FIPS 140-2 Sunset September 2026: The Migration Guide to FIPS 140-3

On September 21, 2026, the Cryptographic Module Validation Program (CMVP)—jointly administered by the National Institute of Standards and Technology (NIST) and the Canadian Centre for Cyber Security (CCCS)—will reclassify all remaining active FIPS 140-2 cryptographic modules to the Historical List. This transition completes the five-year sunset window that began on September 21, 2021, when the CMVP stopped accepting new validation submissions under the legacy standard. For platform architects, security compliance officers, and DevSecOps engineers supporting federal, defense, and FedRAMP environments, this change establishes a hard procurement cutoff across all software and infrastructure baselines.

[[image:poster]]

Moving to Historical status does not render cryptographic modules mathematically broken or insecure overnight, nor does it mandate the immediate shutdown of operational systems. Instead, the transition imposes an administrative and legal procurement ban. Existing deployments operating under an approved System Security Plan (SSP) and Authorization to Operate (ATO) remain grandfathered. However, federal procurement directives prohibit agencies and prime contractors from including Historical-status modules in new system acquisitions, contract recompetes, fleet expansions, or hardware refreshes.

graph TD
 A[Cryptographic Module Asset] --> B{Validation Standard}
 B -->|FIPS 140-2| C{System Lifecycle Context}
 B -->|FIPS 140-3| D[Verify CMVP Active List]
 C -->|In-Situ Existing Fleet| E[Grandfathered Under Current ATO]
 C -->|New Procurement / RFP / Node Expansion| F[Procurement Blocked: Historical Status]
 E --> G[Log on FedRAMP POA&M / Plan Migration]
 F --> H[Migrate to FIPS 140-3 Validated Module]
 D --> I[Compliant Deliverable]
 H --> I

Procurement and Compliance: Grandfathering Versus Procurement Bans

The CMVP maintains three distinct lifecycle classifications for cryptographic modules:

Under Federal Acquisition Regulation (FAR) clause 52.204-21 and NIST SP 800-53 Revision 5 (Security Control SC-13, Cryptographic Protection), federal information systems must employ active, validated cryptographic mechanisms. When an agency issues a Request for Proposals (RFP) or an engineering team procures additional capacity, Contracting Officers (COs) and Contracting Officer Representatives (CORs) cannot legally accept deliverables relying on Historical modules.

Grandfathering applies solely to static, already-authorized production footprints. It does not protect:

• Procuring additional server nodes or software licenses under new delivery orders.
• Forklift hardware refreshes, including the replacement of physical Hardware Security Modules (HSMs).
• Major application re-architectures, platform migrations, or new microservice deployments.
• Contract recompetes or new FedRAMP Agency Authorizations.

For Cloud Service Providers (CSPs) subject to FedRAMP baselines (SC-13 and SC-8), reliance on Historical modules must be logged as a deficiency on the platform's Plan of Action and Milestones (POA&M). Third-Party Assessment Organizations (3PAOs) evaluate these entries during annual continuous monitoring assessments, where unmitigated dependencies can impede ATO renewals. In defense infrastructure, defense industrial base (DIB) contractors audited under CMMC Level 2 and Level 3 face non-compliance findings if underlying Linux operating environments deliver sunset cryptographic providers.

Core Breaking Changes in FIPS 140-3

FIPS 140-3 transitions federal cryptography from domestic criteria to international standards: ISO/IEC 19790:2012 (Security requirements for cryptographic modules) and ISO/IEC 24759:2014 (Test requirements), modified by the NIST SP 800-140 series. This structure introduces non-negotiable architectural mandates:

Under Implementation Guidance IG 2.4.C, applications calling an OpenSSL 3 FIPS provider can no longer rely on ambient compliance flags. Code must inspect the service indicator directly:

#include <openssl/evp.h>
#include <openssl/core_names.h>

int verify_fips_indicator(EVP_CIPHER_CTX *ctx) {
 int approved = 0;
 OSSL_PARAM params[2];

 params[0] = OSSL_PARAM_construct_int(OSSL_CIPHER_PARAM_FIPS_INDICATOR, &approved);
 params[1] = OSSL_PARAM_construct_end();

 if (EVP_CIPHER_CTX_get_params(ctx, params) <= 0) {
 return 0; /* Call failed or indicator unsupported */
 }
 return approved; /* Returns 1 if fully approved, 0 otherwise */
}

In runtime environments such as Go, builds utilizing legacy BoringCrypto wrappers under FIPS 140-2 must transition to Go 1.24+ native cryptography, which implements strict FIPS 140-3 controls through the GOFIPS140 build directive.

Simultaneously, NIST SP 800-90B mandates continuous Repetition Count Tests (RCT) and Adaptive Proportion Tests (APT) on the physical noise source. If an entropy source drifts or repeats samples, the module enters a fatal state, rejecting Deterministic Random Bit Generator (DRBG) seeding and blocking handshake negotiations. At the protocol layer, NIST SP 800-131A Revision 2 completely terminates Triple-DES encryption, bans SHA-1 signature generation, and requires the TLS 1.2 Extended Master Secret (EMS / RFC 7627) extension. Handshakes drop instantly if legacy load balancers or proxies do not negotiate EMS.

Fleet Audit Playbook

DevSecOps teams must run an automated audit across host kernels, cryptographic configurations, shared libraries, and application runtimes.

# 1. Host Kernel: Verify kernel-level FIPS enforcement (must return 1)
cat /proc/sys/crypto/fips_enabled

# 2. System Policy: Verify active cryptographic policies and EMS enforcement
update-crypto-policies --show | grep -i "NO-ENFORCE-EMS" || echo "Strict EMS Active"

# 3. Provider Integrity: Audit active OpenSSL 3 providers and verify shared library
openssl list -providers -verbose
openssl fipsinstall -verify -module /usr/lib64/ossl-modules/fips.so \
 -provider_name fips -mac_name HMAC -section_name fips_sect

# 4. Binary Runtimes: Inspect Go application binaries for FIPS 140-3 engine symbols
go version -m ./target_binary | grep -E "GOFIPS140"

Enterprise Distribution Roadmap

Vendor Backlog and Queue Management

The validation queue across Cryptographic and Security Testing (CST) laboratories and the NIST/CCCS review system currently averages 12 to 24 months:

[ CST Lab Testing ] ──> [ Review Pending ] ──> [ In Review ] ──> [ Coordination ] ──> [ Finalization ] ──> [ Validated ]
 (6-12 Months) (Queue: ~6-12 Mo) (NIST/CCCS) (Comments/Edits) (Cert Sign-off) (Active List)

Module listing on the Modules in Process (MIP) list does not constitute validation. Under CMVP policy, an entry on the MIP list conveys no formal compliance rights.

When dependent on commercial hardware security modules or third-party software whose FIPS 140-3 certificates remain pending, teams must execute a three-part risk strategy:

1. Audit MIP Stages: Reject vendor self-attestations. Require vendors to supply their official CMVP tracking number, accredited laboratory identifier, and verified stage (Review Pending, In Review, Coordination, or Finalization).
2. Document FedRAMP POA&Ms: Record the module transition in the platform's POA&M, citing the active FIPS 140-2 certificate, the vendor's MIP tracking number, and the projected transition timeline under FedRAMP Cryptographic Module Selection guidelines.
3. Structure Contracting Officer Waivers: File an interim compliance waiver with the agency Contracting Officer Representative:

• Justification: Establish that the cryptographic engine has completed laboratory testing and is queued in CMVP "Coordination" or "Finalization."
• Compensating Controls: Demonstrate defense-in-depth protections, such as encapsulating traffic inside an already-validated FIPS 140-3 perimeter gateway or IPsec tunnel.
• Sunset Clause: Bind the agreement to an expiration term (6 to 12 months), with a contractual requirement to deploy the validated FIPS 140-3 module within 60 days of certificate publication.

By auditing operating system stacks, adapting application code to explicit service indicator APIs, enforcing SP 800-131A cipher baselines, and monitoring vendor queue trajectories, platform teams will safeguard their compliance and procurement eligibility through the September 2026 deadline.