FIPS 140-3 officially replaced FIPS 140-2 as the active standard for cryptographic module validation in September 2022, when NIST closed the 140-2 submission window. For a team designing custom security silicon, the transition represents more than a version number change — the underlying evaluation methodology shifted from NIST's own scheme to ISO/IEC 19790:2012 (the module security requirements) and ISO/IEC 24759:2017 (the test requirements), administered through the NIST Cryptographic Module Validation Program (CMVP) via accredited Cryptographic and Security Testing (CST) laboratories. Understanding that structure matters before any RTL is taped out, because design decisions made early become certification liabilities or assets later.
ISO/IEC 19790 vs. FIPS 140-2: What Changed for Silicon
The most significant structural difference for hardware modules is the physical security section. FIPS 140-2 defined four levels with Level 3 requiring "tamper-evident" coatings and Level 4 requiring "tamper-active" response. ISO/IEC 19790 preserves the four-level structure but tightens the requirements at Level 3 and expands the annex on environmental failure testing.
Under 19790, Level 3 physical security requires that the module respond to physical probing attempts with a zeroize response — passive tamper-evidence alone (coatings, seals) is insufficient for Level 3. For a custom ASIC, this means the tamper-detection mesh must be connected to active zeroize logic that clears key registers and SRAM within a specified response time. The standard does not specify a maximum response time in microseconds, but the CST lab will probe against the tamper response criterion operationally during testing.
The software/firmware requirements in 19790 are more explicit about roles and authentication: Level 3 requires identity-based authentication (not just role-based) for sensitive security parameter access. For a module with an administrative interface, this typically means crypto officer credentials must be identity-bound, not shared role passwords. For a hardware-only module with no external interface for cryptographic officer operations, this section may not apply in the same way — but the determination of applicability is the module boundary definition question, and getting that wrong costs months.
Entropy Source: SP 800-90B Compliance as a Gate Item
FIPS 140-3 modules must use approved entropy sources, and for any hardware module with an on-die entropy source (TRNG, SRAM PUF), SP 800-90B compliance documentation is a hard gate item. The CMVP will not process a submission without it.
SP 800-90B Section 2 defines the entropy source model: a noise source produces raw entropy, conditioning functions process it, and the output feeds a deterministic random bit generator (DRBG). Each component of this pipeline must be documented and tested. The IID and non-IID entropy estimation tests defined in Section 6 must be run on raw noise source output — not on post-conditioning output — and the min-entropy claim must be the minimum of the IID estimator upper bound and the non-IID estimators.
A common mistake: running SP 800-90B tests on the output of a von Neumann corrector or other conditioning function, then claiming the conditioned output entropy as the source entropy. The CST lab will flag this. The noise source characterization must be on raw samples before any whitening.
The practical timeline impact: collecting sufficient SP 800-90B data requires silicon. You cannot characterize a TRNG on a simulator or an FPGA prototype — process-dependent physical noise characteristics only exist in real silicon. This means the SP 800-90B characterization run cannot start until first silicon is available, which is typically 6–9 months post tape-out at an advanced node. If you plan to submit to CMVP on a schedule that requires SP 800-90B data, the prototype silicon schedule is on the critical path for certification, not just for product validation.
CAVP: Algorithm Certificates Before CMVP
The Cryptographic Algorithm Validation Program (CAVP) certification is a prerequisite for the CMVP module submission. Every approved algorithm implemented in the module — AES, SHA-3, ECDSA, HMAC, the DRBG — must have a separate CAVP certificate before the module review can proceed. CAVP testing is conducted by the same accredited CST labs that do CMVP work, using Known Answer Tests (KATs) against the NIST test vector sets.
For a silicon implementation, CAVP algorithm testing is a significant engineering effort because the test vectors must exercise the actual hardware implementation, not a reference software model. The CAVP test harness must interface with the hardware through the module's API, which means the firmware layer and host driver stack must be sufficiently complete to run automated CAVP test sessions. Teams that attempt to run CAVP before the firmware interface is stable lose significant time to re-testing after firmware changes.
Practical sequencing: lock the crypto engine RTL before silicon tape-out; begin CAVP algorithm testing on the first metal spin; hold the firmware API stable from that point. Any crypto-engine RTL change after the first tape-out restarts the CAVP clock for affected algorithms.
The CMVP Submission Process and Realistic Timelines
A CMVP submission for a hardware module at Level 3 involves: the Security Policy document (a public-facing description of the module's approved uses, CSP handling, and security rules); the Finite State Model; the algorithm implementation documentation; the SP 800-90B entropy source documentation; the physical security documentation (test specimens and tamper test protocols); and CAVP algorithm certificates for all approved algorithms. The complete package routinely runs several hundred pages.
Once submitted, the CMVP assigns the submission to a review queue. As of recent years, the CMVP queue for hardware modules has run 12–18 months from initial submission to certificate issuance, with significant variation depending on submission completeness and the number of review cycles required. Incomplete submissions that require clarification rounds can extend this to 24+ months.
The most efficient path: engage the CST lab that will test your module during the design phase, before tape-out. Many labs offer pre-submission consulting to review the proposed module boundary, the Security Policy draft, and the physical security approach. Issues identified at that stage cost engineering time; issues identified after first silicon is delivered cost both engineering time and silicon respins. Labs accredited under the National Voluntary Laboratory Accreditation Program (NVLAP) for cryptographic module testing are listed on the NIST website.
Design Decisions That Affect Certification Level
Not every design decision is certification-neutral. Several architectural choices made early in RTL design directly constrain the achievable certification level.
Key storage isolation: If key material is accessible via any external bus (JTAG, debug interface, memory-mapped register visible to a host CPU), the module cannot claim Level 3. Key registers must be within the cryptographic boundary and inaccessible to entities outside it. This seems obvious, but JTAG debug paths left enabled in early engineering spins — and not formally excluded from the module boundary — have failed certification reviews.
Zeroize coverage: The zeroize response must cover all Criticial Security Parameters (CSPs) — all keys, all intermediate keying material, all authentication data. The CSP inventory must be documented in the Security Policy. Missing a register from the zeroize path is an easy mistake in RTL and a definitive Level 3 certification failure.
Power analysis countermeasures: Level 3 does not mandate resistance to DPA, but Level 4 does. If a Level 4 target is on the roadmap, designing DPA countermeasures into the RTL from the start is far less expensive than retrofitting them in a metal spin. Dual-rail precharge logic and masking schemes are RTL decisions that cannot be added cleanly post-tape-out.
We're not saying every security silicon project should target FIPS 140-3 Level 3 — Level 1 and Level 2 are the right targets for many applications. We're saying that the difference between "designed with FIPS 140-3 in mind" and "designed to pass FIPS 140-3 Level 3" is a set of specific, non-trivial RTL and physical design choices that must be made before tape-out, not retrofitted during certification testing.