Skip to main content
Commerce Security Authority
Category: Cryptography Fundamentals

FIPS 140-3

Also known as: FIPS 140-3, Federal Information Processing Standard 140-3, Security Requirements for Cryptographic Modules
Simply put

FIPS 140-3 is a U.S. government computer security standard used to validate cryptographic modules, meaning the hardware or software components that perform encryption and other cryptographic functions. It is the latest version of the FIPS 140 series and is intended to help ensure that these modules meet defined security requirements when protecting sensitive information. It applies to federal agencies that use cryptographic-based security systems, and it is often referenced in commercial security contexts as well.

Formal definition

FIPS 140-3, titled 'Security Requirements for Cryptographic Modules,' is a U.S. federal standard governing the security requirements for cryptographic modules. It became effective September 22, 2019, with NIST's Cryptographic Module Validation Program (CMVP) permitted to begin accepting validation submissions under the FIPS 140-3 scheme beginning September 2020. The standard is applicable to all federal agencies that use cryptographic-based security systems to protect sensitive information in computer and related systems. Note that FIPS 140-3 is a NIST/CMVP validation standard distinct from PCI DSS and other PCI standards; where PCI requirements reference the use of validated cryptographic modules, practitioners should confirm the applicable requirement against the current published PCI standard rather than assuming FIPS 140-3 validation alone satisfies a given PCI control.

Why it matters

Cryptographic modules are the components that actually perform encryption, key management, and related functions, and a weakness in a module can undermine the protection that an entire system depends on. FIPS 140-3 provides a defined set of security requirements and an independent validation path through NIST's Cryptographic Module Validation Program (CMVP), giving organizations a recognized reference point for judging whether a module meets baseline security expectations rather than relying on a vendor's unverified claims. This matters in payment and commerce security contexts because encryption, tokenization systems, hardware security modules, and PIN-handling components frequently rely on cryptographic modules whose trustworthiness is central to protecting sensitive data.

FIPS 140-3 is applicable to all federal agencies that use cryptographic-based security systems to protect sensitive information, and it is often referenced in commercial security contexts as well. For merchants, processors, and vendors, a module's FIPS 140-3 validation can serve as evidence during procurement, risk assessment, or customer due diligence. However, validation applies to the specific module as tested and configured, so the security benefit depends on deploying and operating the module within its validated boundary and approved mode.

It is important not to overstate what FIPS 140-3 delivers. It is a NIST/CMVP validation standard distinct from PCI DSS and the other PCI standards. Where PCI requirements reference the use of validated cryptographic modules, FIPS 140-3 validation alone does not automatically satisfy a given PCI control, and practitioners should confirm the applicable requirement against the current published PCI standard rather than assuming equivalence.

Who it's relevant to

Federal agencies and their vendors
The standard is applicable to all federal agencies that use cryptographic-based security systems to protect sensitive information in computer and related systems. Vendors selling to these agencies often need modules validated under CMVP to meet procurement requirements.
Security engineers and architects
Teams selecting or integrating hardware security modules, encryption libraries, or key management components can use FIPS 140-3 validation as a reference point for module assurance, while recognizing that the benefit depends on deploying the module within its validated boundary and approved mode.
Compliance officers and assessors
Where controls or contracts reference validated cryptographic modules, FIPS 140-3 validation may serve as supporting evidence. Because it is distinct from PCI DSS and other PCI standards, assessors should confirm the applicable requirement against the current published PCI standard rather than treating FIPS 140-3 validation as automatically satisfying a PCI control.
Payment processors, acquirers, and merchant risk teams
Organizations that depend on encryption, tokenization, and PIN-handling systems built on cryptographic modules may reference FIPS 140-3 validation during vendor due diligence and risk assessment, while confirming how that validation maps to their specific compliance obligations.

Inside FIPS 140-3

Cryptographic Module Validation Program (CMVP)
The validation program, jointly operated by NIST and the Canadian Centre for Cyber Security, under which cryptographic modules are tested against FIPS 140-3 requirements by accredited laboratories. A module's validation status and certificate details are published on the CMVP validation list.
Security levels
FIPS 140-3 defines multiple security levels (commonly described as Levels 1 through 4) that impose progressively stronger requirements, ranging from basic algorithm correctness to physical tamper resistance and environmental protections. The appropriate level depends on the deployment environment and threat model, not on the label alone.
Cryptographic module boundary
The defined physical or logical perimeter that contains the cryptographic functions, keys, and sensitive parameters subject to validation. What is inside versus outside the boundary determines what the validation actually covers.
Approved algorithms and modes
The set of cryptographic algorithms and modes recognized as acceptable for use within a validated module. Using an approved algorithm outside a validated module, or in a non-approved mode, does not by itself confer FIPS 140-3 validation.
Relationship to ISO/IEC standards
FIPS 140-3 is aligned with international cryptographic module standards (ISO/IEC 19790 and associated testing requirements), representing an update over the prior FIPS 140-2 generation. Practitioners should confirm the current requirements and transition timelines against official NIST and CMVP publications rather than assuming fixed dates.

Common questions

Answers to the questions practitioners most commonly ask about FIPS 140-3.

Does FIPS 140-3 validation of a cryptographic module make my payment environment PCI DSS compliant?
No. FIPS 140-3 is a U.S. and Canadian standard governing the security of cryptographic modules; it is validated by the Cryptographic Module Validation Program, not by PCI SSC. Using a FIPS 140-3 validated module may help satisfy expectations around strong cryptography in certain PCI DSS requirements, but it does not by itself establish PCI DSS compliance. PCI DSS covers a much broader set of controls, and readers should confirm applicable requirements against the current published standard rather than assuming validation of one module equals compliance.
Is FIPS 140-3 the same thing as encryption, so that a validated module means my data is protected?
No. FIPS 140-3 does not encrypt data; it is a standard that specifies security requirements for the cryptographic module that implements cryptographic functions such as encryption, hashing, and key management. Validation attests that the module meets defined security requirements when used correctly, but protection of data still depends on how the module is configured, which algorithms and key strengths are used, how keys are managed, and how the module fits into your overall architecture. Encryption, tokenization, truncation, masking, and hashing remain distinct techniques whose effect depends on implementation and validation, not on the presence of a validated module alone.
How do I confirm that a cryptographic module I plan to use is actually FIPS 140-3 validated?
Verify the module against the validation records maintained by the Cryptographic Module Validation Program rather than relying on a vendor claim of being FIPS-based or FIPS-compliant, which is not the same as validated. Confirm that the specific module version, configuration, and operational environment match what was validated, since validation applies to a defined boundary and configuration. Also confirm the security level and the cryptographic functions covered are appropriate for your intended use.
What is the difference between a module being FIPS 140-3 validated and running in an approved mode of operation?
A module may be validated but still support non-approved algorithms or configurations. To rely on the validation for a given deployment, the module generally must be operated in its approved mode as described in its security policy, using only the approved algorithms and settings. Operating outside that mode can mean the protections you are depending on are not the ones that were validated, so confirm the configuration guidance in the module's documentation.
How does FIPS 140-3 relate to PCI PIN and PCI P2PE requirements for cryptographic hardware?
FIPS 140-3 is a separate standard from PCI PIN and PCI P2PE, which are distinct PCI SSC standards governing PIN security and point-to-point encryption respectively. Those PCI programs have their own device and hardware security module requirements and their own validation processes. A FIPS 140-3 validation may be referenced or accepted in some contexts, but it does not substitute for meeting the specific requirements of PCI PIN or PCI P2PE. Confirm the applicable expectations against the current published version of each relevant standard.
What should I plan for regarding transition from earlier FIPS 140 versions to FIPS 140-3?
Because validation programs manage transitions between standard versions on published timelines, plan by checking the current status of your modules in the validation records and identifying whether existing validations remain listed or are moving to a historical or sunset status. Rather than assuming fixed dates, confirm transition timelines and any re-validation needs with the governing validation program and your vendors, and factor lead time for procurement or reconfiguration into your remediation planning.

Common misconceptions

A product labeled 'FIPS 140-3 compliant' is the same as one that is FIPS 140-3 validated.
Only modules that have completed CMVP testing and appear on the published validation list are validated. Vendor claims of being 'compliant,' 'designed to,' or 'uses FIPS-approved algorithms' are not equivalent to holding an active CMVP certificate, and the validated version, configuration, and boundary must match what is deployed.
Using a FIPS 140-3 validated module makes a system PCI DSS compliant or automatically satisfies encryption requirements.
FIPS 140-3 governs the validation of cryptographic modules; it is a separate program from PCI DSS. A validated module can support strong cryptography, but PCI DSS scope and compliance depend on how keys are managed, how data is protected, and how the overall implementation is designed and validated, not on the presence of a certificate alone.
Any FIPS 140-3 validation provides the same level of protection.
The security levels differ substantially, and validation is scoped to a specific module boundary, version, and configuration. A Level 1 software validation and a Level 3 tamper-resistant hardware validation address different threats, so the level and boundary must be matched to the deployment's requirements.

Best practices

Verify the specific module, version, and configuration on the official CMVP validation list rather than relying on vendor marketing claims of compliance.
Confirm that the way you deploy and operate the module matches its validated configuration and stays within the defined cryptographic module boundary, since operating outside it can void the assurance the validation provides.
Select the FIPS 140-3 security level appropriate to your threat model and environment, recognizing that higher levels add physical and environmental protections that lower levels do not.
Confirm current requirements, applicable algorithms and modes, and any transition timelines against official NIST and CMVP publications rather than assuming fixed dates or a fixed relationship to FIPS 140-2.
Treat FIPS 140-3 validation as one input to, not a substitute for, broader compliance obligations such as PCI DSS, and separately validate key management and data protection controls.
Track the validation status of modules over time, as certificates and applicable requirements can change, and plan for revalidation or migration when a module's status or your configuration changes.