If you sell into government, defense, healthcare, or finance, the phrase FIPS validated eventually lands on your desk. FIPS 140 is the U.S. and Canadian standard that decides whether the cryptography inside a product is actually trustworthy, not just present. This post breaks down what the standard covers, the four security levels, the certificate lifecycle, and exactly where Fortinet fits, with a hard deadline you need to know about.
What FIPS 140 actually validates
FIPS 140 is a publication series from NIST that sets requirements for cryptographic modules: the hardware, firmware, or software that implements approved security functions inside a defined cryptographic boundary. Validation is run by the Cryptographic Module Validation Program (CMVP), a joint program of NIST (U.S.) and the CSE (Canada). Testing is performed by accredited third-party labs, not by NIST or the vendor.
Two points trip people up. First, the standard uses the word validated, not certified. Second, validation applies only to the exact tested configuration: a specific module name, version, and operating environment. Change the build or the hardware and the validation no longer strictly applies.
FIPS 140-3 supersedes FIPS 140-2. It aligns with the international ISO/IEC 19790 standard and tightens several requirements: a mandatory approved-mode indicator across all levels, stricter zeroization of all sensitive security parameters (including public keys), authentication complexity enforced by the module rather than by policy, and new life-cycle assurance demanding internal vendor testing on top of the lab’s work.
The four security levels
Both FIPS 140-2 and 140-3 define four increasing, qualitative levels. Each builds on the one below it.
| Level | Core requirements | Typical use | Fortinet relevance |
| Level 1 | Basic. At least one approved algorithm; production-grade components. No physical security mechanisms required. | Software / firmware modules, general crypto libraries | FortiOS as a firmware module |
| Level 2 | Adds tamper-evidence (seals or coatings) and role-based authentication. | Appliances needing evidence of physical tampering | FortiGate appliance + FortiASIC, exact build/model combo |
| Level 3 | Adds identity-based authentication, physical tamper-detection/response, and zeroization of keys on intrusion. EFP or EFT required. | HSMs, high-assurance government systems | Not currently validated by Fortinet |
| Level 4 | Highest. Full envelope tamper-detection/response, environmental failure protection, fault-injection resistance, MFA. | Hostile/unattended physical environments | Not currently validated by Fortinet |
A key takeaway: the level is not a simple “better product” score. It reflects the **threat model and physical environment** the module is built to survive. A firewall in a locked data center has very different needs than an HSM in an unattended field cabinet.
The certificate lifecycle
A FIPS validation is not permanent. Every module moves through a predictable set of states, and understanding them is the difference between a clean audit and a failed one.
| Lifecycle stage | What it means | Status window |
| Implementation Under Test (IUT) | Vendor has engaged an accredited lab; work has begun but no formal testing submitted. | Pre-submission |
| Module In Process (MIP) | Lab testing complete; report submitted to CMVP and queued for review. | In review (now averaging ~540+ days for 140-3) |
| Active | Validation issued. The certificate can be cited for new federal procurements. 140-3 certs run for 5 years. | 5-year active window |
| Historical | Still usable in existing deployments, but agencies should not include it in new procurements. All 140-2 certs move here on 21 Sep 2026. | Post-sunset / end of 5-year term |
| Revoked | Validation withdrawn due to a discovered security flaw. Should not be used. | Terminal |
The September 21, 2026 sunset
This is the date to circle. On 21 September 2026, CMVP moves every remaining active FIPS 140-2 certificate to the Historical list, regardless of when it was originally validated. The modules keep working in existing systems, but agencies “should not include” historical modules in new procurements. For frameworks like FedRAMP, CMMC, and DFARS, a 140-2 certificate becomes insufficient evidence after that date. CMMC Level 2 enforcement follows about seven weeks later.
Worth knowing: 140-3 validation now averages well over 500 days in the CMVP queue alone, and full efforts often run 18 to 30 months end to end. If a vendor has not already transitioned, the window to do so before the sunset is effectively closed.
Where Fortinet fits
Fortinet validates its products to FIPS 140-2/140-3 Level 1 and Level 2. Since the end of February 2022, all new Fortinet certifications target FIPS 140-3. Mapping that to the levels above:
– Level 1 applies to the firmware/software itself. **FortiOS** is validated as a multi-chip standalone firmware module, with the cryptographic boundary defined as the appliance chassis.
– Level 2 adds the hardware: the FortiGate appliance and its FortiASIC security processors (for example SoC4 or the CP9). A Level 2 certificate is tied to the exact combination of certified firmware build and specific hardware model.
– Fortinet does not currently validate to Level 3 or Level 4, which would require chassis tamper switches and automatic key zeroization on physical intrusion. This process is ongoing and will probably change once the September 2026 deadline arrives.
A practical detail for virtual deployments: FortiGate-VM lacks an internal hardware entropy source, so the Araneus Alea II USB entropy token is required for FIPS or Common Criteria compliance on VM models. Hardware appliances with SoC3/SoC4 or CP9 processors supply their own validated entropy.
FIPS and Common Criteria are not the same thing
Fortinet’s federal firmware is often referred to as FIPS-CC. These are two separate programs bundled together. **FIPS 140** validates the cryptographic module specifically. Common Criteria (typically NDcPP with EAL4+ALC_FLR.3 for FortiOS) evaluates the broader security functionality of the product. A given FortiOS release is validated and evaluated against specific hardware models, so you must match the exact version and platform.
Turning it on
FIPS mode is not the default. You enable it from the CLI:
config system fips-cc
set status enable
set self-test-period 1440
end
Enabling FIPS-CC mode is disruptive by design. On most models the FortiGate **reboots, regenerates its encryption keys, and runs startup and conditional self-tests** before coming back up in FIPS mode. From that point the unit runs periodic self-tests on the interval you set, and restricts itself to NIST-approved algorithms; weak or non-approved ciphers are disabled. Confirm with get system status and look for FIPS-CC mode: enable. Always deploy according to the module’s published Security Policy, which states the exact validated configuration.
Practical checklist
– Verify the exact module name, version, and hardware model against the CMVP Validated Modules database, not a vendor datasheet.
– Confirm the certificate is Active, and check its sunset date.
– If you rely on a 140-2 certificate, plan your move to a 140-3 validated build before 21 September 2026.
– For FortiGate-VM, budget for the Alea II entropy token.
– Deploy strictly per the Security Policy document, or you are running a validated product in an unvalidated way.
Bottom line
FIPS 140 is about proof, not marketing. The level tells you the physical threat model the crypto was built to survive; the lifecycle tells you whether that proof is still citable. Fortinet covers Levels 1 and 2 across FortiOS and FortiGate hardware and has moved to 140-3 for new validations. With the 140-2 historical sunset arriving on 21 September 2026, now is the time to audit your certificates and confirm you are running an Active, correctly configured, FIPS-validated build.
Verify all certificate details against the live CMVP Validated Modules search before relying on them.
