Everything You Need to Know About FIPS Compliance

FIPS compliance means your organization is using cryptographic modules that NIST has formally validated through the Cryptographic Module Validation Program (CMVP), and that those modules are correctly configured in your systems. If you handle federal data, pursue FedRAMP authorization, operate under CMMC Level 2 or above, or sell into regulated sectors like healthcare and finance, FIPS-validated cryptography is a hard requirement, not a best practice. The first practical step is verifying that every module in your stack holds an Active FIPS 140-3 certificate in the CMVP database not just a product family name that was validated years ago.

Quick Answer: What Is FIPS Compliance?

FIPS compliance means an organization uses cryptographic modules formally validated by NIST’s CMVP against FIPS 140-2 or FIPS 140-3, and has correctly deployed those modules within its systems. Federal agencies and contractors are legally required to use FIPS-validated modules under FISMA. NIST moved all remaining FIPS 140-2 certificates to Historical status on September 21, 2026. All current Active validations are FIPS 140-3.

Key Takeaways

• FIPS compliance is mandatory for U.S. federal agencies and contractors under FISMA, and effectively required for FedRAMP and CMMC Level 2 and above.
• FIPS validation is what a module vendor earns through CMVP testing. FIPS compliance is what the organization using that module is responsible for maintaining.
• NIST stopped accepting FIPS 140-2 submissions in September 2021. All remaining FIPS 140-2 certificates moved to Historical status on September 21, 2026. All new validations are FIPS 140-3.
• FIPS 140-3 is based on ISO/IEC 19790:2012 and ISO/IEC 24759. It adds stronger entropy requirements, mandatory side-channel attack testing, and broader coverage of virtualized and cloud environments compared to FIPS 140-2.
• All four FIPS 140 security levels (1 through 4) apply to both FIPS 140-2 and FIPS 140-3. Most enterprise use cases require Level 2 (tamper-evident) or Level 3 (tamper-resistant with key zeroing).
• FIPS 140-3 validation typically takes 6 to 24 months through a NIST-accredited Cryptographic Security Testing Laboratory (CSTL).
• NIST finalized FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA) in August 2024. NIST IR 8547 targets RSA and ECC deprecation around 2030. FIPS-compliant infrastructure must be crypto-agile to support this migration.

What Is FIPS Compliance?

Federal Information Processing Standards (FIPS) are standards and guidelines published by the National Institute of Standards and Technology (NIST) for federal computer systems. FIPS publications cover a range of topics, but in the context of cryptography and security, the most operationally significant are the FIPS 140 series: the Security Requirements for Cryptographic Modules.

FIPS compliance has two distinct meanings that are often conflated, and getting them right matters for audits and procurement:

• FIPS validation is what a cryptographic module vendor earns. It is a formal certification issued by NIST after a module has been tested by a NIST-accredited Cryptographic Security Testing Laboratory (CSTL) and passed review through the Cryptographic Module Validation Program (CMVP). A validated module receives a certificate number that appears in the CMVP database at csrc.nist.gov. The certificate is tied to the specific hardware and firmware or software version tested, not the product family.
• FIPS compliance is what the organization using a validated module is responsible for. It means procuring and deploying modules with Active CMVP certificates, configuring them to operate in FIPS-approved modes, using only approved algorithms and key sizes, and maintaining the documentation and controls that auditors verify.

The practical implication: a vendor’s product page saying “FIPS 140-2 validated” is not sufficient. You need to verify the specific version number you are deploying against the CMVP database, confirm the certificate is Active (not Historical), and confirm the module is operating in its approved mode of operation per its Security Policy document.

Who Needs FIPS Compliance?

FIPS compliance is a hard legal requirement for some organizations and an effective market requirement for others. Understanding which category applies to you determines the urgency and scope of your compliance program:

Organization type	FIPS requirement	Governing authority
U.S. federal agencies	Mandatory: must use FIPS-validated cryptographic modules for all sensitive unclassified information	FISMA (44 U.S.C. § 3551), OMB Circular A-130
Federal contractors and subcontractors	Mandatory when handling federal data or operating federal information systems	FISMA, FAR clause 52.239-1, agency-specific contract requirements
FedRAMP-authorized cloud services	Mandatory: FIPS-validated encryption required for data in transit and at rest in federal environments	FedRAMP Security Controls (SC-28, SC-8, IA-7)
CMMC Level 2 and Level 3 contractors (DoD)	Required: FIPS-validated cryptography required for CUI protection under SC.L2-3.13.11	CMMC 2.0 (32 CFR Part 170), NIST SP 800-171 Rev. 2
Healthcare organizations (HIPAA)	Effectively required when using encryption as a safeguard for ePHI; NIST guidance specifies FIPS-validated modules	HIPAA Security Rule (45 CFR § 164.312), HHS guidance
Financial services (PCI DSS)	PCI DSS v4.0 requires strong cryptography; industry interpretation is FIPS-validated modules for cardholder data environments	PCI DSS v4.0 Requirements 4 and 6
State and local government	Often required by state policy for systems interoperating with federal systems or handling federal grant data	State IT security policies; CISA guidance
Private sector with no federal exposure	Not legally required, but FIPS-validated modules are the recognized benchmark for cryptographic security best practice	Voluntary; often contractually required by enterprise customers

FIPS 140-2 vs. FIPS 140-3: What Changed and What It Means for You

Understanding the transition between FIPS 140-2 and FIPS 140-3 is operationally important right now. NIST moved all remaining FIPS 140-2 certificates to Historical status on September 21, 2026. If your organization is still using modules that only hold FIPS 140-2 certificates, those certificates are now Historical, and you need a defined plan to transition to FIPS 140-3 validated replacements.

Category	FIPS 140-2	FIPS 140-3
Underlying standard	ISO/IEC 19790:2006	ISO/IEC 19790:2012 + ISO/IEC 24759
Security levels	Four levels (1-4)	Same four levels with refined criteria
Entropy and RNG requirements	Not explicitly defined	Stronger entropy source requirements for key generation; SP 800-90 series mandated
Side-channel attack testing	Addressed only at Level 3-4	Comprehensive non-invasive attack testing (SPA, DPA, timing) required at all applicable levels
Physical security	Tamper-evidence and tamper-resistance	Modernized physical security requirements; improved response mechanisms
Module authentication	Passwords and simple mechanisms	Multi-factor authentication required at Level 3 and above
Software integrity	Basic integrity checks	More stringent self-tests and software integrity requirements
Virtualized environments	Broad terms; limited cloud guidance	Explicit requirements for virtualized environments, containers, and firmware updates
Post-quantum readiness	No PQC provisions	Framework supports approved PQC algorithms (FIPS 203, 204, 205) within validated modules
Testing alignment	Separate FIPS testing process	Aligned with ISO/IEC 24759; reduces redundancy between international and U.S. testing
Module revalidation	Rigid change management	Improved change management and delta testing for module updates
Submission status	No longer accepted (closed September 2021)	Only active submission path for new validations
Certificate status (as of September 2026)	Historical: no longer current	Active: required for new procurements and ongoing compliance

The FIPS 140-2 to FIPS 140-3 Transition Timeline

• September 22, 2019: FIPS 140-3 approved and published by NIST.
• September 22, 2021: NIST stopped accepting new FIPS 140-2 module submissions to CMVP. All new submissions from this date forward must target FIPS 140-3.
• September 21, 2026: All remaining FIPS 140-2 certificates moved to Historical status. Historical certificates are no longer considered current for compliance purposes.
• Now: Organizations must verify Active FIPS 140-3 certificates for all modules in scope. Existing deployments using Historical modules need a documented transition plan.

What Are the Four FIPS 140 Security Levels?

Both FIPS 140-2 and FIPS 140-3 use the same four-level security framework. The security level you need depends on what data the module protects, how it is deployed, and what your regulatory framework requires. Here is what each level requires in practice:

Level	Physical security	Authentication	Typical use case	Example module type
Level 1	None required; software-only acceptable	Operator roles with at least one mechanism	Low-risk applications, developer libraries, general software encryption	Software cryptographic library (e.g., OpenSSL in FIPS mode)
Level 2	Tamper-evident coatings, seals, or locks on removable covers; pick-resistant locks on doors	Role-based authentication	Government systems handling sensitive unclassified data; most enterprise HSM deployments	Network-attached HSM with tamper-evident enclosure
Level 3	Tamper-resistant hardware with active response: keys zeroed when penetration detected; identity-based authentication	Identity-based authentication (e.g., multi-factor)	High-assurance key management, CA private keys, payment processing HSMs	Hardware HSM used as a root CA or payment processor
Level 4	Complete physical envelope protecting against penetration from any direction; environmental failure protection (voltage, temperature attacks)	Multi-factor with environmental monitoring	Highest-sensitivity environments: intelligence, classified adjacent, military applications	Ruggedized HSM designed for hostile physical environments

A practical note on level selection: the level required is not always the highest available. FIPS 140 Level 2 is sufficient for most federal agency use cases and FedRAMP environments. Level 3 is typically required when the module protects CA private keys, long-term key material, or payment processing keys. Level 4 is rare outside of intelligence community and specialized defense applications. Over-specifying the level increases cost and complexity without proportionate security benefit.

FIPS Compliance vs. FIPS Validation: Why the Distinction Matters for Audits

This distinction comes up in almost every FIPS audit and procurement discussion. Organizations that confuse the two either over-claim compliance they have not verified or underestimate what they need to maintain. Here is the precise breakdown:

Category	FIPS Validation	FIPS Compliance
What it is	Formal NIST certification that a specific cryptographic module meets FIPS 140-2 or FIPS 140-3 requirements	Organizational posture of using validated modules correctly in systems and operations
Who earns it	Module vendors (HSM manufacturers, software vendors, cryptographic library developers)	Organizations deploying and operating those modules
Testing process	NIST-accredited CSTL (Cryptographic Security Testing Laboratory) tests the module; CMVP issues the certificate	No formal NIST test; organizations self-assess or engage third-party assessors (e.g., for FedRAMP or CMMC)
Evidence artifact	CMVP certificate number and Security Policy document at csrc.nist.gov/cmvp	System documentation showing validated modules deployed in approved modes; configuration evidence; procurement records
Scope	Specific to the cryptographic module: the exact hardware version or software build tested	System-wide: all modules across the system boundary that handle sensitive data must be validated
Duration	Certificate is Active until NIST revokes it or moves it to Historical; Historical certificates have no expiry date but are no longer current	Ongoing: compliance must be maintained through procurement decisions, configuration management, and re-assessment
Who needs to verify it	Procurement teams and security architects, before acquiring any cryptographic module	Compliance teams, auditors (FedRAMP 3PAO, CMMC C3PAO), security operations
Common failure modes	Deploying a module version not covered by the certificate; using a module outside its approved operating environment	Operating a validated module outside its FIPS-approved mode; using unapproved algorithms; outdated Security Policy documentation

What Are the Key FIPS Compliance Requirements?

FIPS compliance for an organization operating in a federal or regulated environment involves five categories of requirements. These map to what auditors check during a FedRAMP assessment, a CMMC evaluation, or an agency security review:

1. Cryptographic Module Selection and Verification

Every cryptographic module used to protect sensitive data must hold an Active FIPS 140-3 certificate in the CMVP database. The verification process requires checking the specific module version, not just the product family. A vendor may have an Active certificate for version 3.1 of a product while version 3.2 is still in review. Deploying version 3.2 in a FIPS-required environment before its certificate is issued creates a compliance gap.

Evidence artifact: CMVP certificate numbers for each module in scope, captured in a cryptographic module inventory. The inventory should include module name, version, certificate number, certificate status, approved operating environment, and the system or service where the module is deployed.

2. Approved Mode of Operation

A validated module can be operated in FIPS-approved mode or non-approved mode. In non-approved mode, the module may use non-FIPS algorithms or key sizes for compatibility with legacy systems. For FIPS compliance purposes, the module must be running in its FIPS-approved mode of operation as defined in the module’s CMVP Security Policy document.

Evidence artifact: Configuration documentation or system security plan (SSP) confirming that each validated module is configured in FIPS-approved mode. For software modules such as OS-level cryptographic libraries, this typically means enabling a FIPS mode flag verified at runtime. For HSMs, this means the administrative configuration documented in the Security Policy is applied and verified.

3. Approved Algorithms and Key Sizes

FIPS compliance requires using only NIST-approved cryptographic algorithms for protecting sensitive data. The approved algorithm list is maintained by NIST in the Cryptographic Algorithm Validation Program (CAVP) and in NIST SP 800-131A Rev. 2. The most commonly required algorithms and minimum key sizes for FIPS compliance are:

• AES (Advanced Encryption Standard): 128, 192, or 256-bit keys for symmetric encryption. AES-256 is preferred for long-term data protection. AES-256 is the standard for most federal data-at-rest requirements.
• RSA: Minimum 2048-bit keys for key transport and digital signatures. RSA-3072 or RSA-4096 preferred for longer-term use. NIST IR 8547 targets RSA for deprecation around 2030.
• ECDSA (Elliptic Curve Digital Signature Algorithm): Minimum P-256 curve. P-384 preferred for higher-assurance applications. Also targeted for deprecation around 2030 under NIST IR 8547.
• SHA-2 family (SHA-256, SHA-384, SHA-512): Required for hashing and digital signatures. SHA-1 is no longer approved for digital signatures under FIPS standards.
• HMAC: Hash-based Message Authentication Code using approved hash functions for data integrity and authentication.
• Post-quantum algorithms (emerging): FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), FIPS 205 (SLH-DSA) finalized August 2024. CMVP validation of modules implementing these algorithms is in progress. Federal agencies should monitor NIST guidance on PQC algorithm transition timelines under NSM-10 and NIST IR 8547.

4. Key Management

Key management is one of the most frequently cited gaps in FIPS compliance audits. Having a validated module is not sufficient if the keys it protects are not generated, stored, distributed, rotated, and destroyed according to FIPS requirements and the organization’s documented key management policy.

FIPS requirements for key management include: generating keys using approved random number generators (SP 800-90A/B/C compliant); storing keys only in FIPS-validated modules or protected key storage with access controls; separating key management roles (key generation, key distribution, key destruction); limiting key lifetimes per NIST SP 800-57 guidance; and destroying keys using approved zeroization procedures when they are no longer needed.

For most organizations, key management at FIPS compliance standards requires a Hardware Security Module (HSM) at FIPS 140-3 Level 2 or Level 3 to serve as the root of trust for key generation and storage. Software-only key management does not meet the physical security requirements for sensitive federal data. Evidence artifact: Key management policy documentation; HSM audit logs; key lifecycle records showing generation, distribution, rotation, and destruction events with timestamps.

5. Documentation and Audit Trails

FIPS compliance is not auditable without documentation. The minimum documentation set that auditors and assessors expect includes: a system security plan (SSP) or equivalent that identifies all cryptographic modules in scope, their CMVP certificate numbers, and their approved modes of operation; a cryptographic module inventory listing certificate status for each module; configuration evidence showing FIPS-approved mode is enabled; key management policy and key lifecycle records; physical security documentation for Level 2 and above deployments; and annual review records confirming that certificate status has been re-verified and configurations remain correct.

How to Achieve FIPS Compliance: A 6-Step Implementation Process

The following process applies to organizations building FIPS compliance for the first time or closing gaps identified in an audit or self-assessment. Each step includes the evidence artifact you need to produce before moving to the next:

1. Define your compliance scope: Identify which systems, services, and data flows are in scope for FIPS compliance based on your regulatory obligations (FISMA, FedRAMP, CMMC, HIPAA, PCI DSS). Document the system boundary precisely. Everything inside the boundary that handles sensitive data needs to use FIPS-validated cryptographic modules. Evidence artifact: Scope definition document or SSP system boundary description.
2. Inventory all cryptographic modules in scope: Identify every cryptographic module used within your system boundary. This includes HSMs, TLS libraries, OS-level cryptographic providers, VPN clients, disk encryption solutions, and any application-level cryptographic code. For each module, record the vendor, product name, version, and whether it has an Active FIPS 140-3 certificate. Evidence artifact: Cryptographic module inventory with CMVP certificate verification status. A CBOM Secure engagement automates this discovery across cloud and on-premises environments.
3. Verify CMVP certificate status for each module: Search the CMVP database at csrc.nist.gov/projects/cryptographic-module-validation-program for each module. Confirm certificate status is Active (not Historical or Revoked), that the certificate covers the exact version you are deploying, and that your deployment environment matches the approved operating environment in the module’s Security Policy. Evidence artifact: CMVP certificate printouts or database query results with verification date.
4. Configure modules in FIPS-approved mode and remediate gaps: Enable FIPS-approved mode on all validated modules in scope. Identify any modules without Active FIPS 140-3 certificates and plan their replacement. Identify any uses of non-approved algorithms or deprecated key sizes and remediate them. This step is where most of the actual technical work happens. Evidence artifact: Configuration documentation; before-and-after algorithm scan results; replacement procurement records for non-compliant modules.
5. Implement FIPS-compliant key management: Deploy a FIPS 140-3 Level 2 or Level 3 validated HSM as the root of trust for key generation and storage. Document key management policies covering generation, distribution, rotation, and destruction. Implement role separation for key management functions. Evidence artifact: HSM deployment documentation with CMVP certificate; key management policy; key ceremony records for root keys and CA keys if applicable.
6. Document, test, and maintain: Produce the complete documentation set described in the requirements section above. Conduct periodic reviews (annually at minimum) to re-verify CMVP certificate status, confirm configurations remain correct, and identify any new modules added to the system boundary. For FedRAMP and CMMC, third-party assessors will verify this documentation. Evidence artifact: Annual review records; updated module inventory; continuous monitoring evidence.

FIPS Compliance Audit-Ready Checklist

Use this checklist to verify your FIPS compliance posture before an assessment or to track remediation progress after a gap analysis:

Control area	Requirement	Evidence artifact	Owner	Status
Scope definition	System boundary documented; all data flows involving sensitive data identified	SSP system boundary; data flow diagrams	Security Architecture	To action
Module inventory	All cryptographic modules in scope inventoried with vendor, version, and CMVP certificate number	Cryptographic module inventory	Security Engineering	To action
CMVP certificate status	All modules verified as Active FIPS 140-3 in CMVP database; no Historical or Revoked certificates in use	CMVP database query results with verification date	Compliance / Security Engineering	To action
Version alignment	Deployed module version matches the version covered by the CMVP certificate	Module version documentation; Security Policy review	Security Engineering	To action
FIPS-approved mode enabled	All validated modules confirmed operating in FIPS-approved mode per their Security Policy	Configuration documentation; runtime FIPS mode verification logs	Security Engineering	To action
Approved algorithms only	No deprecated algorithms in use (SHA-1 for signatures, DES, 3DES, RC4, RSA under 2048 bits)	Cryptographic algorithm scan results; code review records	Security Engineering	To action
Key generation	Keys generated using SP 800-90 compliant DRBG within a validated module	HSM configuration; key generation audit logs	Key Management / Security Engineering	To action
Key storage	Cryptographic keys stored only in FIPS 140-3 Level 2 or Level 3 validated HSM or equivalent protected storage	HSM deployment documentation with CMVP certificate; access control configuration	Key Management	To action
Key lifecycle policy	Documented key management policy covering generation, distribution, rotation, and destruction per NIST SP 800-57	Key management policy document; key rotation schedule	Key Management / Compliance	To action
Role separation	Key management roles separated: key generation, key distribution, key destruction assigned to distinct roles	RACI matrix for key management; access control configuration	Security Architecture	To action
Physical security (Level 2+)	Tamper-evident seals and access controls present on hardware modules at Level 2; tamper-resistant mechanisms at Level 3	Physical security inspection records; module seal photographs	Facilities / Security Engineering	To action
Audit trail logging	All cryptographic operations logged with timestamps; logs tamper-protected and retained per policy	Logging configuration; log retention policy; sample log extract	Security Operations	To action
SSP documentation	System Security Plan identifies all cryptographic modules, their certificate numbers, and their approved modes of operation	SSP or equivalent security documentation	Compliance	To action
Annual review	Annual re-verification of CMVP certificate status; configuration review; inventory update for any new modules added	Annual review records with date; updated inventory	Compliance	To action
PQC readiness assessment	Cryptographic inventory identifies all RSA and ECC usage; plan exists for migration to FIPS 203/204/205 compliant modules before 2030	CBOM or cryptographic inventory report; PQC migration roadmap	Security Architecture	To action

What Are the Common Challenges in FIPS Compliance?

Organizations that have been through FIPS compliance assessments consistently encounter the same categories of gaps. Understanding these before you start saves significant remediation time:

• Product family vs. specific version confusion: Vendors market products as “FIPS validated” when only specific versions hold Active certificates. When the validated version is updated or patched, the new version may not yet have its own certificate. Organizations must track the specific version deployed against the specific version certified a process that requires ongoing monitoring, not a one-time check at procurement.
• Non-approved mode operation: Many validated modules have both a FIPS-approved mode and a non-FIPS mode for compatibility with legacy systems. Auditors regularly find that organizations have a validated module deployed but not configured to operate in its FIPS-approved mode. The module being present is not the same as the module being used in a compliant configuration.
• Legacy system algorithm gaps: Legacy applications often use deprecated algorithms such as SHA-1 for signatures, 3DES, or RSA with insufficient key sizes. These cannot be made FIPS-compliant without code changes or replacement. Cryptographic discovery across the application estate is the only reliable way to identify all legacy algorithm usage before an assessment exposes them.
• Software key storage: Applications that generate and store cryptographic keys in software, in configuration files, or in operating system key stores do not meet the physical security requirements for FIPS Level 2 and above. Key material for sensitive data must be in a validated HSM or equivalent protected store.
• Validation timeline for new modules: FIPS 140-3 validation takes 6 to 24 months. If your compliance program requires a new HSM or cryptographic library and no validated version yet exists, you face a choice between delaying the project or accepting a temporary exception with a documented remediation timeline. Factor validation timelines into procurement decisions before they become compliance blockers.
• PQC migration planning: RSA and ECC are targeted for deprecation around 2030 under NIST IR 8547. Organizations building FIPS-compliant infrastructure now need to verify that their HSMs and cryptographic modules support PQC algorithm updates via firmware, not hardware replacement. Modules that do not support ML-KEM, ML-DSA, or SLH-DSA via firmware will require physical replacement during the migration window.

How Does FIPS Compliance Relate to Post-Quantum Cryptography?

FIPS compliance and post-quantum cryptography (PQC) are converging requirements. NIST finalized three post-quantum cryptographic standards in August 2024: FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA). These are the first FIPS-approved post-quantum algorithms, and CMVP validation for modules implementing them is underway.

The connection to FIPS compliance is direct: NIST IR 8547 guidance targets RSA and ECC for deprecation around 2030 and disallowance by 2035. When those algorithms are deprecated, using them will no longer constitute FIPS compliance even if they are currently implemented in a validated module. Organizations that plan their FIPS compliance programs today need to account for this migration window in their infrastructure choices.

The practical implication is crypto-agility in HSM selection. Before procuring or renewing an HSM deployment, verify with the vendor that the specific hardware model supports ML-KEM, ML-DSA, and SLH-DSA via firmware update, not hardware replacement. HSMs that require physical replacement to support PQC will create a significant cost and operational burden during the 2028 to 2032 window when migration will be most active. For organizations wanting to map their current RSA and ECC exposure before it becomes a compliance gap, our PQC Readiness service and PQC Center of Excellence provide the cryptographic inventory and migration roadmap to get ahead of that window.

What Encryption Consulting Recommends: Our Practical Perspective

After working with organizations across federal contracting, healthcare, financial services, and defense supply chain on FIPS compliance programs, a few consistent patterns separate teams that navigate assessments cleanly from those that face significant findings:

Organizations that treat FIPS compliance as a procurement exercise tend to struggle at the configuration layer. Buying a validated HSM or selecting a FIPS-validated TLS library is step one. The harder work is ensuring every deployment is in FIPS-approved mode, every algorithm in the stack meets current minimums, and the documentation is accurate enough that an assessor can independently verify it. We see more FedRAMP and CMMC gaps at the configuration and documentation layer than at the module selection layer.

The second pattern is version drift. Organizations validate a module at procurement and then lose track of certificate status as the product is updated. A version increment that introduces a new algorithm or changes a firmware component may require a new CMVP submission. The compliance program needs to include a process for re-verifying CMVP status whenever a module is updated not just at initial procurement. This is especially important now that FIPS 140-2 certificates have moved to Historical status: any module update that triggered a new validation submission after September 2021 went through FIPS 140-3, but organizations may not have updated their documentation to reflect that.

Third: start PQC planning now, not when the deprecation notices arrive. The 6 to 24 month validation timeline means that if you wait until RSA deprecation is imminent before identifying which of your HSMs support PQC firmware updates, you will be making emergency procurement decisions under deadline pressure. A cryptographic inventory completed today gives you the map you need to plan the migration calmly over the next three to four years.

How Encryption Consulting Can Help With FIPS Compliance

Encryption Consulting is an ISO/IEC 27001:2022 and SOC 2 certified applied-cryptography firm. We help organizations build FIPS compliance programs that pass FedRAMP, CMMC, and agency security assessments and that are architected to survive the PQC migration without complete infrastructure replacement.

• FIPS Compliance Advisory: Our Compliance Advisory Services cover FIPS gap assessment, cryptographic module inventory, configuration remediation, and documentation development for FedRAMP, CMMC, FISMA, HIPAA, and PCI DSS compliance programs. We produce the evidence packages that 3PAOs and C3PAOs need to verify, not just recommendations that leave the hard work to your team.
• HSM as a Service: For organizations that need FIPS 140-3 Level 3 validated key custody without the capital expense and operational complexity of on-premises hardware, HSM-as-a-Service provides dedicated, compliance-grade HSM capacity with full CMVP certificate documentation and configuration evidence. This is the right starting point for organizations that need Level 3 key protection for CA private keys, long-term key material, or payment processing.
• CBOM Secure (Cryptographic Inventory): CBOM Secure runs a discovery pass across your cloud accounts, on-premises infrastructure, and application code to produce a Cryptographic Bill of Materials (CBOM). This inventory identifies every cryptographic algorithm, key size, and module in use including the ones that will fail a FIPS compliance check before an assessor finds them. This is also the foundation for PQC migration planning.
• PKI as a Service: For organizations that need a FIPS-compliant certificate infrastructure for device identity, TLS, code signing, or user authentication, PKI-as-a-Service provides a fully managed CA with always-offline root CA using FIPS 140-3 Level 3 HSM key storage, CP/CPS governance documentation, and key ceremony records that satisfy the most demanding federal audit requirements.
• PQC Readiness: Our PQC Readiness service and PQC Center of Excellence assess your current RSA and ECC exposure across every environment in scope, identify which HSMs and modules support PQC firmware updates versus requiring replacement, and produce a migration roadmap calibrated to your FIPS compliance obligations and the NIST IR 8547 deprecation timeline.

Conclusion

FIPS compliance is one of the most concrete, verifiable security obligations in the federal and regulated sectors and one of the most commonly misunderstood. The distinction between FIPS validation (what a vendor earns) and FIPS compliance (what your organization maintains) determines whether you pass an assessment or face major findings. The September 2026 transition of all FIPS 140-2 certificates to Historical status makes this a live operational issue, not a future planning item: every organization still using FIPS 140-2 validated modules needs an inventory and a transition plan now.

The path forward is sequential: inventory first to know what you have, verify CMVP status for every module in scope, configure validated modules to operate in their FIPS-approved modes, and build the documentation that auditors need to independently verify your posture. Layer in PQC planning now while the migration window is open, so you are not making emergency infrastructure decisions when RSA and ECC deprecation becomes imminent around 2030.

Last reviewed and updated: September 1, 2026. For questions about your organization’s FIPS compliance program, contact our team.

Frequently Asked Questions

What does FIPS compliance mean?

FIPS compliance means an organization uses cryptographic modules that have been validated by NIST’s Cryptographic Module Validation Program (CMVP) against FIPS 140-2 or FIPS 140-3, and has correctly configured and deployed those modules in its systems. FIPS validation is what the module vendor earns. FIPS compliance is what the organization using that module is responsible for maintaining. Federal agencies and contractors are legally required to use FIPS-validated modules for protecting sensitive unclassified information under FISMA.

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

FIPS 140-2 is based on ISO/IEC 19790:2006. FIPS 140-3 is based on ISO/IEC 19790:2012 and ISO/IEC 24759. FIPS 140-3 adds stronger entropy requirements, mandatory side-channel attack testing, multi-factor authentication at Level 3 and above, and explicit requirements for virtualized and cloud environments. NIST stopped accepting FIPS 140-2 submissions in September 2021 and moved all remaining FIPS 140-2 certificates to Historical status on September 21, 2026. All new validations are FIPS 140-3.

Is FIPS compliance mandatory?

FIPS compliance is mandatory for U.S. federal agencies and their contractors under FISMA and OMB Circular A-130. It is effectively required for FedRAMP authorization and CMMC Level 2 and above. In healthcare and financial services, FIPS-validated modules are required when frameworks such as HIPAA and PCI DSS specify NIST-approved cryptography. Private sector organizations with no federal exposure are not legally required to comply, but FIPS-validated modules are the recognized benchmark for cryptographic security best practice.

What are the four FIPS 140 security levels?

Level 1 requires correct algorithm implementation with no physical security requirements so a software library can achieve Level 1. Level 2 adds tamper-evident seals and role-based authentication. Level 3 requires tamper-resistant hardware that zeroes keys when penetration is detected, plus identity-based authentication. Level 4 is the highest, requiring a complete physical envelope with environmental failure protection. Most enterprise and government use cases require Level 2 or Level 3.

How long does FIPS 140-3 validation take?

FIPS 140-3 validation typically takes 6 to 24 months from submission to certificate issuance. The process involves testing by a NIST-accredited Cryptographic Security Testing Laboratory (CSTL), followed by CMVP review. Timelines vary based on module complexity, security level, testing lab queue, and the number of comments requiring resolution. Factor validation timelines into procurement decisions before they become compliance blockers.

What happened to FIPS 140-2 certificates?

NIST stopped accepting new FIPS 140-2 module submissions on September 22, 2021. Remaining FIPS 140-2 certificates were moved to Historical status on September 21, 2026. Historical status means the certificate is no longer considered current for compliance purposes. Organizations should verify that modules they are using hold Active FIPS 140-3 certificates, not Historical FIPS 140-2 certificates, for ongoing compliance.

What is the CMVP?

The Cryptographic Module Validation Program (CMVP) is a joint program operated by NIST and the Canadian Centre for Cyber Security (CCCS) that manages testing and validation of cryptographic modules against FIPS 140-2 and FIPS 140-3. Module vendors submit their products to NIST-accredited Cryptographic Security Testing Laboratories (CSTLs) for testing. Upon passing, NIST issues a validation certificate searchable at csrc.nist.gov/projects/cryptographic-module-validation-program.

Does FIPS compliance cover post-quantum cryptography?

FIPS 140-3 includes provisions for post-quantum algorithms within validated modules. NIST finalized FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA) in August 2024. Under NIST IR 8547, RSA and ECC are targeted for deprecation around 2030 and disallowance by 2035. Organizations should verify that their HSMs and cryptographic modules support PQC algorithm firmware updates so they do not require hardware replacement during the migration window.