FIPS certification for SSDs
Note: timeline and cost figures below are typical ranges and should be confirmed with an accredited test lab.
What FIPS is
FIPS (Federal Information Processing Standards) are US government standards published by NIST. For a drive, the relevant one is FIPS 140-3, Security Requirements for Cryptographic Modules. It defines how the hardware and firmware that perform encryption must be designed, tested and documented. US federal agencies must use validated modules to protect sensitive data, and many regulated industries (defense, healthcare, finance) and the Canadian government require the same.
- FIPS 140-3 is the current version. It replaced FIPS 140-2 and is based on ISO/IEC 19790. New 140-2 submissions ended in 2022, and remaining 140-2 certificates were scheduled to move to the historical list in September 2026.
- FIPS 197 is not the same thing. FIPS 197 is the AES algorithm standard. A drive marketed as "FIPS 197" has a validated AES implementation, but the drive as a whole has not been validated as a module.
- The certificate covers a specific configuration. It applies to named hardware and firmware versions, so a security-relevant firmware change requires revalidation.
Security levels
| Level | What it requires | Typical SSD relevance |
|---|---|---|
| 1 | Approved algorithms and correct implementation; no physical security beyond production-grade components | Software or basic hardware encryption |
| 2 | Adds tamper-evident seals or coatings and role-based authentication | Most common target for self-encrypting drives |
| 3 | Adds tamper resistance and response (such as hard epoxy potting and key zeroization), identity-based authentication, and stronger key protection | High-security and defense drives |
| 4 | Adds a full tamper-detection envelope and protection against environmental attacks (voltage, temperature) | Rare for SSDs; mostly hardware security modules (HSMs) |
Drives without an enclosure (M.2 and other bare-board form factors)
FIPS 140-3 does not require a drive to be in an enclosure. It requires that the cryptographic boundary be physically protected to the claimed level. The boundary is the defined perimeter containing every component that performs or stores security functions (keys, encryption, authentication, firmware verification). The vendor chooses where to draw it, and the lab and CMVP must agree it is complete.
The standard recognizes three physical embodiments, and each has its own protection rules:
| Embodiment | Example | Boundary |
|---|---|---|
| Single-chip | The SSD controller alone | The chip package |
| Multiple-chip embedded | A bare M.2 board | The board, or a protected region of it |
| Multiple-chip standalone | A 2.5" or U.2 drive | The full enclosure |
How the boundary is physically protected
| Level | Protection required |
|---|---|
| 1 | Production-grade components with standard passivation; no further protection |
| 2 | Opaque, tamper-evident coating or enclosure, with tamper-evident seals on any removable covers; components inside must not be visible |
| 3 | Hard, opaque tamper-evident coating, potting, or package (or a strong enclosure with tamper response and zeroization on any door or cover); removal attempts must have a high probability of seriously damaging the module; vents must block probing; environmental failure protection or testing (EFP/EFT) for voltage and temperature |
| 4 | Complete tamper-detection and response envelope with immediate zeroization, plus environmental failure protection and fault-injection resistance |
For a bare M.2 drive at Level 3 there are two usual approaches:
- Pot the board. Cover the controller, NAND, DRAM and the traces between them with a hard, opaque epoxy or encapsulant.
- Shrink the boundary to the controller. Validate the controller chip as a single-chip module with a hard, opaque coating or package. The NAND sits outside the boundary and holds only encrypted data.
Engineering trade-offs of potting: it traps heat, must fit within M.2 height limits, and prevents rework and failure analysis.
Physically removable NAND
A drive with removable NAND can still reach Level 3, depending on where the NAND sits relative to the boundary:
- NAND outside the boundary (the workable route). The controller is the module. Everything on the NAND must be ciphertext: user data is encrypted, and any keys stored there are wrapped with an approved method under a key that never leaves the controller in plaintext. Firmware stored on the NAND must be verified with an approved signature before it runs. The certificate then covers the controller module, not the whole drive, and the Security Policy must say so.
- NAND inside the boundary. A removable component is treated like a door or cover. At Level 3, opening or removing it must trigger tamper response and zeroization of plaintext keys, which is hard to do on an unpowered drive without a battery-backed circuit.
Levels are assigned per requirement area, so a drive can hold Level 3 for physical security with a different overall level. Confirm with the customer whether "Level 3" means the overall certificate level.
Who does the certification
- CMVP (Cryptographic Module Validation Program) issues the certificate. It is run jointly by NIST and the Canadian Centre for Cyber Security.
- An accredited third-party test lab does the testing. These labs are accredited under NIST's NVLAP program; examples include atsec, Leidos, UL, Lightship and Intertek Acumen.
- The vendor hires and pays the lab. The vendor never submits directly to NIST.
The certification process
- Define and design. Set the cryptographic boundary (typically controller, firmware and NAND in the enclosure) and the target level, often with a consultant or lab doing a gap analysis.
- Algorithm validation (CAVP). Each algorithm (AES-XTS, SHA, DRBG, RSA/ECDSA for firmware signing, and so on) is tested through NIST's automated system and receives its own certificate.
- Entropy validation (ESV). The random-number entropy source is assessed against SP 800-90B.
- Documentation. The vendor writes the Security Policy, a finite state model, design documents and key management descriptions.
- Lab testing. The lab reviews source code, runs functional and self-test checks, and does physical security testing for Level 2 and above. The module is listed as "Implementation Under Test".
- CMVP review. The lab submits its report and the module moves to the "Modules in Process" list. It then goes through review pending, in review, coordination (questions and answers with the lab) and finalization.
- Certificate issued. The module appears on the public NIST validated modules list and stays active for five years.
How long it takes
| Phase | Typical duration |
|---|---|
| Design, gap analysis, documentation | 3–6 months |
| Algorithm, entropy and lab testing | 3–6 months |
| CMVP review queue and coordination | 6–18 months |
| Total for a new SSD | About 12–24 months |
- The CMVP queue is the largest and least predictable part. It has run well over a year at times.
- Reusing validated parts shortens the schedule. Building on an already-validated controller or crypto module, or rebranding an existing validated module under an OEM arrangement, can cut it to a few months.
- Cost for a new hardware validation is typically in the low-to-mid six figures (USD). That covers lab fees, NIST fees and engineering effort.