Category: Cryptography & Encryption
FIPS-Validated Cryptographic Module
Also known as: FIPS 140-Validated Module, FIPS-Validated Cryptography
Simply put
A FIPS-validated cryptographic module is a piece of hardware, software, or firmware that performs encryption or other cryptographic functions and has been formally tested and confirmed to meet U.S. government security requirements. The validation is performed under the Cryptographic Module Validation Program (CMVP), and a module that passes receives a certificate showing it conforms to the FIPS 140 standard. It is important to note that being 'FIPS-validated' is not the same as merely being 'FIPS-compliant' or claiming to use approved algorithms; validation refers to formal testing and a certificate, not a self-assertion.
Formal definition
A cryptographic module that has been validated by the Cryptographic Module Validation Program (CMVP) against the applicable revision of the FIPS 140 standard, with a certificate indicating conformance to the security requirements of that standard. Per the evidence, the CMVP is currently accepting FIPS 140-3 validations, and validated modules are placed on the CMVP Active list for a defined period (described in the evidence as five years, or two years in certain cases); practitioners should verify current CMVP list status, applicable revision, and validity dates against official CMVP records rather than relying on a vendor's compliance claim. Validation is distinct from operational use: a system running in 'FIPS mode' is configured at runtime to restrict cryptographic operations to FIPS-approved algorithms, but this runtime configuration does not by itself establish that the underlying module holds a valid CMVP certificate. The evidence does not fully specify security levels, embodiment types, or agency- and program-specific requirements (for example, particular FedRAMP or DoD obligations), which readers must confirm against current authoritative sources.
Why it matters
For systems that protect Controlled Unclassified Information (CUI) and other sensitive federal data, the distinction between a FIPS-validated cryptographic module and one that merely claims to use approved algorithms is often decisive. Many federal and defense requirements call specifically for validated cryptography, meaning cryptography that carries a certificate from the Cryptographic Module Validation Program (CMVP), not a vendor's self-assertion of compliance. A compliance officer or assessor who accepts a marketing claim of 'FIPS-compliant' without confirming an active CMVP certificate risks a finding, because validation refers to formal testing and a certificate rather than a claim about algorithm selection.
Who it's relevant to
Compliance Officers and ISSMs
Those responsible for demonstrating that cryptography meets federal requirements need to confirm an active CMVP certificate for each module in scope, rather than accepting a 'FIPS-compliant' label. They should treat certificate status as time-limited, modules remain on the CMVP Active list for a defined period, and periodically re-verify list status against official CMVP records. Specific program obligations (for example, particular FedRAMP or DoD requirements) should be confirmed against current authoritative sources.
Assessors and Auditors
Assessors should look for evidence of both a valid CMVP certificate and the correct runtime configuration. A system configured in 'FIPS mode' restricts operations to FIPS-approved algorithms at runtime, but that configuration alone does not prove the underlying module is validated. Verifying the certificate number, applicable FIPS 140 revision, and validity dates on the CMVP list guards against accepting a self-asserted compliance claim as validation.
Government Contractors and Vendors
Vendors offering products to federal and defense customers should be precise in their representations, distinguishing between claiming use of approved algorithms and holding a formal CMVP validation with a certificate. Because the CMVP is currently accepting FIPS 140-3 validations and certificates carry defined validity periods, contractors should track the revision under which their modules are validated and monitor certificate expiration to avoid gaps in coverage.
System Owners and Authorizing Officials
Those making risk and authorization decisions should recognize that validated cryptography is one control among many and that a certificate does not by itself establish overall security or authorization. Because CMVP status is time-bound, authorizing officials should ensure continuous monitoring accounts for certificate validity and confirm that program- or agency-specific cryptographic requirements are met against current authoritative sources.
Inside FIPS-Validated Cryptographic Module
FIPS 140 Standard
The Federal Information Processing Standard that specifies security requirements for cryptographic modules. It exists in successive versions (such as FIPS 140-2 and FIPS 140-3), and the applicable version depends on when the module was tested and validated. Readers should verify which version governs a given module against current authoritative sources, as FIPS 140-2 validations are being phased out in favor of FIPS 140-3.
Cryptographic Module Validation Program (CMVP)
The program jointly operated by NIST and the Canadian Centre for Cyber Security that validates cryptographic modules against the FIPS 140 requirements. Validation is performed through accredited laboratories, and the resulting certificate is what distinguishes a validated module from one that merely claims FIPS-compliant algorithms.
Validation Certificate
The formal record issued upon successful CMVP validation, identifying the specific module, its version or configuration, the tested boundary, and the security level achieved. The certificate applies to the exact validated configuration; deviations in deployment may fall outside the scope of the validation.
Cryptographic Boundary
The defined physical or logical perimeter of the validated module. Only the components and functions within this boundary are covered by the validation; cryptography performed outside the boundary is not addressed by the certificate.
Security Levels
FIPS 140 defines multiple security levels reflecting increasing rigor in areas such as physical security and tamper evidence. The level appropriate for a system generally depends on the sensitivity of the information being protected and applicable agency or contractual requirements.
Approved Algorithms and Operational Mode
Validated modules implement algorithms that have been approved and separately tested (for example through algorithm validation). Modules typically must be operated in an approved or FIPS mode of operation for the protection to be considered compliant; running the same module in a non-approved mode may not satisfy the requirement.
Common questions
Answers to the questions practitioners most commonly ask about FIPS-Validated Cryptographic Module.
Is using strong or industry-standard encryption the same as using a FIPS-validated cryptographic module?
No. Employing a strong algorithm such as AES is not sufficient on its own. FIPS validation refers to a specific module that has completed testing under the Cryptographic Module Validation Program (CMVP), jointly run by NIST and the Canadian counterpart authority, and that carries a validation certificate. A product may implement an approved algorithm correctly yet still not be FIPS-validated if the module itself has not been tested and certified. Compliance requirements that call for FIPS-validated cryptography generally mean the certificated module, not merely the use of an approved algorithm. Confirm the specific requirement against the applicable control or contract language.
Does a vendor claim of 'FIPS compliant' mean the module is FIPS-validated?
Not necessarily. 'FIPS compliant' or 'FIPS capable' is marketing language that does not carry the same meaning as 'FIPS-validated.' Validation is established by a certificate issued through the CMVP, and the module's configuration must match the validated boundary and operating conditions described in that certificate. A reader should verify that a specific certificate exists and applies to the version and mode being deployed, rather than relying on a general compliance claim. Confirm details against the current official validation listing maintained by the CMVP.
How do I confirm that a particular module is FIPS-validated?
In most cases you locate the module on the CMVP validation list and identify its certificate, then match the version, platform, and operational environment against what is described in that certificate. Validation is generally specific to a defined module boundary and set of tested configurations, so a product family entry may not cover every version or build. Because listings and statuses change over time, verify the current entry directly against the authoritative CMVP source rather than a cached or third-party summary.
Do I have to run the module in a particular mode for the validation to apply?
Generally yes. Many validated modules must be operated in a specific approved or FIPS mode, and the applicable configuration is described in the module's security policy documentation associated with its certificate. Operating outside that tested configuration can mean the deployment no longer reflects the validated state, even though the same software is installed. Consult the module's security policy and vendor guidance, and verify the required settings against the current authoritative documentation for that certificate.
What happens to my deployment if a module's validation status changes?
Validation statuses can move over time as modules transition through the CMVP lifecycle, and a module's standing on the validation list may change. Because compliance requirements often reference validated modules, a change in status can affect whether a deployed configuration still meets the applicable requirement. This entry does not cover the specific remediation timelines or transition provisions, which may depend on agency tailoring and contract terms. Confirm current status and any allowed transition provisions against the authoritative CMVP source and the governing requirement.
Does FIPS validation of the cryptographic module satisfy all cryptography-related compliance obligations?
No. FIPS validation addresses the module itself, but broader obligations typically also address matters such as key management, protecting data at rest and in transit, and correct configuration within a system. Validation of the module does not by itself establish that these surrounding requirements are met, and it does not equate to overall system security or authorization. Determine which specific controls or clauses apply to your system and confirm each against the current authoritative text.
Common misconceptions
Using AES, SHA-256, or other approved algorithms means a product is FIPS-validated.
Implementing an approved algorithm is not the same as holding a CMVP validation. Validation applies to the specific cryptographic module and configuration that has completed testing and received a certificate. A product that merely uses approved algorithms without a corresponding validation certificate is generally not considered FIPS-validated.
A FIPS validation certificate covers the module however it is deployed.
The certificate applies to the specific tested version, configuration, and cryptographic boundary, and typically to operation in an approved (FIPS) mode. Deploying a different version, changing the configuration, or running outside the approved mode can place the deployment outside the scope of the validation.
FIPS validation by itself makes a system compliant or secure.
A FIPS-validated module is one control element among many. Compliance with frameworks such as the DoD RMF or requirements for protecting CUI generally requires FIPS-validated cryptography where cryptography is used, but the overall system must still satisfy the broader control set and authorization requirements. Validation of a module is not equivalent to authorization or overall security.
Best practices
Confirm that any cryptographic module in scope holds an active CMVP validation certificate, and verify the certificate number, module version, and tested configuration against the current authoritative CMVP listings rather than relying on vendor marketing claims.
Verify which FIPS 140 version governs the module and check its status, since older validations are being phased out in favor of newer ones; confirm the current position against authoritative sources.
Ensure the module is deployed in its approved (FIPS) mode of operation and in the exact validated configuration, because operation outside the tested boundary or mode may not satisfy the requirement.
Document where FIPS-validated cryptography is required within the system boundary, mapping it to the applicable requirements for protecting the relevant information (such as CUI under DoD requirements), and confirm those requirements against current official guidance.
Track certificate lifecycle status, as validations can move to historical or sunset status over time; treat a validated module as subject to ongoing verification rather than a permanent guarantee.
Distinguish module validation from system authorization in your compliance records, recognizing that a validated module supports but does not by itself satisfy assessment or authorization requirements.