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

Key Takeaways

• FIPS 140-3 is now the active standard - NIST officially replaced FIPS 140-2 with FIPS 140-3 in 2019, and the transition deadline for new validations has passed, making 140-3 the benchmark for cryptographic module compliance in U.S. federal environments.
• FIPS 140-3 is aligned with ISO/IEC 19790, meaning it carries more international credibility and harmonizes cryptographic security requirements across global standards bodies.
• Four security levels remain, but the requirements at each level are stricter, especially around physical security, key management, and algorithm approval.
• The transition affects everything - from cloud services like AWS KMS and Azure Key Vault, to hardware like HSMs and encrypted USB drives, to open-source tooling like OpenSSL and BouncyCastle.
• FIPS 140-3 compliance isn't automatic - vendors must go through CMVP (Cryptographic Module Validation Program) testing before a product can appear on the NIST FIPS 140-3 compliant list.

What Is FIPS 140-3?

FIPS 140-3 - formally titled FIPS PUB 140-3: Security Requirements for Cryptographic Modules - is the current U.S. federal standard governing the design and testing of cryptographic modules used in sensitive but unclassified applications. Published by NIST (National Institute of Standards and Technology), it defines how hardware, software, and firmware components must protect cryptographic keys, manage entropy, and behave under attack.

The standard applies to any organization that handles federal data, including government agencies, defense contractors, healthcare organizations subject to HIPAA, and financial institutions that interface with federal systems. When a procurement requirement says "FIPS 140 compliant," FIPS 140-3 is now the spec you need to meet.

Unlike FIPS 197, which defines the AES algorithm itself, FIPS 140-3 governs the module that implements cryptographic operations - meaning the environment, the interfaces, the key lifecycle, and the physical or logical protections around the cryptography. It is the broader container standard, not an algorithm-level specification.

FIPS 140-3 vs. FIPS 140-2: What Changed?

The most important upgrade in FIPS 140-3 is its alignment with ISO/IEC 19790:2015 and ISO/IEC 24759, the international standards for cryptographic module testing. This shift eliminated the parallel-but-divergent structure that made cross-border compliance expensive and confusing. For global vendors, a product that satisfies ISO/IEC 19790 now maps far more cleanly to FIPS 140-3 than it ever did to FIPS 140-2.

Beyond harmonization, the key differences between FIPS 140-2 and FIPS 140-3 include:

Algorithm requirements. FIPS 140-3 tightens approved algorithm lists and removes legacy ciphers that FIPS 140-2 still permitted under certain conditions. SHA-1 is no longer acceptable for most use cases, and deprecated key lengths for RSA and elliptic curve are excluded. Post-quantum cryptography (PQC) is now on the roadmap for future guidance.

Non-invasive attack testing. FIPS 140-3 introduces explicit requirements for resistance to side-channel attacks - including power analysis, electromagnetic analysis, and timing attacks - at higher security levels. FIPS 140-2 addressed this only loosely.

Key zeroization and lifecycle. The 140-3 standard adds more granular requirements for how cryptographic keys are zeroed from memory, how long interim values can persist, and what triggers a secure erasure event.

Logical interface model. FIPS 140-3 introduces a revised logical interface model with clearer delineation between trusted channels and trusted paths - concepts that weren't explicitly separated under 140-2. This has practical implications for module design: inputs and outputs that flow through controlled interfaces must now be classified and handled differently depending on whether they represent data-in-transit or operator commands.

Implementation Guidance (IG). NIST continues to publish FIPS 140-3 Implementation Guidance (IG) documents to clarify edge cases and evolving interpretations. These IGs are living references that affect how labs assess submissions, and staying current with the latest IG is essential for any vendor pursuing validation.

For a deeper look at how scanning tools handle validated versus non-validated modules, our post on scanner misreads in security tooling is worth reviewing - misidentification of FIPS module status is a real source of false positives and false negatives in compliance pipelines.

FIPS 140-3 Security Levels Explained

FIPS 140-3 defines four security levels, each building on the requirements of the previous:

Level 1 is the baseline. It requires that approved cryptographic algorithms are used correctly, but imposes no physical security requirements. A software-only module running on a general-purpose OS can achieve Level 1 if its cryptographic logic is sound. Most cloud-hosted services start here.

Level 2 adds tamper-evidence - typically physical seals, coatings, or enclosures that show visible signs of unauthorized access. It also requires role-based authentication for operators. Many FIPS 140-2 Level 2 validated products, including smartcards and some encrypted USB drives, are making the migration to Level 2 under the new standard.

Level 3 is where physical security becomes active, not just passive. The module must detect and respond to tampering - not merely show evidence of it. Zeroization of critical security parameters (CSPs) must occur automatically when intrusion is detected. FIPS 140-2 Level 3 was a common target for HSMs (hardware security modules), and FIPS 140-3 Level 3 remains the benchmark for products like the AWS CloudHSM, Azure Key Vault Premium, and enterprise HSMs from vendors like Thales and Entrust.

Level 4 is the highest tier and is reserved for the most sensitive environments. It requires protection against environmental attacks - including voltage and temperature extremes - and comprehensive physical security envelopes. Level 4 modules are rare, expensive, and typically deployed only in classified or high-assurance government contexts.

It's worth noting: there is no FIPS 140-3 Level 5. Some search queries reflect confusion between FIPS levels and DNS security or biometric module specifications - those are entirely separate frameworks.

FIPS 140-3 and the CMVP: How Validation Works

The Cryptographic Module Validation Program (CMVP) is administered jointly by NIST and the Canadian Centre for Cyber Security (CCCS). It is the gating process that determines whether a product earns a place on the official FIPS 140-3 validated modules list.

Vendors submit their module to an accredited Cryptographic and Security Testing (CST) laboratory. Testing is conducted against the FIPS 140-3 standard and the associated Implementation Guidance. Once the lab approves the module, it moves into the NIST review queue, and upon final approval, the module appears on the CMVP validation list with a certificate number, validation date, and module description.

The FIPS 140-3 certification list is publicly searchable at the NIST CMVP website. It's the authoritative source for confirming whether a specific product version - not just a product line - holds a valid FIPS 140-3 certificate. Version specificity matters: an older firmware version of an HSM may be listed while the latest firmware awaits validation.

For teams running containerized workloads, this version-dependency creates real complexity. Our article on container image vulnerabilities and DevSecOps best practices covers how to track cryptographic module versions in image-based deployments and avoid shipping containers that silently drop FIPS-validated paths.

FIPS 140-3 in Cloud Environments

Cloud providers have been active participants in FIPS 140-3 validation, particularly for their key management and HSM services.

AWS KMS uses FIPS 140-2 Level 2 validated HSMs for most operations, with FIPS 140-2 Level 3 validated hardware for AWS CloudHSM. AWS is progressing toward FIPS 140-3 validations across its LC (AWS-LC) cryptographic library. The AWS-LC FIPS 140-3 certificate marks a significant step for teams relying on AWS for cryptographic operations under federal compliance requirements.

Azure Key Vault offers two tiers: the standard tier uses software-protected keys, while the Premium tier uses FIPS 140-2 Level 3 validated HSMs. Microsoft is actively pursuing FIPS 140-3 alignment, and organizations on Azure should verify the current validation status of the specific Key Vault tier they're using.

Google Cloud has published documentation confirming FIPS 140-2 Level 1 compliance for its software cryptographic modules, with certain services achieving Level 2 or Level 3 through underlying hardware.

For SASE (Secure Access Service Edge) vendors, the picture varies. Some vendors such as Zscaler and Cato Networks advertise FIPS 140-2 Level 3 compliance for their encryption pipelines, but buyers in regulated industries should request the specific CMVP certificate numbers - not just compliance claims - when evaluating SASE solutions with FIPS 140-2 Level 3 encryption capabilities.

FIPS 140-3 in Open-Source Cryptography

OpenSSL has been one of the most closely watched open-source projects in the FIPS 140-3 transition. The OpenSSL 3.0 FIPS provider received FIPS 140-3 validation, and Lightship Security's work on OpenSSL 3.5 validation continues the lineage. Teams using OpenSSL should verify which version and provider configuration is covered by the current certificate - the OpenSSL FIPS 140-3 validation status for 2025 shows active maintenance of the certification.

BouncyCastle - the widely used Java and C# cryptographic library - has pursued FIPS 140-3 validation through its FIPS-specific API distribution. The Bouncy Castle FIPS 140-3 module is distinct from the standard BC library and requires explicit dependency configuration.

Go (Golang) has added native FIPS 140-3 support in recent releases through the GOFIPS140 environment variable, enabling a FIPS-compliant build mode. The golang FIPS 140-3 integration allows Go applications to use a validated cryptographic module without significant refactoring.

Ubuntu ships with FIPS 140-3 validated modules available through Ubuntu Pro subscriptions, covering kernel crypto, OpenSSL, and libgcrypt. RHEL 9 similarly provides FIPS 140-3 packages through Red Hat subscriptions.

The importance of using validated, unmodified cryptographic libraries extends to container base images. Hardened base images that ship FIPS-validated module paths are a prerequisite for any containerized workload that needs to remain in compliance scope - a topic covered in detail in our piece on why hardened images matter.

FIPS 140-3 and Post-Quantum Cryptography (PQC)

One of the more forward-looking aspects of FIPS 140-3 is its architecture for incorporating post-quantum cryptographic algorithms. NIST has finalized its first set of PQC standards (ML-KEM, ML-DSA, SLH-DSA), and the FIPS 140-3 framework is being extended to support validation of modules implementing these algorithms.

For organizations beginning post-quantum migration planning, FIPS 140-3 compliance and PQC readiness are increasingly linked. Any module that will eventually support quantum-resistant algorithms should be validated under FIPS 140-3 - not FIPS 140-2 - to avoid re-validation when PQC requirements are formalized.

FIPS 140-3: Hardware Products

The hardware market for FIPS 140-3 validated products spans several categories:

Encrypted USB drives - Products like Apricorn's Aegis Secure Key 3.0, the Kingston DataTraveler 4000 G2, and IronKey drives have historically targeted FIPS 140-2 Level 3 certification. Migration to FIPS 140-3 validated drives is ongoing, and buyers should check the CMVP list for current certificate status. Specifications like "FIPS 140-2 Level 3 USB drive" and "FIPS 140-2 Level 3 flash drive" are still valid for legacy-compliant products, but procurement teams for new deployments should target FIPS 140-3 validated hardware.

Hardware Security Modules (HSMs) - Thales, Entrust, SafeNet, and Utimaco produce HSMs with FIPS 140-2 Level 3 and Level 4 validations. FIPS 140-3 HSM certifications are emerging from this cohort and should be confirmed directly with vendor documentation.

Encrypted SSDs - FIPS 140-2 Level 2 or Level 3 validated SSDs are used in government laptops, classified workstations, and ruggedized field devices. Migration to FIPS 140-3 validated SSDs is part of the longer hardware refresh cycle.

Security keys and tokens - YubiKey FIPS series and similar products from vendors like Athena IDProtect hold FIPS 140-2 Level 3 certifications. The YubiKey FIPS 140-3 program is in progress.

FIPS 140-3 Transition Timeline

NIST published FIPS 140-3 in May 2019. The transition period allowed FIPS 140-2 validations to continue until September 21, 2021, after which CMVP stopped accepting new FIPS 140-2 submissions. Existing FIPS 140-2 certificates remain on the active list until their five-year validation period expires - meaning some FIPS 140-2 certificates issued before the cutoff are still technically active as of 2025–2026, but no new FIPS 140-2 certifications are being issued.

For organizations asking "when is FIPS 140-3 required?" - if you are procuring or deploying new cryptographic modules for federal use, FIPS 140-3 is required now. Legacy deployments running FIPS 140-2 validated modules may continue until those certificates expire, but any new procurement should target FIPS 140-3 validated products.

How Echo Helps Teams Meet FIPS 140-3 Compliance in Containerized Environments

FIPS 140-3 compliance at the cryptographic module level is only part of the picture for modern software teams. For organizations running containerized workloads, compliance also has to hold at the image layer - and that's where most teams run into trouble.

Most public base images ship with unvalidated cryptographic libraries or OpenSSL builds that aren't configured to run in FIPS mode. Even when engineers know to look for this, verifying library versions against the CMVP list, configuring the FIPS provider correctly, and keeping that configuration intact across rebuilds is ongoing, manual work. And when a new CVE touches a cryptographic package, the clock starts ticking - FedRAMP's continuous monitoring requirements expect high and critical vulnerabilities to be remediated within seven days.

Echo provides FIPS-validated and STIG-hardened base images that are pre-configured for compliance out of the box. There's no manual hardening step, no OpenSSL provider configuration to manage, and no need to cross-reference the CMVP list for every image update. Echo delivers patched images directly to your existing registry, so engineering teams don't change their workflow - they just pull from Echo's registry the same way they would from any other source.

The differentiator that matters most for compliance and security teams is Echo's 7-day SLA on high and critical CVEs. This is a contractual commitment, not a best-effort target - and it maps directly to what FedRAMP continuous monitoring requires. For organizations pursuing FedRAMP authorization, CMMC certification, or federal contracts where FIPS 140-3 is a procurement requirement, that gap matters.

Echo is already trusted by Fortune 500 companies including Varonis, EDB, and UiPath. For teams that want FIPS 140-3 compliance at the container layer without building and maintaining it themselves, it's worth evaluating.

FAQ

What is FIPS 140-3? FIPS 140-3 is a U.S. federal standard published by NIST that defines security requirements for cryptographic modules - hardware, software, or firmware components that implement encryption, hashing, key generation, or authentication. It replaced FIPS 140-2 in 2019 and is aligned with ISO/IEC 19790. Any vendor selling cryptographic products to the U.S. federal government must achieve FIPS 140-3 validation through the CMVP program.

What is the difference between FIPS 140-2 and FIPS 140-3? FIPS 140-3 aligns with ISO/IEC 19790, adds requirements for non-invasive attack (side-channel) resistance, updates approved algorithm lists, and introduces clearer definitions for trusted channels versus trusted paths. It also refines key zeroization requirements and removes deprecated algorithms still permitted under 140-2. The practical impact is that 140-3 sets a higher bar for physical security and cryptographic hygiene at every level.

What are the FIPS 140-3 security levels? There are four security levels. Level 1 requires correct use of approved algorithms with no physical security controls. Level 2 adds tamper-evidence and role-based authentication. Level 3 requires active tamper response, including automatic key zeroization on intrusion detection. Level 4 adds comprehensive environmental attack protection and is the highest assurance tier available under the standard.

What algorithms are approved for FIPS 140-3? Approved algorithms include AES (128, 192, 256-bit), SHA-2 and SHA-3 family hash functions, RSA (2048-bit minimum), ECDSA and ECDH on approved curves, HMAC, and DRBG-based random number generation. SHA-1 is approved only for specific legacy digital signature verification. AES-256 is FIPS 140-3 compliant when implemented in a validated module. Post-quantum algorithms are being incorporated following NIST's PQC standardization process.

Is TLS 1.3 FIPS 140-2/140-3 compliant? TLS 1.3 can be used in a FIPS-compliant context, but compliance depends on the underlying cryptographic module, not the protocol version itself. TLS 1.3 uses cipher suites that include FIPS-approved algorithms (AES-GCM, SHA-256, ECDHE), but the module implementing those operations must hold a FIPS 140-2 or FIPS 140-3 validation certificate. TLS 1.2 remains acceptable in FIPS environments when using approved cipher suites. Neither protocol version is inherently FIPS-validated - the module is.

Where can I find the FIPS 140-3 compliant list? The authoritative FIPS 140-3 validated modules list is maintained at the NIST CMVP website (csrc.nist.gov/projects/cryptographic-module-validation-program). The list is searchable by vendor, module name, validation date, and security level. Always verify the specific module version and certificate status rather than assuming a product line is uniformly covered - validation is version-specific.

When is FIPS 140-3 required? FIPS 140-3 is required for cryptographic modules used in federal information systems that process sensitive but unclassified information, per OMB guidelines and NIST SP 800-171 for contractors. It is also referenced in compliance frameworks including FedRAMP, CMMC (Cybersecurity Maturity Model Certification), and some financial regulatory requirements. For new product deployments, FIPS 140-3 is the current standard - no new FIPS 140-2 validations have been issued since 2021.

For questions about how FIPS 140-3 validation status interacts with container security, scanner tooling, and hardened base images, see our related resources on hardened images, scanner misreads, and container image vulnerabilities in DevSecOps.