FIPS 140-3 is the current U.S. federal standard for validating cryptographic modules — the hardware and software components that perform encryption. It defines four security levels, and federal agencies are required to procure only FIPS-validated modules for protecting sensitive data.

What is the difference between FIPS 140-2 and FIPS 140-3?

FIPS 140-3 supersedes FIPS 140-2 and aligns with the international standards ISO/IEC 19790 and ISO/IEC 24759. Key improvements include stronger non-invasive attack resistance requirements, updated self-test requirements, and an expanded scope for software modules.

What are the four FIPS 140-3 security levels?

Level 1 requires only production-grade components. Level 2 adds tamper-evident seals and role-based authentication. Level 3 adds tamper-resistance and identity-based authentication. Level 4 is the highest, requiring a complete tamper-active envelope that destroys the module upon physical intrusion.

The Cryptographic Module Validation Program (CMVP) is a joint effort by NIST and the Canadian Centre for Cyber Security (CCCS) that tests and certifies cryptographic modules against FIPS 140-3. Only modules on the CMVP's validated module list may be used in federal systems.

Which FIPS 140-3 level do most organizations need?

Most commercial and government applications use Level 1 or Level 2. Level 2 is the typical minimum for hardware security modules (HSMs) handling sensitive keys. Level 3 is required by programs like PIV (federal identity cards) and payment HSMs. Level 4 is rare and used only for the most extreme environments.

How long does FIPS 140-3 certification take?

Validation timelines through the CMVP typically range from six months to over two years depending on the module's complexity, the accredited testing laboratory's queue, and the completeness of the vendor's documentation. Active validation queues are publicly tracked on the NIST CMVP website.

FIPS 140-3 Explained: Cryptographic Module Validation Levels

Introduction

When a federal employee swipes a smart card to access a classified system, or when a bank processes an encrypted wire transfer, the cryptography protecting that transaction runs inside a validated cryptographic module. But not every encryption library is created equal — and the U.S. federal government has spent decades building a rigorous, internationally recognized framework to separate production-grade cryptographic implementations from the rest.

That framework is FIPS 140-3. The Federal Information Processing Standard 140-3 is the current mandatory benchmark for any cryptographic hardware or software used in U.S. federal government systems handling sensitive unclassified information. If a vendor wants to sell a security product to a federal agency, the cryptographic module inside it must have a NIST certification number on the Cryptographic Module Validation Program (CMVP) list.

The standard defines four ascending levels of physical security and assurance, each addressing a more sophisticated threat model. Understanding these levels is not just a procurement checkbox — it is a framework for accurately assessing the physical and logical security of any encryption system, from a laptop’s software TPM to a bank vault’s dedicated hardware security module.

What Is FIPS 140-3?

FIPS 140-3, Security Requirements for Cryptographic Modules, is a joint NIST and Canadian Centre for Cyber Security (CCCS) standard that defines the security requirements for cryptographic modules — the hardware, software, or firmware components that implement approved security functions such as encryption, decryption, hashing, key generation, and random number generation.

A cryptographic module as defined by FIPS 140-3 is a set of hardware, software, and/or firmware that implements approved security functions and is contained within a defined cryptographic boundary. The boundary determines precisely what is part of the module and therefore subject to evaluation. Everything outside the boundary is untrusted.

FIPS 140-3, which became effective in September 2019, formally supersedes FIPS 140-2 (published in 2001). Its key architectural improvement is alignment with the international standard ISO/IEC 19790:2012, meaning a module validated against FIPS 140-3 is simultaneously conformant with the international cryptographic module standard — a significant advantage for multinational vendors.

The validation authority is the CMVP (Cryptographic Module Validation Program), which maintains a public list of all validated modules. Any module on the “Active” list can legally be procured for federal use.

How FIPS 140-3 Works

The FIPS 140-3 standard organizes requirements into eleven areas:

Cryptographic module specification
Module interfaces
Roles, services, and authentication
Software/firmware security
Operational environment
Physical security
Non-invasive security
Sensitive security parameter management
Self-tests
Life-cycle assurance
Mitigation of other attacks

Across these eleven areas, modules are assessed at one of four security levels. Higher levels impose stricter requirements in each area, most significantly in physical security and authentication. A module can achieve different levels in different areas, resulting in an overall level that is the minimum of all area scores.

RSA Conference's concise overview covers the key changes from FIPS 140-2, the four security levels, and what the transition means for vendors and procurers.

FIPS 140-3 Security Levels vs Use Cases

The four security levels are not merely incremental — each targets a qualitatively different threat model and physical deployment scenario.

Security Level	Physical Security	Authentication	Typical Use Case
Level 1	Production-grade components; no physical security mechanism required.	Role-based (operator vs user).	Software modules on a general-purpose OS (e.g., OpenSSL validated build).
Level 2	Tamper-evident coatings, seals, or pick-resistant locks.	Role-based authentication.	Rack-mounted HSMs in a physically controlled data centre.
Level 3	Tamper-resistance: must actively prevent access to critical security parameters (CSPs).	Identity-based authentication (e.g., PIN + smart card).	PIV cards, payment HSMs, network encryption appliances.
Level 4	Tamper-active: complete envelope; zeroises all CSPs upon any physical intrusion attempt.	Identity-based authentication; environmental protection.	Military, intelligence, and highest-risk financial deployments.

Level 4 modules must also protect against environmental attacks — if you heat, cool, or apply voltage fluctuations to the module, it is designed to detect the assault and immediately destroy all sensitive key material. This level is extremely rare and very expensive; fewer than two dozen modules have achieved it globally.

Real-World Use Cases

FIPS 140-3 validation requirements appear across every sector where the U.S. federal government has procurement or regulatory authority.

Federal Agency IT Systems: Under the Federal Information Security Modernization Act (FISMA) and NIST SP 800-53, all federal agencies must use FIPS-validated cryptographic modules to protect Controlled Unclassified Information (CUI). This means that procurement officers at the Department of Defense, VA, or the IRS must verify CMVP validation before approving any security product with cryptographic components — including VPN gateways, database encryption engines, and endpoint security software.

Payment Card Industry (PCI DSS): The PCI Security Standards Council mandates that hardware security modules used for PIN block encryption and key loading meet at least FIPS 140-2 Level 3 (with many issuers requiring Level 4 for the most sensitive certificate authority modules). FIPS 140-3 Level 3 is now the target for new deployments.

Healthcare and HIPAA: While HIPAA does not mandate FIPS 140-3 by name, the HHS Office for Civil Rights has stated that encryption meeting FIPS standards constitutes the “safe harbour” that renders encrypted patient data a non-reportable breach. Health systems seeking to minimize regulatory liability during a breach increasingly specify FIPS 140-2 or 140-3 validated modules in their security policies.

Common Mistakes to Avoid

The most dangerous mistake procurement and compliance teams make is confusing FIPS-approved algorithms with FIPS-validated modules. Using AES-256, SHA-384, or RSA-4096 does not make your system FIPS compliant. The standard requires that the specific cryptographic module (the library or hardware device) implementing those algorithms has itself been validated by the CMVP. An open-source OpenSSL build using AES-256 is not FIPS 140-3 validated; the separately submitted and validated FIPS Object Module for OpenSSL is.

A second critical error is referencing outdated validation certificates. CMVP certificates are time-limited and can be revoked if a critical vulnerability is discovered in the module. Always query the CMVP database directly and verify that the certificate status is “Active” — never rely on a vendor’s marketing materials to confirm current validity.

Organizations also frequently overlook the operational environment requirement. A software module validated for a specific operating system version (e.g., Red Hat Enterprise Linux 9.0) may not be valid on a different version or distribution. Running a validated module on an untested environment disqualifies it from being considered “in FIPS mode,” potentially invalidating your compliance posture.

Getting Started

Achieving and maintaining FIPS 140-3 compliance is a structured process with clear milestones for both vendors and procurers.

For procurers — consult the CMVP validated modules list: Before purchasing any security product, verify its module number at csrc.nist.gov/Projects/Cryptographic-Module-Validation-Program/Validated-Modules. Filter by algorithm, security level, and status “Active.”
Match the security level to your threat model: Use Level 1 for pure software on a locked-down system, Level 2 for physically controlled server environments, Level 3 for anything requiring tamper-resistance and strong authentication (HSMs, smart cards), and Level 4 only for extreme national security or high-value financial applications. That tamper-resistant foundation is the same concept covered in our guide on the hardware root of trust.
For vendors — engage an accredited testing laboratory: FIPS 140-3 validation must be performed by a NIST-accredited Cryptographic and Security Testing (CST) laboratory. The labs are listed on the NIST CMVP website. Engage early — lab queues routinely extend 12–18 months.
Enable FIPS mode correctly: Many validated modules ship in a “FIPS mode” that must be explicitly enabled via configuration. Ensure your deployment scripts and hardening guides enable FIPS mode and disable non-FIPS algorithms (such as MD5 for anything but legacy compatibility).
Plan for re-validation: Any change to the validated module — including a security patch that alters the cryptographic code path — may require re-validation or at minimum a CMVP-reviewed change report. Build this into your software development lifecycle.

FIPS 140-3 sits at the intersection of cryptographic theory and procurement law. To understand the hardware security modules that most commonly require Level 3 or 4 certification, see our guide on Hardware Security Modules: HSM vs KMS Explained.