FIPS 140-3, Security Requirements for Cryptographic Modules, is the active Federal Information Processing Standard that supersedes FIPS 140-2. It aligns with the international standard ISO/IEC 19790:2012, adding specific U.S. government requirements. The standard defines four Security Levels (Level 1 to Level 4) that specify increasing degrees of physical and logical protection for the cryptographic boundary, key management, and authentication mechanisms.
Glossary
FIPS 140-3

What is FIPS 140-3?
FIPS 140-3 is the current U.S. government standard that specifies the security requirements for cryptographic modules, defining four increasing, qualitative security levels to accredit their design and implementation.
Validation under FIPS 140-3 is performed by accredited Cryptographic Module Validation Program (CMVP) laboratories. A critical component is the FIPS 140-3 Derived Test Requirements (DTR) , which maps the standard's assertions to concrete vendor tests. For sovereign AI infrastructure, a FIPS 140-3 Level 3 validated Hardware Security Module (HSM) ensures that cryptographic keys used for model attestation and data encryption are protected by a tamper-resistant, self-destructing physical boundary.
Frequently Asked Questions
Clear, technically precise answers to the most common questions about the FIPS 140-3 cryptographic module validation standard, its security levels, and its role in sovereign AI infrastructure.
FIPS 140-3, titled 'Security Requirements for Cryptographic Modules,' is the current U.S. government standard for accrediting cryptographic modules, superseding FIPS 140-2. The critical architectural difference is that FIPS 140-3 aligns its core requirements with the international standard ISO/IEC 19790:2012, harmonizing U.S. and global certification processes. It introduces a two-part validation structure: the ISO-derived base standard and a companion document, NIST SP 800-140x, which contains specific U.S. requirements and allowed algorithm lists. Key technical additions include mandatory side-channel attack testing for higher security levels, formalized non-invasive security requirements, and stricter software/firmware integrity verification using approved digital signatures. The transition eliminates the 'grandfathering' of older algorithms, mandating only NIST SP 800-131A Rev. 2 compliant algorithms. For vendors, this means a more rigorous, evidence-based testing methodology conducted by accredited Cryptographic Module Validation Program (CMVP) laboratories, replacing the checklist-driven approach of its predecessor.
FIPS 140-3 Security Levels
FIPS 140-3 defines four increasing, qualitative security levels that specify the design and implementation requirements for cryptographic modules. Each level builds upon the previous one, adding stricter physical security, identity-based authentication, and environmental protection mechanisms.
Level 1: Basic Algorithmic Security
The foundational level requiring only approved algorithms and correct implementation. No physical security mechanisms are mandated beyond basic production-grade components.
- Approved algorithms only: AES, SHA, ECDSA, and other NIST-validated functions
- Software-only execution permitted on general-purpose hardware
- No physical tamper resistance required
- Example: A software library running encryption on a standard server
- Typical use case: Encrypting data at rest on a commodity operating system
Level 2: Tamper Evidence & Role-Based Access
Adds requirements for tamper-evident coatings or seals and enforces role-based authentication for operators. The module must provide visible evidence of any physical access attempt.
- Tamper-evident seals or pick-resistant coatings required on removable covers
- Role-based authentication: Operators must authenticate to assume a role (e.g., Crypto Officer vs. User)
- Software modules must run on an OS with Common Criteria EAL2 or equivalent
- Example: A PCIe HSM card with a breakable seal over the enclosure screws
- Typical use case: Enterprise key management appliances in a controlled data center
Level 3: Tamper Resistance & Identity Authentication
Requires hardened physical security that zeroizes critical security parameters upon detected intrusion. Identity-based authentication replaces simple role-based access.
- Tamper-resistant enclosure: Must resist probing and automatically zeroize all plaintext CSPs when tampering is detected
- Identity-based authentication mandatory—each operator has a unique identity
- Critical Security Parameters (CSPs) must be encrypted when exported and physically separated from logical access paths
- Example: A FIPS 140-3 Level 3 HSM that erases its master key if the chassis is opened
- Typical use case: Payment HSM in a PCI DSS environment or certificate authority root key protection
Level 4: Environmental Failure Protection
The highest assurance level, designed for operation in physically unprotected environments. The module must detect and respond to environmental anomalies that could compromise security.
- Environmental Failure Protection (EFP): Detects voltage and temperature fluctuations outside normal operating ranges and zeroizes CSPs immediately
- Complete envelope of protection: The entire cryptographic boundary must resist sophisticated physical attacks including fault injection
- Designed for field-deployed, unattended equipment where physical security cannot be guaranteed
- Example: A military-grade encryption module that self-destructs its key material if cooled below a threshold for a cold-boot attack
- Typical use case: Satellite communication cryptosystems, battlefield tactical radios, or ATM cash-dispensing modules in unguarded locations
Key Differences from FIPS 140-2
FIPS 140-3 aligns with the international ISO/IEC 19790:2012 standard, introducing significant structural changes from its predecessor FIPS 140-2.
- ISO alignment: FIPS 140-3 is a profile of ISO/IEC 19790, enabling mutual recognition with international Common Criteria schemes
- Mandatory SP 800-56B compliance for RSA key transport, eliminating legacy padding schemes
- Non-invasive security testing is now explicitly required at all levels, not just Level 3 and 4
- Software/firmware security requirements are now defined in a separate standard (ISO/IEC 24759) and referenced normatively
- Self-tests expanded to include pairwise consistency tests for both signature generation and verification keys
- Transition deadline: All FIPS 140-2 certificates sunset on September 21, 2026, making migration mandatory for federal systems
Certification Process & CMVP
The Cryptographic Module Validation Program (CMVP)—jointly run by NIST and the Canadian Centre for Cyber Security—validates modules against FIPS 140-3.
- Accredited laboratories: Testing is performed by 23 NVLAP-accredited CST laboratories (as of 2024)
- Algorithm validation prerequisite: All cryptographic algorithms must first receive CAVP certificates before module testing begins
- Documentation package: Vendors submit a security policy, finite state model, and source code for review
- Typical timeline: 9–18 months from submission to certificate issuance, depending on complexity and lab backlog
- Certificate lookup: All validated modules are listed on the NIST CMVP website with their exact operational configurations and security policy documents
- Revalidation triggers: Any hardware revision, firmware update affecting security, or algorithm change requires revalidation
Enabling Efficiency, Speed & Accuracy
Intelligent Analysis, Decision & Execution
We build AI systems for teams that need search across company data, workflow automation across tools, or AI features inside products and internal software.
Talk to Us
Search across company data
Give teams answers from docs, tickets, runbooks, and product data with sources and permissions.
Useful when people spend too long searching or get different answers from different systems.

Automate internal workflows
Use AI to route work, draft outputs, trigger actions, and keep approvals and logs in place.
Useful when repetitive work moves across multiple tools and teams.

Add AI to products and internal tools
Build assistants, guided actions, or decision support into the software your team or customers already use.
Useful when AI needs to be part of the product, not a separate tool.
FIPS 140-2 vs. FIPS 140-3
Key differences between the superseded FIPS 140-2 standard and the current FIPS 140-3 standard, which aligns with ISO/IEC 19790:2012.
| Feature | FIPS 140-2 | FIPS 140-3 |
|---|---|---|
Underlying Standard | Proprietary U.S. government framework | ISO/IEC 19790:2012 with NIST SP 800-140 series modifications |
Security Levels | 4 qualitative levels (Level 1-4) | 5 qualitative levels (Level 1-4 plus new Software Level 1) |
Module Types | Hardware, firmware, software, hybrid | Hardware, firmware, software, hybrid, plus non-cryptographic module boundary |
Self-Tests | Pre-operational known-answer tests and conditional tests | Pre-operational integrity tests, known-answer tests, and conditional tests with extended coverage |
Algorithm Validation | Referenced FIPS-approved algorithms | Mandatory CAVP validation for all approved algorithms; non-approved algorithms require explicit justification |
Key Management | Basic key zeroization requirements | Enhanced key zeroization, key establishment SP 800-56B/C compliance, and mandatory key lifecycle documentation |
Documentation Requirements | Finite state model and security policy | Extended finite state model, mandatory non-proprietary security policy, and entropy source documentation |
Operational Environment | Single OS per validation | Multi-chip embedded, single-chip, and firmware-loadable modules with expanded OS coverage |
Entropy Source Validation | Not explicitly required | Mandatory entropy source validation per SP 800-90B for all random bit generators |
Transition Timeline | Active until September 2026 | Mandatory for new submissions after September 2021; all FIPS 140-2 certificates sunset September 2026 |
Related Terms
FIPS 140-3 validation exists within a broader framework of hardware security standards, testing methodologies, and implementation technologies. These related concepts define the ecosystem for certifying and deploying cryptographic modules in sovereign AI infrastructure.
Common Criteria (CC)
An international standard (ISO/IEC 15408) for computer security certification that provides a framework for specifying security requirements and independently evaluating products. While FIPS 140-3 focuses specifically on cryptographic modules, Common Criteria addresses broader system security:
- Protection Profiles: Standardized security requirement sets
- Evaluation Assurance Levels (EAL1-EAL7): Increasing rigor of testing
- Mutual Recognition: Certificates recognized across 31 nations
Organizations often require both FIPS 140-3 and Common Criteria certification for defense and critical infrastructure deployments.
NIST SP 800-53
The security and privacy controls framework that mandates the use of FIPS 140-validated cryptography within U.S. federal information systems. Key control families include:
- SC-13: Cryptographic Protection — explicitly requires FIPS-validated modules
- SC-12: Cryptographic Key Establishment and Management
- SA-10: Developer Configuration Management
Sovereign AI infrastructure inherits these controls when deployed for government workloads, making FIPS 140-3 validation a prerequisite for federal contract compliance.
Cryptographic Algorithm Validation Program (CAVP)
A prerequisite program that validates the correctness of individual cryptographic algorithms before a module can undergo FIPS 140-3 testing. The CAVP process:
- Tests algorithm implementations against NIST test vectors
- Issues separate certificates for each approved algorithm
- Covers AES, RSA, ECDSA, SHA-3, and DRBG implementations
A FIPS 140-3 certificate requires that all embedded cryptographic algorithms have valid CAVP certificates, establishing a two-tier validation hierarchy.
ISO/IEC 19790:2012
The international standard upon which FIPS 140-3 is directly based, harmonizing U.S. requirements with global cryptographic module evaluation criteria. The relationship includes:
- FIPS 140-3 adopts ISO/IEC 19790 as its normative core
- Adds NIST-specific annexes for U.S. government requirements
- Enables mutual recognition with other national schemes
This alignment allows module vendors to pursue both FIPS and international certifications with reduced duplicate testing effort.
Entropy Source Validation
A mandatory component of FIPS 140-3 testing that verifies the quality and unpredictability of random bit generation. Entropy sources must demonstrate:
- Min-entropy estimation: Statistical proof of randomness density
- Health tests: Continuous monitoring for entropy failure
- Independent testing: Per NIST SP 800-90B requirements
Weak entropy undermines all cryptographic operations. FIPS 140-3 requires validated entropy sources at all security levels, with Level 4 demanding the most stringent physical entropy verification.

About the author
Prasad Kumkar
CEO & MD, Inference Systems
Prasad Kumkar is the CEO & MD of Inference Systems and writes about AI systems architecture, LLM infrastructure, model serving, evaluation, and production deployment. Over 5+ years, he has worked across computer vision models, L5 autonomous vehicle systems, and LLM research, with a focus on taking complex AI ideas into real-world engineering systems.
His work and writing cover AI systems, large language models, AI agents, multimodal systems, autonomous systems, inference optimization, RAG, evaluation, and production AI engineering.
Partnered with leading AI, data, and software stack.
How We Work
Custom AI workflows for your Business
One-fit-all AI don't work for modern businesses. At Inferensys, we aim to understand your business & custom requirements; which we use to define most efficient agentic workflows, the data, and the tools for your business.
01
Review the use case
We understand the task, the users, and where AI can actually help.
Read more02
Pick the right approach
We define what needs search, automation, or product integration.
Read more03
Build the first useful version
We implement the part that proves the value first.
Read more04
Improve from there
We add the checks and visibility needed to keep it useful.
Read moreThe first call is a practical review of your use case and the right next step.
Talk to Us