Skip to main content
Comply Defense
Category: Cryptography & Encryption

FIPS 140-2

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

FIPS 140-2 is a U.S. government standard that defines the security requirements a cryptographic module must meet to be trusted for protecting sensitive information. A product that has been tested and validated against this standard has demonstrated that its encryption components work as intended. Note that validation applies to the specific cryptographic module tested, and readers should verify current status and applicability against official sources, as newer revisions of the FIPS 140 series exist.

Formal definition

FIPS 140-2 is a Federal Information Processing Standard, issued and maintained by NIST, that specifies the security requirements to be satisfied by a cryptographic module protecting sensitive information in information technology systems. Conformance is established through independent testing under the Cryptographic Module Validation Program (CMVP), which uses Derived Test Requirements and associated implementation guidance covering Approved and non-Approved security functions. Validation is scoped to a particular module configuration rather than to a general product line, and practitioners should distinguish validation of a cryptographic module from broader system authorization or security assurances. As of the applicable revision, requirements and program guidance may differ from successor standards in the FIPS 140 series, and the reader should confirm current authoritative text.

Why it matters

FIPS 140-2 matters because it provides a government-recognized basis for trusting that a cryptographic module actually performs as claimed. Rather than relying on a vendor's assertion that its encryption is sound, agencies and contractors can point to independent validation under the Cryptographic Module Validation Program (CMVP), maintained by NIST, as evidence that the module was tested against defined security requirements. In many federal contexts, the use of validated cryptographic modules is treated as a baseline expectation for protecting sensitive information, which is why the standard frequently appears in procurement language, control implementation statements, and assessment findings.

A critical point that experienced practitioners emphasize is that validation is scoped narrowly to a specific module configuration that was tested, not to a general product line or a vendor's broader portfolio. Purchasing a product from a vendor that holds some FIPS 140-2 validations does not automatically mean the particular version, build, or operating configuration you deploy is itself validated. Readers should confirm the exact module, version, and configuration status against the official CMVP listings rather than assuming coverage from marketing claims.

Equally important, validation of a cryptographic module should not be confused with authorization of a system or with broader security assurance. A validated module addresses whether the cryptography works as intended within its defined boundary; it does not by itself demonstrate that a system is securely configured, properly integrated, or authorized to operate. Because newer revisions of the FIPS 140 series exist and program guidance evolves, the applicable requirements and current validation status should always be verified against authoritative NIST sources.

Who it's relevant to

Information System Security Managers and Security Engineers
Those responsible for implementing and documenting cryptographic protections need to confirm that the specific modules deployed are validated in the configuration they run. This means checking the exact module, version, and operating configuration against official CMVP listings rather than relying on general vendor claims, and distinguishing module validation from system-level authorization.
Government Contractors and Product Vendors
Contractors supplying products intended to protect sensitive government information often need to demonstrate that their cryptographic modules have been validated under the CMVP. Vendors should be precise about which module configurations are validated, since validation applies only to the specific tested module and not to an entire product line.
Assessors and Auditors
Personnel evaluating cryptographic implementations use FIPS 140-2 as a reference point for whether a module has been independently tested. Assessors should verify current validation status against authoritative NIST sources, recognize that newer revisions of the FIPS 140 series exist, and avoid treating a validation as evidence of broader security or authorization.
Authorizing Officials and Compliance Officers
Those making risk and authorization decisions should understand that the presence of a validated cryptographic module addresses the cryptography within its defined boundary but does not by itself satisfy system authorization or demonstrate overall security. Applicability and required revisions should be confirmed against current official sources and any governing contractual or regulatory requirements.

Inside FIPS 140-2

Standard Scope and Purpose
FIPS 140-2 is a U.S. federal standard published by NIST that specifies security requirements for cryptographic modules used to protect sensitive information in federal systems. It addresses the module itself rather than the broader system in which it operates.
Security Levels
The standard defines a graduated set of qualitative security levels intended to cover a range of applications and environments, with higher levels generally imposing more stringent physical and logical protection requirements. Practitioners should verify the specific level requirements against the current authoritative text.
Requirement Areas
FIPS 140-2 organizes requirements across multiple functional areas of a cryptographic module, such as its design, interfaces, roles and authentication, physical security, and self-tests. The precise set and naming of these areas should be confirmed against the published standard.
Validation Program
Conformance is established through the Cryptographic Module Validation Program (CMVP), jointly overseen by NIST and its Canadian counterpart, under which accredited laboratories test modules and validated modules are listed publicly. Validation applies to a specific module configuration, not to a general product line.
Relationship to Successor
FIPS 140-2 has a successor, FIPS 140-3, and the two coexist during a transition period in which previously validated modules and their certificates remain subject to defined lifecycle and sunset arrangements. Readers should verify current transition and certificate status through official CMVP sources.

Common questions

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

Does FIPS 140-2 certify an entire product or system as secure?
No. FIPS 140-2 validation applies to a specific cryptographic module, not to a full product, application, or information system. The validation covers the defined cryptographic boundary of the module as tested, and a validated module embedded in a larger product does not make that product as a whole 'FIPS validated.' Compliance with the standard for the module also should not be equated with overall security of the system in which it operates. Readers should confirm the exact boundary and scope of any validation against the module's official certificate.
Is FIPS 140-2 still current, or has it been superseded?
FIPS 140-2 is a NIST-issued standard that has been succeeded by a newer revision in the FIPS 140 series. However, modules validated under FIPS 140-2 generally remain valid for a transition period and continue to appear on the applicable validation program lists as of the applicable dates. Whether a FIPS 140-2 validated module is acceptable for a given use depends on the current program status and any transition timelines, which the reader should verify against the current authoritative NIST and program sources rather than assuming the standard is either fully retired or indefinitely current.
How do I confirm that a specific cryptographic module is actually FIPS 140-2 validated?
Validation status is established by the certificate issued through the applicable NIST validation program, which lists the module name, version, vendor, cryptographic boundary, and the security level. Practitioners should check the official validation listing for the exact module version in use, because a validated version differs from a similarly named but unvalidated build. This entry does not cover procurement or contractual verification specifics, which should be confirmed against current official program records.
What is the difference between the security levels defined in FIPS 140-2?
FIPS 140-2 defines multiple security levels that impose progressively stronger requirements across areas such as physical protection and access controls for the cryptographic module. Selecting an appropriate level generally depends on the sensitivity of the information the module protects and the applicable agency or system requirements. The specific requirements at each level should be confirmed against the current standard text, and this entry does not prescribe which level a particular deployment must meet.
Does using a FIPS 140-2 validated module satisfy all encryption requirements for CUI or DoD systems?
Not by itself. A validated cryptographic module addresses the cryptographic module requirement, but broader obligations for protecting Controlled Unclassified Information or DoD systems under the RMF may involve additional controls, configuration, and operational requirements beyond module validation. FedRAMP or civilian-agency acceptance of a module also does not automatically satisfy DoD-specific requirements. Readers should confirm the full set of applicable requirements against the governing controls and current authoritative sources.
What does it mean to operate a validated module in an approved or FIPS mode?
Many validated modules can operate in more than one configuration, and only certain configurations use the approved cryptographic functions consistent with the validation. Operating outside the approved mode can mean the deployment is not using the module as validated, even though the module itself holds a certificate. Practitioners should consult the module's security policy and current official documentation to confirm how to configure and verify approved-mode operation; this entry does not cover product-specific configuration steps.

Common misconceptions

A FIPS 140-2 validation certifies that an entire product or system is secure.
Validation applies only to the cryptographic module and its tested configuration and boundary. It does not certify the surrounding application, operating environment, or system, and compliance with the standard is not equivalent to overall security.
A product marketed as 'FIPS compliant' is the same as a FIPS 140-2 validated module.
Claims of being 'FIPS compliant' or 'FIPS ready' are not equivalent to a completed CMVP validation. Only a module with a corresponding validation certificate listed by the program has been formally validated, and the certificate covers a specific version and configuration.
FIPS 140-2 is fully replaced and no longer relevant now that FIPS 140-3 exists.
FIPS 140-2 and FIPS 140-3 coexist through a defined transition, and existing FIPS 140-2 certificates generally remain effective under program lifecycle rules until their applicable sunset. The current status of any certificate should be verified against official CMVP sources.

Best practices

Confirm that a module holds an active validation certificate listed through the CMVP rather than relying on vendor 'FIPS compliant' marketing language.
Verify that the validated configuration, module boundary, and applicable security level match your intended deployment and operating environment.
Determine which FIPS 140-2 security level your requirement calls for and confirm the specific requirements against the current authoritative NIST text.
Track the FIPS 140-2 to FIPS 140-3 transition and monitor certificate lifecycle and sunset status through official CMVP sources so procurement and renewal decisions stay current.
Treat cryptographic module validation as one component of security, not as evidence that the surrounding system, application, or authorization requirements are satisfied.
Confirm agency- or program-specific expectations for validated cryptography, since interpretations and required levels may differ across federal civilian, defense, and other environments.