Most conversations about FIPS 140-3 start with software: key management libraries, HSM appliances, cloud cryptographic services. For OEM silicon architects, that framing misses the point entirely. When the root-of-trust lives on a die you are taping out, the FIPS 140-3 evaluation path, the threat model, and the physical security requirements all look meaningfully different from what a hosted HSM vendor faces.
This article is aimed at SoC architects and security engineers who need to understand what FIPS 140-3 Level 3 actually requires at silicon level — not at the module boundary of a PCB-mounted HSM, but inside the RTL you are integrating into your design. It draws on zeroRISC's experience targeting FIPS 140-3 Level 3 for the OpenTitan-based root-of-trust IP core, and on the NIST CMVP documentation that governs the process.
FIPS 140-3 Is ISO/IEC 19790 — That Distinction Matters
FIPS 140-2 was a NIST-authored standard. FIPS 140-3, which replaced it for new submissions from September 2021 onward, adopts ISO/IEC 19790:2012 as its normative body with NIST SP 800-140x series as implementation guidance. This is not a minor editorial change. ISO/IEC 19790 reorganizes the requirement structure substantially, and the SP 800-140C document (non-invasive attack mitigation) introduces requirements that have direct silicon-level implications.
For OEMs integrating a root-of-trust block, the most operationally significant change from 140-2 to 140-3 is the treatment of non-invasive attacks. Under 140-2, physical security requirements at Levels 3 and 4 focused on tamper evidence and tamper response. Under 140-3 and SP 800-140C, there is now a structured requirement to address non-invasive attack vectors — including simple power analysis (SPA), differential power analysis (DPA), and electromagnetic analysis (EMA) — as part of physical security Level 3 conformance. An IP block that meets the old Level 3 physical security bar may not meet the new one without explicit countermeasures in RTL.
What Level 3 Requires at Silicon — Four Categories
FIPS 140-3 Level 3 adds requirements in four areas that are directly relevant to a silicon implementation:
Physical security mechanisms. The cryptographic boundary must provide tamper evidence and, at Level 3, include mechanisms that either prevent or detect unauthorized access and zeroize critical security parameters (CSPs) upon tamper detection. For silicon, this means on-chip tamper detection circuitry — voltage glitch sensors, clock frequency sensors, active shield mesh integrity — connected to a zeroization path that can clear key material before any attacker can extract it. This is not optional at Level 3; it is a hard conformance requirement per ISO/IEC 19790 §7.7.
Roles, services, and authentication. Level 3 requires identity-based authentication rather than role-based authentication. In silicon terms, this means the lifecycle controller must authenticate the operator before permitting critical state transitions. A simple JTAG unlock token is insufficient; the authentication mechanism must be bound to the specific device identity, typically via HMAC-authenticated commands over a challenge-response protocol.
Key management. CSPs must be protected in storage and in transit within the cryptographic boundary. For on-chip key storage, this means the OTP cells storing root key material must be within the cryptographic boundary, and access to them must be controlled by the same authenticated mechanisms governing other CSPs. Key derivation paths must be documented in the security policy.
Non-invasive attack mitigation (SP 800-140C). This is the most technically demanding addition for silicon. The IP block must include countermeasures against timing attacks, power analysis, and electromagnetic side-channel attacks at a level commensurate with the implementation's threat environment. The CMVP does not prescribe specific countermeasure implementations, but it requires that the developer demonstrate that known non-invasive attack techniques have been evaluated and mitigated.
The CMVP Validation Path for Silicon IP
NIST's Cryptographic Module Validation Program (CMVP) is the body that issues FIPS 140-3 validation certificates. The CMVP does not evaluate modules directly; it accredits independent testing laboratories (through NVLAP) who perform the actual conformance testing. For a silicon root-of-trust IP block, the validation scope is the cryptographic module itself — defined by its security policy, cryptographic boundary, and the physical implementation.
The validation path for an IP core has one significant challenge not present for software modules or HSM appliances: the cryptographic boundary. For a PCB-mounted HSM, the boundary is the module housing. For an IP core integrated into an SoC, the boundary must be precisely defined in terms of the RTL and the synthesized gate-level netlist. The security policy must describe how the boundary is maintained across process nodes and foundry implementations, since the same RTL may be synthesized at TSMC 28nm HPM or GF 22FDX.
A pre-validated IP block — one where the CMVP submission covers the RTL as the cryptographic module — addresses this by documenting the security policy at the RTL level, with the physical implementation parameters (foundry, node, operating conditions) treated as environmental assumptions. An OEM integrating such a block is responsible for maintaining those assumptions in their SoC design and tapeout; they are not responsible for re-running the CMVP laboratory evaluation from scratch.
We are not claiming that integrating a pre-validated IP block automatically certifies your SoC. The OEM SoC as a whole is not a FIPS 140-3 validated module unless the OEM runs their own module-level CMVP validation. What a pre-validated IP block provides is that the cryptographic core within your SoC is built on evaluated RTL, reducing the scope and duration of any module-level validation you may subsequently pursue.
SP 800-90B: The Noise Source Requirement That Blocks Most Designs
NIST SP 800-90B specifies the requirements for entropy sources used to seed deterministic random bit generators (DRBGs). Under FIPS 140-3, random bit generation must use an approved DRBG seeded by an SP 800-90B compliant entropy source. For a silicon root-of-trust, this requirement is frequently the longest-lead item in the validation process, because SP 800-90B entropy source compliance requires both a design-time analysis and empirical testing of the physical entropy source on silicon.
The SP 800-90B process involves: (1) a stochastic model of the entropy source describing the physical noise mechanism; (2) a health test suite running continuously on-chip that can detect if the entropy source degrades; (3) an IID (independent and identically distributed) or non-IID assessment run on actual silicon samples. The empirical testing requires physical silicon samples — this cannot be completed on simulation alone. This means that for a new design attempting to build its own entropy source, the SP 800-90B validation cannot be completed until post-silicon, adding 6-12 months to the overall timeline.
An IP core that ships with a pre-validated SP 800-90B entropy source eliminates this as a critical path item. The design documentation and test report accompany the RTL delivery; the OEM does not need to re-qualify the entropy source unless they modify the physical implementation in ways that affect the noise source operation.
Level 3 vs. Common Criteria EAL4+: Why Both May Be Required
OEMs in certain markets — automotive (ISO/SAE 21434), payment (PCI HSM), government procurement — encounter requirements for Common Criteria (CC) evaluation in addition to FIPS 140-3. CC EAL4+ and FIPS 140-3 Level 3 are not equivalent, and meeting one does not satisfy the other. They share some overlap in physical security requirements, but their evaluation methodologies, assurance levels, and documentation requirements differ substantially.
For silicon root-of-trust IP, CC evaluations typically target a Protection Profile — for hardware devices, often the BSI Protection Profile for Security Controllers (PP-0084) or the PP for Embedded Systems. A FIPS 140-3 Level 3 validation demonstrates conformance to NIST's cryptographic module standard; a CC EAL4+ evaluation under a relevant PP demonstrates a broader security assurance case. The two evaluations can share documentation artifacts (threat model, security architecture, test evidence), but they involve separate laboratory engagements and separate conformance claims.
A Concrete Scenario: The 18-Month Problem
Consider a SoC design team building a secure microcontroller targeting industrial IoT applications that will eventually require FIPS 140-3 Level 3 for a government procurement vertical. The team begins a clean-sheet boot ROM and cryptographic subsystem design. A reasonable timeline to CMVP validation looks like this:
- RTL design and verification: 12-18 months to achieve DV closure on the cryptographic subsystem
- SP 800-90B entropy source characterization: 6-12 months post-silicon, requiring multiple silicon revision iterations if the noise source does not pass IID assessment
- Security policy documentation and laboratory pre-evaluation: 3-6 months
- CMVP laboratory testing and queue wait time: 6-18 months (CMVP queue times have historically varied significantly)
The end-to-end timeline from design start to CMVP certificate: 27-54 months, with significant uncertainty in the SP 800-90B and CMVP queue stages. For a product with a competitive tape-out schedule, that timeline is typically unacceptable. Starting with an IP core whose CMVP validation documentation is complete and whose SP 800-90B entropy source has already been characterized collapses the OEM's exposure to the portions of the process they actually control.
What the Validation Certificate Actually Covers
A FIPS 140-3 certificate on an IP core specifies the cryptographic module boundary, the validated algorithms (listed in the CAVP Algorithm Validation certificates that accompany the module certificate), the operating environment assumptions, and the security level per requirement area. Reading a module certificate carefully is important: a module can achieve Level 3 overall while having individual requirement areas at Level 2 or Level 1, as long as the minimum level for the claimed overall level is met in the areas that govern that level.
For an OEM integrating the IP, the critical items to verify in the certificate documentation are: (1) that the cryptographic boundary definition is compatible with your SoC integration topology; (2) that the foundry and process node you are targeting fall within the operational environment assumptions; (3) that the algorithm approvals cover the specific algorithm instantiations your application requires — a certificate approving AES-256-GCM covers that specific mode, not other AES modes not listed. The security policy document, which is public per CMVP requirements, contains this detail.
The FIPS 140-3 validation process is one of the more rigorous conformance paths available for silicon cryptographic modules — and for OEMs that need to demonstrate that rigor to customers or regulators, having that documentation in place from the IP layer is meaningfully different from having it absent.