The certificate is real. The auditor still failed you. Both of those things can be true, and the reason they are is the single most common misunderstanding in cryptographic compliance.
A procurement team asks whether a product is FIPS 140-3 validated. A vendor produces a certificate number. Everyone marks the box. Eighteen months later an assessor asks a different question: whether the validated module was operating in its approved mode, on the connection in question, at the time the data crossed it, and the answer is a shrug.
FIPS 140-3 is a genuinely useful standard. It is also narrower than most buyers assume.
Table of contents
- What FIPS 140-3 actually validates
- The four security levels
- What the certificate does not cover
- Where audits actually fail
- How post-quantum changes the picture
- Proving it continuously instead of annually
- Frequently asked questions
Key takeaways
- FIPS 140-3 validates a specific cryptographic module in a specific configuration, not the system that uses it.
- A validated module operated outside its approved mode provides no compliance benefit, and this is where most findings originate.
- The certificate is a point-in-time artefact; assessors increasingly ask for evidence of correct operation over time.
- Post-quantum standards are arriving alongside FIPS 140-3, so validated modules will need to accommodate new algorithms without re-architecture.
- Generating cryptographic evidence continuously at a gateway is more defensible than assembling it manually before each assessment.
What FIPS 140-3 actually validates
FIPS 140-3 is the US federal standard for cryptographic modules, and the word module is doing significant work in that sentence.
Validation under the FIPS 140-3 standard assesses a defined boundary: a piece of hardware, firmware or software that performs cryptographic functions, against requirements covering module specification, interfaces, roles and authentication, physical security, the operational environment, key management, self-tests, design assurance and mitigation of other attacks.
Testing is performed by accredited laboratories and certificates are issued through the Cryptographic Module Validation Program. The result is a certificate identifying that module, that version, that configuration, and the specific approved algorithms it implements.
That is a meaningful assurance. An independent laboratory confirmed the cryptography is implemented correctly and behaves as specified. For regulated sectors and federal supply chains, it is frequently non-negotiable.
The four security levels
FIPS 140-3 defines four levels, and buyers routinely conflate them.
Level 1 requires approved algorithms correctly implemented, with no specific physical security requirements. Most software modules sit here.
Level 2 adds tamper-evidence and role-based authentication: physical seals or coatings that show if a device has been opened.
Level 3 adds tamper-resistance and identity-based authentication, with mechanisms to zeroise keys if the boundary is breached.
Level 4 requires robust protection against environmental attack, including detection of voltage and temperature manipulation.
Higher is not automatically better. A Level 4 hardware module is irrelevant if the connection using it negotiates a non-approved cipher. The level answers how well the boundary is defended, not whether the boundary is being used correctly.
A certificate proves the module was built correctly. It says nothing about whether you are using it correctly.
What the certificate does not cover
This is the gap that produces findings.
It does not validate your system. The module is validated. The application calling it, the configuration selecting algorithms, and the connection carrying the result are not.
It does not guarantee approved mode. Most validated modules can operate in a non-approved mode, often the default. A module running outside its approved configuration provides no FIPS 140-3 compliance benefit, even though the certificate remains valid.
It does not cover key management outside the boundary. How keys are generated, distributed, rotated and retired beyond the module is a separate question, and usually the harder one.
It is point-in-time. Validation reflects a version and configuration at a moment. Patches, upgrades and configuration drift happen afterwards.
It says nothing about coverage. A validated module protecting sixty per cent of your traffic leaves forty per cent unprotected, and the certificate will not mention it.
Where audits actually fail
Assessors have adjusted. The question is no longer whether you hold a certificate.
The questions now are which connections used the validated module, whether it was operating in approved mode at the time, which algorithms were actually negotiated, where the keys came from, whether any traffic bypassed the module entirely, and whether you can demonstrate all of this for a period rather than for a moment.
Most organisations can answer the first question and struggle with the rest. Not because the controls are absent, but because the evidence lives in scattered logs across systems that were never designed to produce a coherent cryptographic record.
The gap between "we are compliant" and "we can prove we were compliant continuously" is where remediation budgets disappear.
How post-quantum changes the picture
FIPS 140-3 compliance is about to become more demanding, and the reason is a second standard arriving alongside it.
CNSA 2.0 mandates post-quantum cryptography from 2027, with Canada, the EU, the UK and the UAE following. The replacement algorithms are standardised: FIPS 203 for key encapsulation and FIPS 204 for digital signatures, published through the NIST post-quantum cryptography project.
Validated modules will need to implement these algorithms, and modules validated only for classical algorithms will need revalidation. Organisations that hard-coded a particular module version into their architecture will discover the cost of that decision during a compliance deadline rather than during a planning cycle.
Meanwhile the threat driving the mandate is already active. Adversaries are capturing encrypted traffic today to decrypt once quantum capability matures. Harvest now. Decrypt later. A FIPS 140-3 certificate for a classical algorithm does not protect data being archived this afternoon.
And there is a second attacker on the same infrastructure. Autonomous AI attacks complete in seconds against enterprise tooling designed to alert a human hours later. Cryptographic compliance and machine-speed defence are usually treated as separate programmes with separate budgets, which is precisely how organisations end up with two migrations colliding in 2027.
Proving it continuously instead of annually
The practical answer to "can you prove it" is to stop assembling evidence and start generating it.
If every connection passes through a single control point, the cryptographic record becomes a by-product of operation rather than a project. Which algorithm was negotiated, which module performed the operation, which identity requested it, when, and whether anything attempted to bypass it, all captured as it happens.
That is one of the four things the Conux cybersecurity gateway does. One agent detects. One blocks and writes the rule. One hardens the surface. One logs the evidence. One orchestrates the rest. Detect. Block. Adapt. Prove, with the proof produced automatically rather than reconstructed before each assessment.
The same gateway applies quantum-safe encryption to every connection, which addresses the 2027 mandate in the same deployment. No rip-and-replace. Existing cloud, identity and applications stay where they are. Weeks, not quarters.
Related reading: quantum computing and compliance, a cryptographic bill of materials and the NIST post-quantum standards explained.
The bottom line
FIPS 140-3 validation is worth having and insufficient on its own.
It proves a module was built correctly. It does not prove your organisation used it correctly, everywhere, continuously, in approved mode, and that is the question being asked now. Add a post-quantum mandate arriving in 2027 and an autonomous adversary operating tonight, and cryptographic evidence stops being an annual exercise.
Two attackers. One gateway.
