FIPS 140-3

What Is FIPS 140-3?

FIPS 140-3 is the United States and Canadian government specification for validating cryptographic modules: the specific hardware or software component that performs encryption. Validation is granted by the Cryptographic Module Validation Program to a named module at a named version, and recorded on a numbered certificate. A product, an image or a platform is never validated.

The standard was approved on 22 March 2019 and became effective on 22 September 2019, superseding FIPS 140-2. It references ISO/IEC 19790:2012, with testing performed against ISO/IEC 24759:2017.

That scoping rule is what makes the standard awkward in a container estate. An image is a filesystem, and may contain OpenSSL, a language runtime's provider, a kernel interface, or all three. The question is which module is validated, and under which certificate.

How Module Validation Works

Validation is a laboratory process with a defined output, and each stage constrains what the resulting certificate means.

• The module boundary is declared. The vendor specifies which code or hardware performs the approved algorithms; everything outside that boundary is untested.
• An accredited laboratory tests it. An independent lab evaluates the module against the requirements and submits its report to the programme.
• A numbered certificate is issued. The CMVP certificate names the module, its version and the environments in which it was tested.
• The module must run in its approved mode. A validated module invoked outside that configuration provides no validated cryptography.

The programme began accepting submissions against the current standard on 22 September 2020, and stopped accepting FIPS 140-2 submissions for new certificates on 1 April 2022. NIST's transition page carries the schedule.

A compliance claim is therefore checkable: ask for the certificate number, the module version it covers, and the tested environment.

What the September 2026 Transition Does and Does Not Mean

In September 2026, every remaining FIPS 140-2 certificate moves to the CMVP Historical List. NIST's own pages differ by a day on the exact date, so plan around the month rather than the day.

Historical does not mean forbidden. Modules on that list may still be purchased and used for existing systems. What changes is how the certificate is treated in new procurement and assessment, and programmes publish their own positions: FedRAMP has issued guidance on the sunset.

For a container estate, four questions follow:

• Which component inside each image performs cryptography, and does anything else quietly implement its own?
• Which certificate covers that component, and does it cover the version actually shipped?
• Does the image configure the module in its approved mode, or merely include it?
• Will the assessor for this system accept a historical certificate, or require a current one?

How to Verify Cryptographic Validation in Production Environments

Treat validation as an inventory problem rather than a procurement checkbox.

• Inventory the providers per image. Record which library each application actually calls, not which libraries happen to be installed.
• Store certificate numbers with the image. Keep the certificate, module version and tested environment in image metadata, not in a spreadsheet.
• Confirm the approved mode at run time. Check that the module reports approved-mode operation on the platform you deploy to.
• Watch the rebuild. A base image rebuild can replace a validated module with an unvalidated newer build, so re-verify after every bump.
• Separate the claim from the evidence. An image described as FIPS-ready is not the same as a module with a certificate.

How Hardened Container Images Support Cryptographic Compliance

Hardened image providers generally assemble images whose cryptographic components come from validated modules and are configured to operate in the approved mode, so teams inherit that configuration rather than building it themselves. Echo states that its images use FIPS-validated modules with a STIG-compliant, hardened configuration, and are ConMon and POA&M ready (echo.ai/product).

The useful question to any provider is narrow: which module, which certificate number, which version, which tested environment, and what happens when the upstream module is rebuilt.

Echo's guidance on finding FIPS-validated base images sets out the checks to run before accepting a vendor's claim.

FAQs

How does FIPS 140-2 differ from the current standard?

They are successive versions of the same cryptographic module standard. The newer one became effective on 22 September 2019 and references ISO/IEC 19790:2012, with testing against ISO/IEC 24759:2017. CMVP stopped accepting FIPS 140-2 submissions for new certificates on 1 April 2022, so fresh validations are now issued only against the current standard.

Can a container image be validated?

No. Validation applies to a cryptographic module, never to an image, a product or a platform. An image can contain a validated module and can be configured so that applications use it in its approved mode, but the certificate always names the module and its version. Ask which module, and which certificate number covers it.

What happens to FIPS 140-2 certificates in September 2026?

They move to the CMVP Historical List. NIST's own pages differ by a day on the precise date. Historical status does not withdraw the module: listed modules may still be purchased and used for existing systems. The practical effect falls on new procurement and on how an assessor chooses to treat that certificate.

How do I find out which module an image actually uses?

Inventory what each application calls at run time rather than what is installed, because an image often ships several cryptographic libraries. Identify the one providing the approved algorithms, record its version, and match that version to a certificate number. Then confirm the module reports approved-mode operation on your deployment platform.

Does using a validated module make a system compliant?

No. Validation is one control among many. A system is compliant when the programme governing it, whether FedRAMP, a defence authorisation or an internal standard, accepts the evidence as a whole, including configuration, key management and operating procedure. A certificate number is necessary evidence rather than sufficient proof of compliance.