USD 
GBP 
CAD 
INR 
AUD 
SGD What is FIPS?
FIPS stands for Federal Information Processing Standards, a collection of standards published by the National Institute of Standards and Technology (NIST) for U.S. federal computer systems. These standards address specific areas of information processing and security, including cryptography.
Within that collection, the FIPS 140 series covers security requirements for cryptographic modules. FIPS 140-2 is the previous version of the cryptographic-module standard, while FIPS 140-3 is now used for new validations.
What is FIPS 140-2?
FIPS 140-2, formally Federal Information Processing Standard Publication 140-2, defines security requirements for cryptographic modules used to protect sensitive information. It evaluates the security of the module performing cryptographic operations rather than simply checking whether a product supports a particular encryption algorithm.
A cryptographic module can consist of hardware, software, firmware, or a combination of them within a defined cryptographic boundary. Depending on the implementation, this could be a dedicated hardware device, a software cryptographic library, firmware embedded in a device, or another component that performs functions such as encryption, digital signatures, key generation, or key management.
What Does FIPS 140-2 Validate?
FIPS 140-2 validates the security, design, and implementation of a defined cryptographic module against a set of technical requirements. The validation applies to the module and configurations covered by its CMVP validation.
FIPS 140-2 evaluates requirements across 11 security areas:
| Security area | What it evaluates |
|---|---|
| Cryptographic module specification | The module’s components and defined cryptographic boundary |
| Ports and interfaces | How information and commands enter and leave the module |
| Roles, services, and authentication | Who can access cryptographic functions and how access is controlled |
| Finite-state model | The module’s defined operating states and transitions |
| Physical security | Protection against physical access or tampering |
| Operational environment | Security requirements for the environment in which the module operates |
| Cryptographic key management | How cryptographic keys and related sensitive material are handled |
| EMI/EMC | Electromagnetic interference and compatibility requirements |
| Self-tests | Tests used to detect failures affecting cryptographic operation |
| Design assurance | Controls and documentation supporting secure module development |
| Mitigation of other attacks | Protection against applicable attacks not covered elsewhere |
Using an approved cryptographic algorithm or obtaining an algorithm-validation certificate does not by itself make a cryptographic module FIPS 140-2 validated. The module must complete the CMVP validation process.
What are FIPS 140-2 Levels and How Do They Differ in Security?
FIPS 140-2 defines four increasing security levels for cryptographic modules, from Level 1 through Level 4. Level 1 establishes baseline security requirements, while Levels 2, 3, and 4 progressively add controls for physical security, authentication, key protection, and environmental safeguards.
A higher level introduces additional security controls, but it is not automatically the right choice for every system. The appropriate level depends on the module’s design and operating environment, the information it protects, and the threats it is expected to address.
| FIPS 140-2 level | What it means | Key security characteristics |
|---|---|---|
| Level 1 | Basic cryptographic module security | At least one approved algorithm or security function; production-grade components; no specific physical tamper-protection requirement |
| Level 2 | Adds stronger physical and access controls | Tamper-evident mechanisms; role-based or identity-based authentication; additional operational-environment requirements |
| Level 3 | Strengthens identity and key protection | Identity-based authentication; stronger physical resistance; protections for plaintext cryptographic keys and other critical security parameters |
| Level 4 | Highest FIPS 140-2 security level | Strong physical protection designed to detect and respond to unauthorized access, including protection against abnormal environmental conditions |
FIPS 140-2 Level 1 – Basic Security
Level 1 provides the baseline security requirements under FIPS 140-2. A module must use at least one approved algorithm or security function and production-grade components, but no specific physical tamper-protection mechanism is required.
Example: A software cryptographic module operating in a general-purpose computing environment can be validated at Level 1 when it meets the applicable requirements.
FIPS 140-2 Level 2 – Tamper Evidence and Operator Authentication
Level 2 adds requirements for physical tamper evidence and operator authentication. Tamper-evident coatings or seals can reveal attempts to access sensitive components, while role-based or identity-based authentication controls operator access. Additional requirements apply to the operational environment of software modules.
Example: A hardware cryptographic module may use tamper-evident seals or coatings that provide visible evidence of attempted physical access.
FIPS 140-2 Level 3 – Stronger Physical and Key Protection
Level 3 adds stronger physical protection and requires identity-based authentication. It also strengthens protection for plaintext cryptographic keys and other critical security parameters (CSPs), including protections designed to prevent them from being exposed when physical access is attempted.
Example: A hardware security module (HSM) designed to resist physical access and protect plaintext cryptographic keys can meet applicable Level 3 requirements.
FIPS 140-2 Level 4 – Highest Physical and Environmental Protection
Level 4 is the highest security level defined by FIPS 140-2 and is intended for environments where physical protection cannot be assumed. It adds stronger responses to physical penetration and addresses abnormal environmental conditions, such as voltage or temperature changes, that could compromise the module.
Example: A cryptographic module designed for an unprotected environment where physical and environmental attacks are part of the threat model may require Level 4 protections.
FIPS 140-2 Validated vs. FIPS Compliant: What’s the Difference?
A FIPS 140-2 validated module has completed testing through the Cryptographic Module Validation Program (CMVP) and received an official validation certificate. “FIPS compliant” is a broader claim that may indicate a product or implementation follows FIPS requirements, but the term alone does not confirm that the module has completed CMVP validation.
| Term | What it indicates |
|---|---|
| FIPS 140-2 validated | A defined cryptographic module has been tested against the applicable FIPS 140-2 requirements through an accredited laboratory and has an official CMVP validation |
| FIPS compliant | A broader claim that may indicate a product, configuration, or implementation follows applicable FIPS requirements or uses FIPS-approved cryptography; the term alone does not prove CMVP validation |
| Uses a FIPS-validated module | A larger product or application incorporates a cryptographic module with its own CMVP validation; the validation applies to that module and its documented configuration |
In short: an algorithm can be approved, a product can claim FIPS compliance, and a module can be FIPS validated—but these statements do not mean the same thing.
How Does FIPS 140-2 Validation Work?
FIPS 140-2 validation is performed through the Cryptographic Module Validation Program (CMVP), a joint program operated by NIST and the Canadian Centre for Cyber Security. Vendors work with an NVLAP-accredited Cryptographic and Security Testing Laboratory (CSTL), which tests the module against the applicable requirements before the validation package is reviewed by the CMVP.
Define the Cryptographic Module
The vendor defines the module being submitted for validation, including its cryptographic boundary, hardware, software or firmware components, supported security functions, operating environment, and security policy. This establishes exactly what the testing and validation cover.
Test the Module Through an Accredited Laboratory
An accredited CSTL evaluates the module against the applicable FIPS requirements and cryptographic algorithm standards. The laboratory tests the module and reviews its supporting security documentation, including its Security Policy. Any identified discrepancies must be addressed before the validation package can proceed.
Submit the Test Report for CMVP Review
Once testing is complete, the laboratory submits its test report and supporting documentation to the CMVP Validation Authorities for review. Laboratory testing alone does not constitute FIPS validation.
Receive an Official CMVP Validation
After successful CMVP review, the module receives a validation certificate and is added to the validated modules database. Its official listing identifies details such as the module, vendor, security level, tested configurations, approved algorithms, and Security Policy.
How Do You Check Whether a Module is FIPS 140-2 Validated?
The most reliable way to check FIPS 140-2 validation is to look up the cryptographic module in the official CMVP validated modules database and verify that the deployed module matches the validation record.
| Check | Why it matters |
|---|---|
| Certificate number | Identifies the specific CMVP validation |
| Vendor and module name | Confirms that the validation belongs to the cryptographic module being used |
| FIPS standard | Shows whether the validation is under FIPS 140-2 or FIPS 140-3 |
| Validation status | Indicates whether the certificate is Active, Historical, or Revoked |
| Security level | Shows the module’s validated overall security level |
| Hardware/software/firmware version | Helps confirm that the deployed version is covered by the validation |
| Tested configuration | Identifies the environment or configuration covered by testing |
| Caveats and security policy | Provides conditions and limitations that may affect how the validation applies |
A product may incorporate a FIPS-validated cryptographic module without the entire product being independently validated. For that reason, verification should focus on the specific module and configuration covered by the CMVP certificate.
What Do Active, Historical, and Revoked Mean?
Active, Historical, and Revoked are different CMVP validation statuses, and Historical should not be interpreted as another word for Revoked.
The module currently appears on the CMVP Active validation list under the conditions identified in its validation entry.
The validation has moved off the Active list because of factors such as its age or a program transition. Historical does not mean revoked, but the validation documentation may no longer reflect the latest CMVP guidance or requirements.
The validation has been revoked and can no longer be cited to demonstrate FIPS compliance.
This distinction matters after the September 2026 transition because the remaining Active FIPS 140-2 certificates moved to the Historical List rather than being automatically revoked.
What Happens to FIPS 140-2 After September 21, 2026?
After September 21, 2026, FIPS 140-2 validation certificates move from the CMVP Active List to the Historical List. FIPS 140-3 validations remain on the Active List for new systems, while Historical FIPS 140-2 modules may continue to be used for existing systems under the CMVP transition policy.
This marks the final stage of a transition that began several years earlier. CMVP began accepting FIPS 140-3 module submissions on September 22, 2020, stopped accepting FIPS 140-2 submissions for new validation certificates on September 22, 2021, and from April 1, 2022, accepted only limited FIPS 140-2 reports that did not change the validation sunset date.
FIPS 140-2 Transition Timeline
| Date | CMVP milestone |
|---|---|
| September 22, 2020 | CMVP began accepting FIPS 140-3 module submissions |
| September 22, 2021 | CMVP stopped accepting FIPS 140-2 submissions for new validation certificates |
| April 1, 2022 | Remaining FIPS 140-2 processing became limited to reports that do not change the validation sunset date |
| September 21, 2026 | Final day Active FIPS 140-2 modules could be used for new systems under the CMVP transition |
| September 22, 2026 | Remaining FIPS 140-2 validation certificates moved to the Historical List |
Does FIPS 140-2 Become Invalid After September 21, 2026?
No. Moving a FIPS 140-2 validation to the Historical List does not mean the module suddenly becomes invalid or that every existing deployment must stop using it.
FIPS 140-2 modules on the Historical List may continue to be used by federal agencies for existing systems under the CMVP transition policy. New federal systems requiring validated cryptography should use modules with applicable Active FIPS 140-3 validations.
Organizations subject to other regulatory, contractual, procurement, or industry requirements should also check the rules applicable to their environment rather than assuming that the federal CMVP transition automatically determines their own deadline.
FIPS 140-2 vs. FIPS 140-3: What’s the Difference?
FIPS 140-3 supersedes FIPS 140-2 for cryptographic module validation, but both standards address the security of cryptographic modules and use four increasing security levels from Level 1 through Level 4. The major differences are in the requirements framework, testing, authentication, sensitive security parameter protection, and lifecycle assurance.
A key structural difference is that FIPS 140-2 contained the cryptographic module security requirements directly within the standard. FIPS 140-3 instead references ISO/IEC 19790 for cryptographic module security requirements and ISO/IEC 24759 for corresponding testing requirements, supplemented by NIST’s CMVP guidance and SP 800-140 series.
| Area | FIPS 140-2 | FIPS 140-3 |
|---|---|---|
| Standards framework | Security requirements defined primarily within FIPS 140-2 | Reference ISO/IEC 19790, with testing based on ISO/IEC 24759 and additional NIST requirements and guidance |
| Security levels | Four increasing levels: 1-4 | Retains four increasing levels: 1-4 |
| Security requirement areas | Uses the FIPS 140-2 security-area framework | Updates the framework to include areas such as non-invasive security, sensitive security parameter management, self-tests, and lifecycle assurance |
| Self-tests | Uses the FIPS 140-2 self-test framework, including power-up and conditional tests | Uses updated pre-operational and conditional self-test requirements |
| Sensitive security parameters | Addresses cryptographic keys and other critical security parameters | Uses the broader Sensitive Security Parameter (SSP) framework and updated requirements for their protection and management |
| Authentication | Role-based or identity-based authentication requirements increase by security level | Updates roles, services, and authentication requirements, including stronger authentication requirements at higher levels |
| Lifecycle assurance | Includes design-assurance requirements | Introduces a broader lifecycle-assurance framework, including additional vendor evidence and testing requirements |
FIPS 140-3 is therefore more than a version-number change. It preserves the basic purpose and four-level security model of FIPS 140-2 while updating how cryptographic modules are specified, tested, documented, and maintained.
For systems requiring a new CMVP validation, FIPS 140-3 is now the applicable standard. Existing systems using Historical FIPS 140-2 modules should be assessed according to the CMVP transition policy and any regulatory, contractual, or procurement requirements that apply to the deployment.
Why Does FIPS Matter for Code Signing?
FIPS matters to code signing because a code-signing certificate’s private key must be protected against unauthorized access and misuse, and validated cryptographic hardware provides an independently tested environment for protecting and using that key.
A code-signing certificate establishes publisher identity through a digital signature, but the security of that signature ultimately depends on control of the corresponding private key. If an attacker obtains the key, it could potentially be used to sign malicious or unauthorized software under the legitimate publisher’s identity.
For publicly trusted code-signing certificates, current CA/Browser Forum requirements require subscriber private keys to be generated, stored, and used in qualifying hardware cryptographic modules. For subscriber-controlled key storage, the applicable hardware requirements include FIPS 140-2 Level 2 or Common Criteria EAL 4+. Signing Services are subject to stronger hardware requirements.
FIPS validation is relevant because it provides evidence that the cryptographic module itself has undergone independent testing against defined security requirements. It does not validate an organization’s entire code-signing process or guarantee that a private key cannot be compromised through weaknesses outside the module’s validation boundary.
What Does FIPS 140-2 Level 2 Mean for Code Signing?
In code signing, a FIPS 140-2 Level 2 requirement refers to the security level of the cryptographic module protecting the private key – not the certificate itself. An OV or EV code-signing certificate is not itself “FIPS validated”; its private key may instead be protected and used within a qualifying cryptographic module.
The certificate establishes the verified publisher identity used in the signature. The cryptographic module helps protect the private key used to create it.
Who Needs FIPS 140 Validation?
FIPS 140 validation is directly relevant to U.S. federal agencies using cryptography to protect sensitive information and to organizations providing products or services that use cryptography in those environments. Private-sector organizations may also encounter FIPS requirements through contracts, procurement rules, industry requirements, or internal security policies.
An organization outside the federal government may encounter FIPS requirements when:
- supplying software, hardware, or cloud services to government customers;
- responding to procurement requirements that specify FIPS-validated cryptography;
- using a security product or service subject to requirements for a qualifying cryptographic module;
- operating under a contract that explicitly requires FIPS validation; or
- adopting FIPS-validated modules as part of an internal cryptographic-security policy.
This is different from saying that every bank, healthcare organization, university, or technology company is automatically required to comply with FIPS 140 simply because it handles sensitive data.
The actual requirement should be traced to the law, regulation, contract, procurement rule, technical standard, or security policy that applies to the organization.
What FIPS 140-2 Means Going Forward
FIPS 140-2 established a common framework for evaluating cryptographic modules across four security levels. After September 21, 2026, however, seeing “FIPS 140-2” in a product specification is not enough. Organizations should check the actual CMVP validation, security level, tested configuration, and current status.
For new systems requiring validated cryptography, FIPS 140-3 is now the standard to plan around. Existing FIPS 140-2 deployments should be evaluated according to their validation status, system lifecycle, and applicable requirements. For code signing, FIPS concerns the cryptographic module protecting the private signing key rather than the certificate itself.
Frequently Asked Questions About FIPS 140-2
Is FIPS 140-2 Required for Code Signing?
Can I Use a Cloud HSM for Code Signing?
What’s the Difference Between FIPS 140-2 and an HSM?
Does Using a FIPS-Validated Module Make the Entire System FIPS Validated?
Will the FIPS 140-2 to FIPS 140-3 Transition Affect My Existing Code-Signing Certificate?
Choose a Code Signing Setup That Fits Your Key Storage
Find certificate options for hardware-protected signing, including token, HSM, and supported cloud signing setups.
