Erkan DemirkayaCryptographic module validation has shifted from being a checkbox that larger contractors handle in isolation to a condition of sale that reaches into the software supply chain, touching Independent Software Vendors (ISVs), on-premise software companies, and the platforms embedded within those vendors' products. If your software processes, transmits, or stores sensitive government data, you need to ensure you address FIPS compliance appropriately.
Vendors who haven't built their cryptographic stack around validated modules are effectively excluded from a significant segment of the government software market. That includes federal civilian agencies, defense contractors subject to CMMC, and any vendor whose software runs on infrastructure governed by the Federal Information Security Act (FISMA) or the Federal Risk and Authorization Management Program (FedRAMP).
This guide covers what FIPS compliance means for software vendors, how the FIPS 140-2 to 3 transition affects current development decisions, what the four security levels require and which one your buyers are likely to specify, and how FIPS compliance considerations extend into the licensing infrastructure layer of your product. It's written for software vendors, product architects, and technical decision-makers.
Key Takeaways
FIPS stands for Federal Information Processing Standards, which is a set of standards issued by the National Institute of Standards and Technology (NIST) that establish requirements for federal agency information systems and the vendors who supply them.
FIPS is a broader standards framework covering topics from data encryption to digital signatures to hash functions. Within that framework, FIPS 140 is the specific publication that governs cryptographic module validation. When practitioners refer to FIPS compliance in a software procurement context, they're almost always referring to FIPS 140 compliance, specifically whether the cryptographic modules in a system have been validated through the Cryptographic Module Validation Program (CMVP).
That distinction between FIPS as a broad framework and FIPS 140 as a targeted cryptographic standard matters because it reframes what compliance actually requires. With FIPS compliance, you're validating the specific cryptographic modules, which consist of the libraries and algorithms responsible for encryption, key management, hashing, and random number generation that your product relies on.
Who must comply spans a wider group than many vendors initially assume. Direct compliance obligations apply to US federal agencies and their information systems. For vendors, the obligation is triggered when your software handles Controlled Unclassified Information (CUI), processes classified government data, or runs on federal infrastructure subject to FISMA. Contract frameworks, including FedRAMP, DoD Impact Level 4 and above, and CMMC Level 2 and Level 3, all specify FIPS-validated cryptographic modules as a minimum requirement.
The most common misconception is that FIPS compliance is binary in that you either have it or you don't, at a product level. In practice, compliance refers to whether the specific cryptographic modules embedded in your system carry active validation certificates. A product can use a mix of validated and non-validated modules. Only operations performed by validated modules are covered by the compliance claim. That's a meaningful architectural difference to make when you're responding to a security questionnaire or supporting a federal procurement review.
FIPS 140-3 applies strictly to the cryptographic modules embedded in software, which are the specific libraries and algorithms responsible for encryption, key management, hashing, digital signatures, and random number generation. The scope doesn’t extend to your broader application logic. If your software calls a cryptographic library to sign a license token or encrypt a data payload, compliance refers to that library, not the feature it supports.
Vendors generally follow one of two paths:
For the vast majority of ISVs, the first path is faster and more practical. Pre-validated libraries with active CMVP (Cryptographic Module Validation Program) certificates include OpenSSL in its FIPS-validated build, Microsoft's Cryptography Next Generation (CNG) API on Windows, and Bouncy Castle in its FIPS-certified variant for Java.
It is important to note that using these libraries doesn’t automatically make your entire product "FIPS Validated." Instead, your product is considered "FIPS Compliant" or "FIPS Inside." Consuming these modules in their exact, unmodified binary form and in a manner consistent with their documented security policy allows your product to inherit their compliance status for federal procurement purposes. When government buyers ask for proof, you’ll provide the CMVP certificate numbers of these underlying libraries.
Independent validation (submitting your own cryptographic module to a CMVP-accredited lab) is appropriate only in highly specialized cases. If your organization has built a proprietary cryptographic engine, or if your deployment scenario requires a module that doesn't map cleanly onto an existing validated option, independent validation may be necessary. For most software product vendors, though, it adds massive costs and multi-year timelines without providing any additional procurement benefit.
The compliance requirement is triggered by the nature of your buyer relationship and the data your software handles. You need to address FIPS compliance when you are:
State and local government buyers, defense contractors in the supply chain, and regulated industry buyers in healthcare and critical infrastructure are increasingly aligning their security requirements with federal standards, even when they aren’t technically bound by them. Addressing FIPS compliance early means you aren’t scrambling to retrofit your cryptographic stack when a sales opportunity surfaces in those sectors.
FIPS 140-2 was the dominant cryptographic module validation standard for over two decades, first issued in 2001. FIPS 140-3 was finalized in 2019 and represented a significant structural change, rather than maintaining a NIST-specific technical framework, FIPS 140-3 adopted ISO/IEC 19790 as its technical basis, aligning US federal cryptographic requirements with the international standard used in many allied nations.
The changes introduced in FIPS 140-3 are substantive. Algorithm requirements were tightened, with certain older algorithms deprecated or restricted. Software and firmware security controls were enhanced, introducing new requirements around software integrity and code signing. Documentation and lifecycle requirements were revised to reflect modern secure development practices. The testing methodology was updated to align with ISO/IEC 24759, which governs how accredited labs conduct validation testing.
NIST stopped accepting new module submissions for FIPS 140-2 back on April 1, 2022. The final milestone for the standard arrives on September 21, 2026, which serves as the sunset date for all remaining active FIPS 140-2 certificates.
The transition from FIPS 140-2 to 3 introduces immediate procurement risks for vendors who are unprepared. On September 21, 2026, the CMVP will move all remaining FIPS 140-2 certificates to the Historical List.
While this doesn’t retroactively invalidate or revoke the certificates (meaning federal agencies can legally continue running them in existing, legacy systems), NIST explicitly advises agencies not to include historical modules in new system procurements. For ISVs, this means that relying on a FIPS 140-2 library will quickly become a liability. If you’re pursuing new federal contracts, or if your buyers are undergoing new FedRAMP or CMMC Level 2 assessments, auditors will flag a 140-2 "Historical" certificate as a compliance gap.
Consequently, any active or upcoming product development must target FIPS 140-3. When selecting a third-party cryptographic library to build into your software, you must ensure that the library carries an active FIPS 140-3 certificate—or is explicitly on the CMVP’s "Modules in Process" list for 140-3—to ensure your software remains viable for federal agency acquisitions.
Feature | FIPS 140-2 | FIPS 140-3 |
Technical basis | NIST-specific framework | ISO/IEC 19790 |
Published | 2001 | 2019 |
Testing methodology | FIPS-specific testing | Aligned with ISO/IEC 24759 |
Algorithm requirements | Original approved list | Updated; older algorithms deprecated |
Software/firmware security | Basic integrity requirements | Enhanced controls, code signing requirements |
New submissions accepted until | Stopped on April 1, 2022 | Current standard; ongoing |
Status after Sept 21, 2026 | Moved to Historical List (not allowed for new federal procurement) | Active List (standard for all new procurement) |
Recommended for new development | No—will cause audit failures | Yes—required baseline |
Both FIPS 140-2 and 3 define four distinct security levels for cryptographic modules. Each one of the FIPS compliance levels builds on the previous one, adding stricter physical security, tamper protections, and authentication controls.
For pure software-only modules, Levels 2, 3, and 4 cannot be achieved independently. Because software lacks physical properties, any software module aiming for Level 2 or higher must be strictly bound to, and tested alongside, specific underlying hardware that fulfills those physical tamper requirements.
The practical difference between these levels dictates whether an ISV can rely on standard software architectures or if they must mandate specialized hardware deployment environments for their customers.
To determine the required level, examine the specific procurement vehicle, contract clauses, or security framework governing how your target audience makes a buying decision.
The gold standard rule for vendors is: Don’t over-engineer. Validating at a higher level than your buyers explicitly require adds immense cost and timeline delays without translating into a procurement advantage.
Level | Physical Security Requirement | Authentication Requirement | Typical Module Type | Common Use Case |
Level 1 | Production-grade components only | Role-based (can be passed to OS) | Pure software cryptographic libraries | General federal civilian, FedRAMP application layer |
Level 2 | Tamper-evident mechanisms (seals, enclosures) | Role-based | Hardened appliances/software bound to specific hardware | FedRAMP high infrastructure, baseline DoD systems |
Level 3 | Tamper detection, response, and zeroization | Identity-based | Hardware Security Modules (HSMs), secure radios | DoD IL4+, Intelligence Community, cryptographic key storage |
Level 4 | Multi-directional envelope; environmental failure protection | Identity-based | Specialized, high-security hardware | Highly restricted environments, nuclear/tactical systems; extremely rare |
The Cryptographic Module Validation Program is jointly operated by NIST and the Canadian Centre for Cyber Security. The CMVP manages the validation process from submission through certificate issuance and maintains the authoritative list of validated modules at csrc.nist.gov.
Vendors pursuing independent validation submit their module to an NVLAP-accredited laboratory. The lab conducts testing against FIPS 140-3 and produces a validation report that NIST reviews before issuing the official certificate. The resulting certificate is tied to the specific version of the module tested; a subsequent release that modifies the cryptographic implementation typically requires a new validation cycle.
CMVP queue times have historically run 12 to 18 months between lab submission and certificate issuance with FIPS 140-2, but now they’re more like 18 to 24+ months with FIPS 140-3. If you're planning independent validation, that timeline needs to be reflected in your product roadmap.
For most software vendors, the practical compliance path is consuming a pre-validated cryptographic library rather than submitting an independent module. This approach is faster, less expensive, and carries no meaningful disadvantage in most procurement contexts. Federal procurement teams reviewing your cryptographic documentation want to see that your module carries an active CMVP certificate. The path by which it achieved that certificate is not a differentiating factor.
The authoritative source for checking whether a library your stack uses holds an active certificate is the CMVP validation list at csrc.nist.gov.
One critical operational consideration is that the "operational environment" is documented in a validated module's Security Policy. A validated module is approved for use in specific environments and configurations. If your integration deviates from those conditions, for example, by enabling non-approved algorithm modes alongside approved ones, or by running the library in an environment that doesn't match its tested configuration, the validation claim doesn't apply to that use. This is a common source of compliance gaps that surface during security reviews. Read the Security Policy for any validated library your team integrates, and ensure your integration stays within its bounds.
Federal procurement teams no longer limit their security review to the application layer. The entire software supply chain is in scope, and that includes the licensing and entitlement management infrastructure embedded in your product. If your licensing platform communicates over encrypted channels, generates or validates cryptographic license signatures, or handles authentication tokens, the algorithms it uses are part of your compliance posture.
This is a point that catches many vendors off guard during procurement reviews. They've addressed the cryptographic modules in their core application but haven't asked the same questions about their licensing vendor. If the entitlement management platform your product depends on relies on non-approved cryptographic primitives for license signing or channel encryption, which introduces a compliance gap that extends to the products built on it. A single weak link in the licensing layer can put the entire contract at risk.
The practical implication is that the licensing infrastructure you choose is an architectural decision with compliance consequences, not just an operational one.
Before committing to a licensing or entitlement management platform for federal-adjacent markets, get clear answers to the following:
Air-gapped and dark-site deployments are standard in defense, classified government facilities, and regulated manufacturing environments. In these contexts, the licensing system has no access to cloud infrastructure for key exchange, certificate validation, or activation. Every cryptographic operation has to be performed locally, using validated modules that are present on the host system.
This creates a meaningful differentiator between licensing platforms. Most cloud-native licensing vendors have architected their cryptographic layer around the assumption of connectivity. License signing happens server-side, the client validates against a remote endpoint, and key material flows over encrypted channels that assume internet access. When you remove connectivity, those architectures either fail or fall back to degraded modes that may not meet FIPS requirements.
A licensing platform built for air-gapped operation has to make different architectural choices from the start. Offline activation has to complete entirely with locally available validated modules. License validation has to work without remote key exchange. The cryptographic design has to be documented and auditable for security review without relying on a cloud infrastructure that federal reviewers can't inspect.
For vendors selling into defense, intelligence, classified facility management, or regulated industrial environments, this isn't an edge case. It's a baseline requirement, and it's one that not all licensing platforms are designed to meet.
FIPS compliance is a question of which cryptographic modules your product uses and whether they carry active CMVP certificates. It is not a product-level certification, and it is not an all-or-nothing designation. The 140-2 to 140-3 transition is manageable provided you're tracking your dependencies; existing 140-2 certificates remain valid for procurement, and new development should target 140-3.
Where vendors consistently under-invest is the supporting infrastructure layer. Federal buyers scrutinize the full software supply chain, and your entitlement management platform is part of it. The cryptographic design of your licensing layer, its behavior under OS-level FIPS enforcement, and its capacity to operate without cloud fallback in air-gapped deployments are all in scope during procurement reviews.
LicenseSpring is built for exactly these deployment scenarios: air-gapped environments, dark-site activations, and the security requirements that come with selling into regulated industries.
If you're evaluating licensing infrastructure for a federal or defense-adjacent market, talk to the LicenseSpring team to see how the platform is designed to support your compliance posture.
