FIPS 140-3 became the active standard for cryptographic module validation on April 1, 2022. Since September 22, 2021, NIST no longer accepts new FIPS 140-2 validation submissions. If you’re procuring new cryptographic hardware or software, it must be validated against FIPS 140-3 — not 140-2.
But here’s what most people get wrong: existing FIPS 140-2 validations remain valid. Your current HSMs and crypto libraries don’t suddenly become non-compliant. The transition affects new validations, not existing ones. Understanding this distinction — and what actually changed between the standards — is critical for making procurement and compliance decisions.
What Changed: FIPS 140-2 vs FIPS 140-3
FIPS 140-3 is based on ISO/IEC 19790:2012 (international standard) rather than being a purely US-developed standard. This alignment means:
Structural Changes
| Aspect | FIPS 140-2 | FIPS 140-3 |
|---|---|---|
| Base standard | US-only (NIST) | ISO/IEC 19790:2012 (international) |
| Testing methodology | Derived Test Requirements (DTR) | ISO/IEC 24759:2017 |
| Security levels | 4 levels (1-4) | 5 levels (1-5) — but Level 5 not yet defined |
| Self-tests | Power-up tests required | Conditional + periodic self-tests (more granular) |
| Degraded operation | Not formally addressed | Explicitly defined — module can operate in degraded mode |
| Multi-factor auth | Not required at any level | Required at Level 4+ for operator authentication |
| Non-invasive attacks | Not addressed | Level 3+ must resist side-channel attacks |
What’s Actually Different in Practice
1. Side-channel resistance (Level 3+): FIPS 140-3 Level 3 explicitly requires resistance to non-invasive attacks (timing attacks, power analysis, electromagnetic emanation). FIPS 140-2 Level 3 didn’t address these. This means hardware vendors must demonstrate side-channel resistance during validation testing.
2. Conditional self-tests: Instead of running all self-tests at power-up (which can take 30+ seconds on some HSMs), FIPS 140-3 allows conditional tests that run only when specific algorithms are first used. This improves startup time.
3. Degraded mode of operation: If a self-test fails for one algorithm (say, RSA), the module can continue operating with other algorithms (AES, SHA) rather than shutting down entirely. This improves availability.
4. Software module validation improvements: FIPS 140-3 better addresses software-only cryptographic modules (like OpenSSL FIPS module) with clearer requirements for operational environments and integrity verification.
5. Approved algorithm list: FIPS 140-3 references SP 800-140 series for approved algorithms, which is updated more frequently than the old FIPS 140-2 annexes. This makes it easier to add new algorithms (like PQC) without revising the base standard.
The Security Levels Explained
Level 1: Basic Security
- Approved algorithms correctly implemented
- No physical security requirements
- Production-grade software module on standard hardware
- Example: OpenSSL FIPS provider running on a standard Linux server
- Use when: You need FIPS compliance for software encryption but don’t need physical tamper protection
Level 2: Tamper Evidence + Role-Based Auth
- Everything in Level 1, plus:
- Tamper-evident coatings or seals on the module
- Role-based operator authentication (not just physical access)
- OS must meet Common Criteria EAL2+ (or equivalent)
- Example: AWS KMS (multi-tenant, FIPS 140-2 Level 2 validated)
- Use when: Cloud-managed encryption, application-level key management
Level 3: Tamper Resistance + Identity-Based Auth
- Everything in Level 2, plus:
- Active tamper response (zeroize keys if physical intrusion detected)
- Identity-based authentication (not just roles — specific individuals)
- Physical separation between interfaces
- Resistance to non-invasive attacks (side channels) — NEW in 140-3
- Example: Thales Luna Network HSM, Entrust nShield, AWS CloudHSM
- Use when: CA private keys, payment processing (PCI PIN), government systems, any high-value key storage
Level 4: Environmental Protection
- Everything in Level 3, plus:
- Protection against environmental attacks (voltage glitching, temperature manipulation)
- Complete envelope of protection around the module
- Extremely rare — used in military/intelligence applications
- Example: Specialized military-grade modules (not commercially common)
- Use when: National security systems, classified environments
Who Needs FIPS Compliance?
Mandatory
- US Federal agencies — FISMA requires FIPS-validated modules for all cryptographic operations
- FedRAMP — cloud services for government must use FIPS-validated modules
- DoD/CMMC — defense contractors handling CUI must use FIPS-validated encryption
- Payment processing — PCI PIN Security requires FIPS 140-2 Level 3+ HSMs for PIN operations
Effectively Required (Auditors Expect It)
- Healthcare (HIPAA) — not explicitly mandated, but auditors reference FIPS as “reasonable safeguard”
- Financial services — regulators expect FIPS-validated encryption for data at rest and in transit
- SOC 2 — auditors frequently ask about FIPS validation as evidence of cryptographic controls
Optional But Valuable
- Any organization handling sensitive data — FIPS validation provides assurance that crypto is implemented correctly
- Vendor differentiation — “FIPS 140-3 validated” on your product spec sheet wins enterprise deals
Achieving FIPS Compliance: Practical Steps
Step 1: Determine Your Required Level
| Your Situation | Minimum Level |
|---|---|
| Software encryption for federal data | Level 1 |
| Cloud KMS for federal workloads | Level 2 |
| CA private keys (WebTrust audit) | Level 3 |
| Payment PIN processing | Level 3 |
| Classified/national security | Level 3-4 |
Step 2: Inventory Your Cryptographic Modules
Identify every component that performs cryptographic operations:
- TLS libraries (OpenSSL, BoringSSL, NSS, SChannel)
- HSMs (network, USB, cloud)
- Key management systems (KMS, Vault)
- Database encryption (TDE modules)
- Disk encryption (BitLocker, LUKS, dm-crypt)
- Application crypto libraries (Bouncy Castle, libsodium)
Step 3: Verify Validation Status
Check each module against the NIST CMVP validated modules list:
- URL: https://csrc.nist.gov/projects/cryptographic-module-validation-program/validated-modules
- Search by vendor, module name, or certificate number
- Check status: “Active” (valid), “Historical” (known issues), “Revoked” (don’t use)
Step 4: Enable FIPS Mode
Most crypto libraries have a “FIPS mode” that restricts operations to approved algorithms:
OpenSSL 3.x:
# /etc/ssl/openssl.cnf
[openssl_init]
providers = provider_sect
[provider_sect]
fips = fips_sect
base = base_sect
[fips_sect]
activate = 1
[base_sect]
activate = 1Java:
// Use FIPS-validated provider
Security.insertProviderAt(new BouncyCastleFipsProvider(), 1);
// Non-approved algorithms (MD5, DES) will throw exceptionsLinux (system-wide):
# RHEL/CentOS — enable FIPS mode at boot
fips-mode-setup --enable
# Requires reboot. All crypto operations system-wide use FIPS-validated modules.Step 5: Test Everything
Enabling FIPS mode breaks things. Common failures:
- Applications using MD5 for checksums (not security-critical, but FIPS rejects it)
- Legacy protocols requiring 3DES or RC4 (not approved)
- SSH connections using non-approved key exchange algorithms
- Database connections using non-approved cipher suites
- LDAP/AD connections using deprecated algorithms
Test in a non-production environment first. Fix all failures before enabling in production.
Step 6: Document and Maintain
For auditors, document:
- Which FIPS-validated modules are in use (certificate numbers)
- Which security level each module is validated at
- How FIPS mode is enforced (configuration, GPO, system settings)
- Process for verifying modules remain on the active validated list
- Process for updating when modules move to “Historical” status
Common Pitfalls
”FIPS-Compliant” vs “FIPS-Validated”
Vendors love saying “FIPS-compliant” or “FIPS-compatible.” These terms are meaningless for compliance purposes. Only “FIPS 140-2/3 Validated” with a CMVP certificate number counts. Always ask: “What is your CMVP certificate number?” and verify it on the NIST website.
Validation Lag
FIPS validation takes 12-24 months. The module being validated is often 1-2 versions behind the current release. This creates tension:
- Validated version: OpenSSL 3.0.8 (FIPS module 3.0.8)
- Current version: OpenSSL 3.2.1 (security patches, bug fixes)
You may need to run an older, validated version rather than the latest patched version. Monitor NIST’s “Implementation Under Test” (IUT) list for upcoming validations of newer versions.
FIPS Mode Breaks Monitoring
Your monitoring system uses MD5 checksums for file integrity checking. FIPS mode disables MD5. Monitoring breaks. Or your log aggregator uses a non-approved TLS cipher suite. Connection fails. Audit all systems that interact with FIPS-enabled infrastructure — not just the primary application.
FAQ
Q: Are existing FIPS 140-2 validations still valid? A: Yes. Existing 140-2 certificates remain valid indefinitely (unless revoked for cause). You don’t need to re-validate existing modules under 140-3. Only NEW validations must use 140-3.
Q: Can I use a FIPS 140-2 Level 3 HSM for new deployments? A: Yes — the HSM’s validation is still active. But if you’re procuring NEW hardware, vendors should be offering 140-3 validated models. Ask about their 140-3 validation timeline.
Q: Does FIPS compliance mean my system is secure? A: FIPS validates that cryptographic operations are implemented correctly. It doesn’t validate your overall system architecture, access controls, network security, or operational procedures. FIPS is one layer of assurance, not a complete security certification.
Q: What about post-quantum algorithms and FIPS? A: FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA) are published. Cryptographic modules implementing these algorithms can now seek FIPS 140-3 validation. Expect validated PQC modules in 2025-2026.
Q: Is AWS KMS FIPS-validated? A: AWS KMS uses FIPS 140-2 Level 2 validated HSMs (for standard keys) and Level 3 (for CloudHSM-backed keys). Check AWS’s compliance page for current certificate numbers. AWS is pursuing 140-3 validation for newer hardware.