FIPS 140-3 certification is a procurement requirement for a growing share of US federal programs, financial institutions subject to OCC guidance, and defense contractors under NIST SP 800-171. Most hardware teams starting the compliance process understand, in broad strokes, that Level 3 requires physical tamper evidence and Level 4 requires active tamper response. What they typically underestimate is the specific silicon-level implementation requirements that those levels impose — and, critically, that battery-backed SRAM zeroization is not the only hardware path to compliance. This piece walks through what FIPS 140-3 Levels 3 and 4 actually require at the chip design level, where the standard gives you design latitude, and where it doesn't.
FIPS 140-3 Structure: ISO 19790 and CMVP
FIPS 140-3 replaced FIPS 140-2 as the active standard in 2019, with mandatory validation lab adoption completed by 2020. The structural change from FIPS 140-2 is significant: FIPS 140-3 is a US government adoption of the international standard ISO/IEC 19790:2012, plus additional NIST-specific requirements in FIPS 140-3 IG (Implementation Guidance) documents. This means the test methodology is documented across multiple NIST and CMVP resources that hardware teams must track simultaneously.
For hardware security modules specifically, the relevant test document is the Derived Test Requirements (DTR) for FIPS 140-3 ISO/IEC 19790:2012 — a 400+ page document specifying exactly how labs verify each requirement. The DTR is where the abstract language of the standard gets translated into pass/fail test procedures. Not reading the DTR directly and relying on vendor summaries is a common source of late-stage compliance failures.
Level 3 Requirements at the Silicon Level
FIPS 140-3 Level 3 adds several physical requirements to the cryptographic algorithm and key management requirements of Level 2. The headline requirement is physical tamper evidence — the module must make tampering evident without active response. In practice, this means:
- Physical package integrity: The cryptographic boundary must use materials that are visibly damaged by physical penetration attempts. Encapsulants, potting compounds, or serialized seals that show evidence of removal qualify. Lab testing involves attempts to penetrate the boundary and assessment of residual evidence.
- Zeroization on detection: Critical Security Parameters (CSPs — which include key material) must be zeroizable when tamper is detected. Level 3 permits either manual zeroization triggered by evidence of tamper, or automated zeroization if detection circuitry is present.
- Identity-based authentication: Level 3 requires at least one authentication mechanism that uses a minimum 1-in-1,000,000 false acceptance probability. Hardware tokens, smart cards, or biometric mechanisms satisfy this; software password authentication alone does not.
The standard's language about zeroization specifies that CSPs in non-volatile storage must be zeroized within 60 seconds of tamper detection for Level 3. This is where battery-backed SRAM implementations shine: the detection circuit can immediately overwrite key material with zeros or random data before power is removed. But battery-backed SRAM is not specified as the required implementation — it's a common implementation pattern, not a compliance requirement.
Level 4 Requirements: What Changes
Level 4 raises the physical protection requirements significantly. The core addition is the requirement for complete physical protection — the module must detect and respond to all physical attacks, not just evidence tamper attempts. The DTR specifies that environmental attacks must also be addressed: voltage glitching, temperature attacks outside the operational range, and abnormal environmental conditions that might disable tamper detection circuitry.
Specifically, Level 4 requires:
- Automated tamper response: Passive tamper evidence is insufficient. The module must actively detect penetration attempts and trigger immediate zeroization without operator intervention.
- Environmental failure protection: The module must either detect and respond to out-of-range voltage or temperature conditions, or be designed to prevent operation under those conditions (which typically means active environmental monitoring on the module itself).
- Hardened detection circuitry: The tamper detection and response circuits themselves must be protected against attacks that disable them before penetration. Level 4 lab testing includes targeted attacks on detection circuitry.
The 60-second zeroization window from Level 3 tightens at Level 4: the standard requires that automated response occurs before the detection event itself provides the adversary useful information. In practice, this means zeroization must complete in milliseconds, not seconds, for modules subject to fast-penetration attack scenarios.
Why Battery-Backed Designs Are Not the Only Compliance Path
The persistence of battery-backed SRAM as the dominant Level 3 and Level 4 HSM design pattern is historical, not mandated. Battery-backed SRAM evolved because, at the time FIPS 140-2 was written, it was the most straightforward way to satisfy the requirement for CSP zeroization on tamper detection: keep the key in volatile memory, keep the detection circuit powered by a battery, and zero on detection. Simple, auditable, well-understood by evaluators.
The standard, however, specifies the outcome required — CSPs are zeroized on tamper detection — not the mechanism. Alternative mechanisms that satisfy the same outcome requirement include:
"A CSP that is never stored — that is reconstructed on demand from a physical characteristic of the module itself — satisfies the zeroization requirement by design. There is nothing to zeroize because the key does not persist between uses."
PUF-based key derivation is the implementation that makes this concrete. If key material is derived from a masked PUF response at the time of use and never written to non-volatile storage, the zeroization requirement becomes trivial: power the chip off, and the key is gone. There is no stored secret to protect, no battery to replace, and no detection circuit that must remain continuously powered. The tamper evidence requirement is still present — the module boundary must still show evidence of penetration — but the consequence of successful penetration is limited to access to the PUF helper data, which is public by design and reveals nothing about the key without the physical silicon.
Evaluation Lab Interaction: What to Expect
CMVP evaluations are conducted by accredited Cryptographic Testing Laboratories (CTLs). The evaluation timeline for Level 3 hardware modules has historically run 18–24 months from submission to certificate issuance, with most of the delay occurring in the NIST review queue after lab testing completes. Level 4 evaluations run longer — 24–36 months is a reasonable planning baseline for first-time submitters.
Key practical observations from teams who have completed evaluations:
- Document the security policy before hardware is finalized. The Security Policy is a required submission artifact that must accurately describe the module's cryptographic boundary, approved algorithms, CSP lifecycle, and roles. Changing hardware after the Security Policy is written creates revision loops that add months.
- Algorithm implementations must be ACVT-validated separately. The Automated Cryptographic Validation Testing (ACVT) program validates each algorithm implementation independently. Each algorithm mode (AES-256-GCM, ECDSA P-384, SHA3-512) requires separate test vector validation. Plan for this as parallel work, not sequential.
- Physical security testing is destructive. Labs will physically attack your module to verify tamper evidence. Submit more units than you think you need — typically 3–5 evaluation units at minimum, more for Level 4 where environmental testing adds additional destruction.
- Conditional algorithms require additional justification. NIST's approved algorithm list for FIPS 140-3 excludes some algorithms present in FIPS 140-2 validated modules (3DES is the most common example). If your module implements any non-approved algorithms, the Security Policy must clearly bound them to non-FIPS-approved modes.
What This Means for Early-Stage Hardware Design
For teams in the tape-out or pre-tape-out phase, the most costly compliance decision is the one that's hard to reverse: the key storage architecture. Battery-backed designs commit you to battery management across the product's lifetime. If you're designing a chip that's intended to operate in data center form factor for 5–10 years, that means battery replacement cycles, operational procedures for unexpected battery failure, and the attendant HSM fleet management complexity.
PUF-based key derivation sidesteps these operational costs. The compliance path is different — you need to establish entropy assessment per NIST SP 800-90B for your specific PUF implementation, and the evaluator interaction around a novel tamper model requires more documentation than a battery-backed SRAM approach that evaluators have seen dozens of times. But the operational posture over the product lifetime is substantially simpler, and the on-chip security properties are stronger in the specific sense that there is no persistent key to exfiltrate under any storage-access attack scenario.
We're working through the FIPS 140-3 evaluation process for our ASIC design now. If you're at an early design stage and want to compare notes on evaluation lab interaction or entropy assessment methodology, we'd welcome that conversation.
