FIPS Validation for Cloud Providers: Guide 2026

If you sell cloud, hosting, or SaaS into regulated markets, the short answer is this: check your crypto boundary, move to FIPS 140-3, and stop relying on vendor wording alone. From 21 September 2026, FIPS 140-2 certificates move to Historical status, so new federal and FedRAMP-facing work should point at active FIPS 140-3 certificates.

I’d boil the whole article down to four checks:

• Know what is in scope: FIPS applies to the cryptographic module, not your whole platform.
• Verify the certificate: look up the exact module, version, environment, and status on csrc.nist.gov.
• Match architecture to validation: KMS, HSMs, TLS endpoints, containers, and regions only count if the validated boundary covers them.
• Plan for time and cost: custom validation can take 18+ months and often costs £40,000 to £80,000+.

A few numbers stand out. The article notes an average of 542 days from CMVP submission to an active 140-3 certificate, a common 16 to 18 week engineering and documentation push for transition work, and 3 to 6 months of lead time for some HSM hardware. So if your stack still leans on 140-2, I’d treat this as a live delivery issue, not a paperwork task.

What matters most? You need to know where keys are generated, stored, used, and erased; whether your cloud service uses the right FIPS endpoints; whether your OS, hardware, and container images are covered; and who owns certificate checks after launch.

I see this as a simple rule: if the certificate does not match the thing you run, you should assume you are not covered. The rest of the article then walks through requirements, architecture choices, rollout steps, and the cost and governance work needed to keep that status in place.

Core FIPS 140-3 and CMVP Requirements

Cryptographic modules, security levels and validated environments

Once the boundary is clear, the next job is to map each validated module to the controls that CMVP will test.

A cryptographic module is the software, firmware or hardware that performs cryptographic functions. The module boundary defines exactly what the certificate covers. In cloud setups, providers often validate software libraries, cloud-native hardware, or operating-system crypto APIs [3]. In container environments, only the validated libraries inside the image are in scope [6].

FIPS 140-3 sets out four security levels across 11 requirement areas. Level 2 requires role-based authentication. Level 3 goes further with identity-based authentication and zeroisation on breach.

One mistake shows up again and again: treating FIPS-capable as if it means FIPS-validated. It does not. FIPS-capable means there is a configuration flag or mode available. FIPS-validated means there is an active CMVP certificate tied to a specific module version [5]. That difference matters more than many teams expect.

How the CMVP process works and how to read a certificate

This matters because CMVP validates a specific module, version and environment, not a broad claim about an implementation.

CMVP is run by NIST and CCCS. NVLAP-accredited labs test the module and submit the evidence to CMVP. If CMVP accepts the findings, it issues a certificate and adds the module to the public database at csrc.nist.gov [7].

When you review a certificate, check the module version, security level, tested environments and status. If your OS or hardware is not listed, your deployment is not covered [7]. This trips up plenty of cloud teams. They assume a vendor’s validated module automatically covers their own setup. It doesn’t. Vendor claims are not enough; the certificate has to match the deployment you are running [2].

Approved algorithms, self-tests and key management controls

After the certificate check, the next issue is how the module deals with approved algorithms, self-tests and key lifecycle controls.

Non-approved algorithms should be disabled when the module runs in FIPS-approved mode. The same applies to non-approved TLS configurations [7].

FIPS 140-3 requires power-on self-tests, runtime self-tests and conditional self-tests. Conditional tests run when certain operations take place, such as key generation or algorithm use.

Key management controls cover the full lifecycle:

• generation
• storage
• distribution
• zeroisation

FIPS 140-3 also defines a Crypto Officer role. Entropy sources must be documented and tested continuously. It also helps to build a Cryptographic Bill of Materials (CBOM) early. List every cryptographic asset, its configuration and certificate status, including third-party dependencies [2].

FIPS 140-2 and 140-3 Explained with Critical Insights for Cryptographic Security and Compliance

Choosing a FIPS Architecture for Cloud Services

::: @figure {FIPS 140-3 Cloud Validation Routes: Time, Cost & Effort Compared} :::

Once you've set the module boundary and the controls around it, the next call is simple in theory but big in practice: where does validation sit in your architecture?

Using validated managed services versus validating your own module

You have two main routes. You can use an existing validated managed service, or you can validate your own module. That one choice shapes cost, delivery time and long-term upkeep. The right order is: validated boundary first, architecture second, cost third.

Using validated managed services is usually the fastest path. You can go live in weeks rather than years, and the provider carries the burden of keeping the validation current. Building and submitting your own module gives you control and room to shape things exactly how you want, but it comes with a heavy price in both money and time.

NIST's cost-recovery fees alone run from around £12,600 at Level 1 to about £15,000 at Level 4, and that's before lab fees and engineering time. Total all-in costs for a custom validation usually land between £40,000 and £80,000+ [9].

Unvalidated encryption does not count as FIPS protection.

For most cloud teams, validated managed services are the sensible place to start. Custom validation tends to fit only where a product has cryptographic needs that no current validated module can cover.

That decision then flows straight into how you design KMS, HSM, TLS and regional failover.

Design choices for KMS, HSMs, TLS endpoints and multi-region deployments

Centralised key management is simpler to audit and rotate. The trade-off is that it can become a latency bottleneck and a single point of failure. A distributed model spreads regional risk, but your audit trail gets messier. That's the usual trade: cleaner control in one place, or more moving parts across several.

HSM-backed key storage is required for Level 3 compliance, but it brings higher cost and tougher disaster recovery planning. Software-backed services often fit lower assurance levels and rarely meet Level 3.

For regional deployments, don't assume coverage. Check that the exact service, region and configuration sit under an active CMVP certificate. Validated endpoints are not offered everywhere. AWS FIPS endpoints for encryption in transit, for example, are currently limited to US Commercial, GovCloud and Canadian regions [3]. Your application also needs to be set up to use the -fips endpoint variants [11].

Containerised setups have their own trap. Turning on FIPS at the node level is not enough by itself. The container images running on those nodes are often not assessed for FIPS compliance [10].

How AWS, Azure and Google Cloud fit into a FIPS strategy

From there, map your design to the exact service, region and endpoint you plan to run.

A few points matter more than they first seem.

For AWS, standard regional endpoints do not route through FIPS-validated cryptographic paths. If you're using AWS CloudHSM, check that you've moved from hsm1.medium to hsm2m.medium; the former moved to the CMVP historical list on 4 January 2026 [11].

For Azure, the Standard tier of Key Vault is software-backed and does not meet Level 3 requirements. You need either the Premium tier or Managed HSM. Teams using AKS should also note that Ubuntu 20.04 node pool support ends on 17 March 2027. That means a move to Ubuntu 22.04 is needed if you want FIPS-enabled node pool support to continue [10].

Google Cloud's External Key Manager (EKM) can help with workloads that have data-residency constraints, though it can add latency during decryption events [8]. Before you lock anything in, verify the exact CMVP certificate, its active status and the tested configuration for the service, region and endpoint you plan to use.

Validation Process and Production Rollout: Step by Step

Gap analysis, scope definition and evidence preparation

Once you’ve fixed the service, region and endpoint, the next job is validation planning.

Start by mapping every place cryptography shows up in your stack. That includes TLS termination, data-at-rest encryption, signing and secrets handling. Then turn that map into a CBOM that lists each key, certificate, algorithm, protocol, module and its current validation status.

Next, check every module against the NIST CMVP database at csrc.nist.gov. Any non-active FIPS 140-3 module counts as a gap. Common problems include deprecated algorithms, legacy TLS on internal endpoints and non-FIPS KMS endpoints [2].

When the gap list is done, put together the submission pack. This should include verified CMVP records, FIPS-mode exports, key ceremony records, test results, a Security Policy and a Finite State Model showing module state transitions [9]. If your module includes an entropy source, expect a separate entropy validation submission. NIST lists the full entropy validation fee at US$5,500 as of January 2026 [9].

If you need hardware changes, start HSM procurement on day one. Lead times of three to six months can throw the whole schedule off course [2].

Working with test laboratories and managing timelines

Once the evidence pack is ready, bring in an NVLAP-accredited test laboratory. The lab begins with ACVP algorithm testing before moving to full module evaluation [9].

Freeze the build before submission. Unstable releases are the main reason labs get delayed.

After testing, the lab sends the report to CMVP for review and any follow-up comments. Reviewers may ask for extra evidence or fixes before they issue a certificate. The average time from CMVP receiving a test report to issuing a certificate has historically been more than 18 months [9]. That’s a long wait, so your product roadmap needs to account for it.

It helps to map the work to a schedule before lab engagement starts:

Keeping FIPS status intact after launch

FIPS status is tied to a specific module version and build configuration. If the version number changes on a validated module, re-validation may be required [9]. In plain terms, dependency management becomes part of compliance, not just engineering.

Use automated pipeline scanning at every build stage. Pair SBOMs and signed provenance with admission controls that block unsigned images [12].

At runtime, monitor HSM health, entropy quality and crypto latency. Also schedule an annual review of your CBOM. System changes, new vendor products and updated NIST guidance can all introduce gaps that weren’t there at launch [2].

Keep the CBOM current, pin validated versions and test every change before production. Those controls also feed into governance, change management and audit readiness.

Governance, Cost Control and Next Steps

Governance and risk controls for regulated cloud environments

Once the validated module is live, the main risk is no longer the design. It’s ownership.

After launch, FIPS turns into an ownership issue: every control needs a named team and a set review rhythm. The usual weak spots are expired certificates, undocumented changes, and endpoint swaps that nobody tracked. In most cases, four teams share day-to-day FIPS ownership:

That internal split is only part of the picture. The hyperscaler boundary needs to be written down too. Be exact about what the hyperscaler covers and what still sits with your team, including access controls, configuration exports, and key-ceremony records.

Governance also needs to cover zeroisation procedures - the secure erasure of keys triggered by tamper events or administrative commands [4].

Cost, performance and automation trade-offs

Once ownership is clear, the next issue is the cost of keeping that control in place.

Ongoing FIPS compliance costs usually fall into five areas: re-validation when module versions change, HSM provisioning and operations, audit evidence collection, endpoint testing, and automated pipeline checks.

Automated CI/CD checks spot unvalidated modules earlier than manual review. Put those checks into every pipeline stage so routine dependency updates don’t open silent gaps [6].

Conclusion: a practical roadmap for cloud providers

The operating model now has to turn those controls into routine work.

In practice, steady FIPS compliance comes down to four habits: define the boundary, verify the certificate, automate change control, and audit on a set schedule. Check the certificate directly on the NIST CSRC website instead of relying on vendor claims [1][2][6]. Then schedule annual cryptographic audits to catch gaps caused by system changes or updated NIST guidance [2].

The hard deadline is 21 September 2026, when all FIPS 140-2 certificates move to the CMVP Historical List [13][2][6]. If your stack still depends on 140-2 validated modules, treat that date as a live project milestone.

If aligning FIPS requirements with your broader DevOps work and cloud cost plan feels like a lot to handle at once, Hokstad Consulting works with cloud providers on exactly that mix - tying cryptographic compliance into CI/CD pipelines, cloud cost engineering, and infrastructure automation so compliance controls and day-to-day efficiency move in the same direction instead of working against each other.

FAQs