Skip to main content
Control Institute
Category: Technical Security Controls

FIPS-Validated Cryptography

Also known as: FIPS 140 validated cryptography, CMVP-validated cryptographic module
Simply put

FIPS-validated cryptography refers to encryption tools that have been formally tested and confirmed to meet U.S. government security standards for protecting sensitive information. The testing is carried out through an official program run by NIST, and a module that passes is added to a public list of validated products. This is stronger than merely claiming to follow the standard, because an independent, government-approved laboratory has actually verified the module.

Formal definition

FIPS-validated cryptography denotes a cryptographic module that has been validated by the Cryptographic Module Validation Program (CMVP) to meet the requirements specified in the applicable Federal Information Processing Standard (FIPS 140-3, with FIPS 140-3 validations currently being accepted). Validation is performed through testing by a NIST-accredited laboratory, after which the module receives a certificate indicating conformance to the standard's security requirements and is placed on the CMVP Active list. Per CMVP practice, validated modules remain on the Active list for a defined period (typically 5 years, or 2 years in certain cases) before transitioning off. This concept should be distinguished from mere FIPS 'compliance': validation reflects an actual tested and certified module rather than a self-asserted claim of meeting the requirements. FIPS validation is a U.S. federal cryptographic standard and is separate from the SOC 2 Trust Services Criteria and ISO/IEC 27001 requirements; where a scope invokes cryptographic controls, use of a FIPS-validated module may support but does not by itself satisfy those frameworks.

Why it matters

For organizations handling sensitive data, the distinction between cryptography that claims to follow a standard and cryptography that has been independently validated is significant. A vendor may assert that its encryption 'uses FIPS-approved algorithms' or is 'FIPS compliant,' but only a module validated through the Cryptographic Module Validation Program (CMVP) has actually been tested by a NIST-accredited laboratory and issued a certificate confirming conformance to the security requirements of the applicable standard. This independent verification matters because implementation errors in cryptography are common and difficult to detect through self-assessment alone; validation provides assurance that a specific module, as tested, meets defined requirements rather than relying on an unverified claim.

FIPS validation is a U.S. federal cryptographic standard and is distinct from both the SOC 2 Trust Services Criteria and ISO/IEC 27001 requirements. Where an audit or certification scope invokes cryptographic controls, use of a FIPS-validated module may help support those controls, but it does not by itself satisfy either framework. Compliance teams should treat FIPS validation as evidence that can strengthen a control narrative rather than as a substitute for demonstrating that cryptography is appropriately selected, deployed, and managed within the environment.

Validation status is also time-bound. Under CMVP practice, validated modules remain on the Active list for a defined period, typically five years, or two years in certain cases, before transitioning off. A module that was validated in the past may no longer be on the Active list, so relying on a module's historical validation without confirming its current status can create a gap between what an organization believes it has in place and what remains actively validated.

Who it's relevant to

Compliance and GRC Managers
When scoping SOC 2 or ISO 27001 engagements that involve cryptographic controls, GRC teams should understand that FIPS validation can support a control narrative but does not by itself satisfy the Trust Services Criteria or the ISMS requirements. Confirming a module's current status on the CMVP Active list, rather than accepting a vendor's 'FIPS compliant' claim, provides stronger evidence for the encryption controls in scope.
Security Engineers and Architects
Engineers selecting and deploying encryption need to distinguish between a validated module and one that merely uses approved algorithms. Choosing a module that appears on the CMVP Active list, and tracking when that validation is due to transition off the list, helps ensure the cryptography in production remains verifiably tested rather than self-asserted.
Auditors and Assessors
Assessors reviewing cryptographic controls should treat FIPS validation as independently verified evidence, checking the CMVP Active list to confirm a module's current standing. Because validation is a U.S. federal standard separate from SOC 2 and ISO 27001, auditors should assess how a validated module fits within the broader control environment rather than treating validation as equivalent to meeting either framework.

Inside FIPS-Validated Cryptography

FIPS 140 Validation
A validation of a cryptographic module against the U.S. Federal Information Processing Standard maintained under the Cryptographic Module Validation Program (CMVP), a joint program of NIST and its Canadian counterpart. Validation confirms that a module has been independently tested against the standard's requirements; the specific edition (for example, FIPS 140-2 or FIPS 140-3) should be stated when citing a validation, since requirements and transition timelines differ by version.
Validated Module Boundary
The clearly defined logical or physical boundary of the cryptographic module that was submitted for testing. Validation applies only to the specific module, version, and operating configuration listed on the CMVP validation certificate, not to the entire product or system in which it is embedded.
Approved Algorithms and Modes
Cryptographic algorithms and modes that fall within the scope of the validation. Using a validated module does not by itself guarantee FIPS-compliant operation; the module must typically be operated in its designated approved (or FIPS) mode and configured to use approved algorithms for the cryptography to be considered validated.
Testing Laboratory and Certificate
Validation is performed by an accredited third-party testing laboratory, and successful modules receive a certificate listed publicly by the CMVP. The certificate identifies the module, version, applicable standard edition, and the tested configuration.
Relevance to Compliance Frameworks
FIPS-validated cryptography may be referenced within a SOC 2 examination or an ISO/IEC 27001 ISMS as supporting evidence for cryptography-related controls, depending on scope. Neither framework universally mandates FIPS validation; whether it is relevant depends on the scope, applicable criteria or Statement of Applicability, and any customer or regulatory requirements.

Common questions

Answers to the questions practitioners most commonly ask about FIPS-Validated Cryptography.

Does SOC 2 or ISO 27001 require FIPS-validated cryptography?
Neither framework mandates FIPS-validated cryptography as a universal requirement. SOC 2's Trust Services Criteria address encryption and cryptographic controls in terms of whether they are designed and operating to meet the applicable criteria, but the specific standard used is a scoping and control-design decision. Similarly, ISO 27001's Annex A includes reference controls related to cryptography that are selected via the Statement of Applicability and informed by risk assessment. Whether FIPS validation is expected typically depends on the service commitments, customer requirements, and any overlapping regulatory obligations rather than on the frameworks themselves.
Is FIPS-validated cryptography the same as using a FIPS-approved algorithm?
No. Using a FIPS-approved algorithm is not the same as using a FIPS-validated cryptographic module. Validation refers to a formal process in which a cryptographic module is tested and confirmed against the applicable standard, whereas simply implementing an approved algorithm does not by itself confer validated status. Auditors and certification bodies evaluating your controls may distinguish between the two, so it is important to describe accurately whether you rely on validated modules or merely approved algorithms, and to align that description with your stated commitments.
How should we scope FIPS-validated cryptography within a SOC 2 examination?
Scoping typically involves identifying where cryptographic controls support the applicable Trust Services Criteria, most often the Security (Common Criteria) category and, depending on scope, Confidentiality. You would define which systems, data flows, and cryptographic modules are in scope, then describe the related controls so the service auditor can assess suitability of design (Type I) and, over a defined review period, operating effectiveness (Type II). Because the specifics depend on your service commitments and the auditor's judgment, discuss expectations with your CPA firm during scoping rather than assuming a fixed approach.
How does FIPS-validated cryptography relate to the ISO 27001 Statement of Applicability?
If cryptographic controls are relevant to your risk assessment, the associated Annex A reference controls would typically be marked applicable in the Statement of Applicability, with your implementation approach documented. Whether that implementation relies on FIPS-validated modules is a design choice you justify based on identified risks and any applicable requirements. Keep in mind that Annex A was restructured in the 2022 revision, so reference the version you are certifying against when documenting cryptographic controls, and remember that the certificate covers only the defined scope of your ISMS.
What evidence typically demonstrates FIPS-validated cryptography during an audit?
In most engagements, evidence may include documentation identifying the specific validated modules in use, configuration records showing that validated modules are enabled where required, policies governing cryptographic use, and records demonstrating the control operated over the review period for a SOC 2 Type II. The exact evidence expected varies by auditor or certification body and by the controls in scope, so confirm evidentiary expectations early. Note that such evidence attests only to the controls and, for Type II, the period covered, and does not guarantee freedom from breaches.
Does implementing FIPS-validated cryptography for one framework satisfy the other?
Not automatically. While cryptographic controls can often be mapped across SOC 2 and ISO 27001, the mapping is partial, and satisfying the expectations of one framework does not by itself satisfy the other. Each is evaluated under its own model, SOC 2 as an attestation examination under the AICPA SSAE 18 standard resulting in a report, and ISO 27001 as a certification against a management system standard. Plan your cryptographic controls to address the specific criteria, scope, and requirements of each engagement rather than assuming reciprocity.

Common misconceptions

Using a FIPS-approved algorithm (such as AES) means your cryptography is FIPS-validated.
Validation applies to a tested cryptographic module in a specific configuration, not to an algorithm in the abstract. Implementing an approved algorithm outside a validated module, or running a validated module outside its approved mode, does not typically constitute FIPS-validated cryptography.
FIPS validation is a mandatory requirement for SOC 2 or ISO 27001.
Neither framework universally requires FIPS-validated cryptography. In a SOC 2 examination, cryptography-related expectations depend on the Trust Services Criteria in scope and the auditor's evaluation; in ISO 27001, applicable cryptographic controls are selected through the Statement of Applicability informed by risk assessment. FIPS validation may be relevant where customer contracts or regulations require it, but it is not an inherent obligation of either standard.
A FIPS validation certificate covers the whole product indefinitely.
A certificate covers only the specified module, version, and tested configuration under a particular edition of the standard. It does not extend automatically to other components, later versions, or reconfigured deployments, and validations are subject to program transition timelines that vary by edition.

Best practices

Confirm the exact module, version, and standard edition (for example, FIPS 140-2 or FIPS 140-3) on the CMVP certificate rather than relying on vendor marketing claims of being 'FIPS compliant'.
Verify that validated modules are actually operated in their approved (FIPS) mode and configured to use approved algorithms, since a validated module used outside that mode may not qualify.
Determine whether FIPS validation is actually relevant to your engagement by reviewing the SOC 2 Trust Services Criteria in scope or the ISO 27001 Statement of Applicability, along with any customer or regulatory requirements, rather than assuming it is required.
Maintain documentation mapping deployed modules to their certificates so this evidence can support cryptography-related controls during a SOC 2 examination or an ISO 27001 ISMS assessment.
Track applicable program transition timelines and edition changes so that validations relied upon do not lapse relative to your compliance and contractual commitments.
Scope validation claims precisely to the module boundary and configuration, and avoid representing that an entire system or product is FIPS-validated when only a component is.