After the September 2026 sunset, FIPS 140-2 modules are no longer accepted for new federal compliance needs and are treated as legacy components. Systems that keep using them risk failing audits, procurement checks, and security attestations. The practical impact is a compliance gap, reduced trust in cryptographic assurance, and pressure to replace or recertify affected modules before continued use can be justified.
Why the September 2026 sunset changes the compliance posture
Once the sunset passes, the issue is no longer whether the module once met an approved standard. The practical question becomes whether the system still depends on a component that will not satisfy new federal compliance expectations. That changes how auditors, procurement reviewers, and security teams judge the system, especially where cryptographic assurance is part of the control story.
Legacy status is not just a label. It means the module may still function technically, but it no longer carries the assurance value needed for new approvals. In regulated environments, that difference matters because cryptographic controls are often tied to evidence, attestations, and supply-chain confidence rather than simple operational uptime.
What remains true operationally if the module still works
A module can remain in service and still become unacceptable for future compliance use. That creates a split between technical continuity and governance acceptability. The system may continue to encrypt, sign, or authenticate traffic, but the organisation now has to justify why a legacy cryptographic component is still present and whether that justification is temporary, bounded, and documented.
For teams that rely on the module for production services, the key operational question is whether the dependency is embedded in the platform, the application, or the compliance boundary. The more deeply it is embedded, the more likely the organisation needs a managed transition plan rather than an ad hoc replacement. For background on cryptographic primitives and FIPS-oriented implementation concerns, see the Cryptography Basics Guide.
How to plan the transition without creating a control gap
Teams should treat this as a cryptographic migration and assurance problem, not a last-minute patching exercise. The first priority is inventory: identify every system, service, appliance, or application that depends on the affected module, then map where the module is used for encryption, signing, key handling, or transport protection. That inventory determines whether the replacement path is a software upgrade, a hardware refresh, a vendor recertification path, or a compensating control.
Where key management is part of the dependency, the migration should be coordinated with module replacement so that keys, certificates, and signing material are not stranded in an unsupported trust chain. A useful reference point is the Cryptographic Key Management Guide, which covers lifecycle handling, rotation, and inventory discipline for cryptographic material.
Risk and Threat Considerations
The main risk is not immediate cryptographic failure, but a confidence failure: a system can keep operating while its compliance and assurance basis erodes. That creates exposure in audits, procurement, and regulated workflows, and it can also mask the fact that an older cryptographic implementation is no longer aligned with current assurance expectations.
Failure mechanism: The module remains technically functional, but the organisation continues to rely on a legacy cryptographic assurance boundary after the approval window has closed. That can trigger audit findings, failed procurement checks, or a required rework of the system’s security attestation.
Impact: Continued use can delay approvals, force emergency replacement work, and undermine trust in the system’s cryptographic posture. In the worst case, the organisation may have to suspend or limit use until the dependency is remediated or formally re-justified.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-57 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-57 | Key Management | Directly applies because the issue turns on cryptographic module lifecycle and assurance. |
| Recommendation — Review key lifecycle dependencies and replace or recertify modules that no longer satisfy current assurance needs. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Cryptographic modules often underpin authenticator material and its lifecycle governance. |
| Recommendation — Manage cryptographic authenticators so legacy module dependencies do not persist beyond approved use. | ||
| ISO/IEC 27001:2022 | A.8.24 — Use of cryptography | The question concerns continued use of cryptographic modules under a changed assurance regime. |
| Recommendation — Update cryptographic controls and supporting evidence when module status changes from approved to legacy. | ||
Practitioner Guidance
What to prioritise: Confirm where the module sits in the control boundary first. If it supports production cryptography that is part of a compliance claim, prioritise replacement planning before the sunset date rather than waiting to see whether the old path is still “working.”
What to verify: Test whether the module is tied to a product certification, a third-party attestation, or an internal control statement. If any of those depend on the module remaining current, the replacement timeline needs to move faster than the application team’s release cadence.
Practitioner takeaway: The material issue is assurance decay, not just compatibility. If the module stays in service, the organisation must be able to explain why that dependency is still defensible under current compliance and procurement expectations.