Category: Cryptography & Encryption

FIPS 140-3

Also known as: FIPS 140-3, FIPS PUB 140-3, Federal Information Processing Standard Publication 140-3

Simply put

FIPS 140-3 is a U.S. government computer security standard used to validate cryptographic modules, which are the hardware or software components that protect sensitive data through encryption. It is the current version of the standard and is used when federal departments and agencies design, implement, or operate cryptographic modules. Validation against the standard is carried out through a formal program rather than being self-declared.

Formal definition

FIPS 140-3, titled 'Security Requirements for Cryptographic Modules,' is a Federal Information Processing Standard that specifies security requirements to be satisfied by cryptographic modules operated by or on behalf of federal departments and agencies. The standard identifies the Cryptographic Module Validation Program (CMVP), a joint effort of the U.S. and Canadian governments, as the validation authority for modules claiming conformance. Practitioners should note that FIPS 140-3 governs the validation of cryptographic modules specifically and does not by itself constitute a broader system authorization; readers should verify current effective dates, applicable revisions, and CMVP transition timelines against the authoritative NIST/CSRC publications, as validation status and program requirements evolve over time.

Why it matters

FIPS 140-3 matters because it establishes a common, government-recognized baseline for the cryptographic modules that protect sensitive federal data. Rather than relying on a vendor's own assertion that its encryption is sound, the standard channels those claims through an independent validation process, giving agencies and their contractors a defensible basis for trusting that a module's cryptography has been tested against published security requirements. For compliance officers and system owners, this distinction between self-declared and formally validated cryptography is often the difference between meeting and failing a procurement or authorization requirement.

Because FIPS 140-3 is the current version of the standard for validating cryptographic modules operated by or on behalf of federal departments and agencies, it frequently appears as a prerequisite in acquisition language and system security requirements. A practical consequence is that organizations may need to confirm not only that a product uses strong algorithms, but that the specific module is validated under the applicable program and that its validation remains current. Practitioners should note that validation status and program requirements evolve over time, so a module considered acceptable at one point may require re-verification against current CMVP information.

A common expert correction is that FIPS 140-3 validation of a cryptographic module is not the same as a broader system authorization. Validation addresses the module specifically; it does not by itself establish that an information system is compliant, secure, or authorized to operate. Treating a validated module as if it satisfies wider compliance obligations conflates a narrow cryptographic assurance with an overall security posture, and readers should confirm how module validation fits within their applicable authorization framework.

Who it's relevant to

Compliance officers and ISSMs

Those responsible for meeting federal security requirements need to confirm that cryptographic modules in scope are validated under the applicable program and remain current. They should treat module validation as one element of compliance, not as evidence of overall system security or authorization, and verify current CMVP status against authoritative sources.

Government contractors and product vendors

Organizations designing, implementing, or supplying cryptographic modules for use by or on behalf of federal departments and agencies may need their modules validated through the CMVP rather than self-declaring conformance. They should track evolving program requirements and transition timelines that affect whether a module's validation is accepted.

Authorizing officials and system owners

AOs and system owners relying on encryption to protect sensitive data should understand that FIPS 140-3 validation applies to the module specifically and does not by itself authorize a system. They should confirm how validated modules fit within their broader authorization framework and verify current effective dates and revisions.

Auditors and assessors

Assessors evaluating cryptographic protections should check that modules are validated through the CMVP and that validation status is current as of the applicable revision, distinguishing a validated module from a mere claim of strong cryptography, and confirming details against the authoritative NIST/CSRC publications.

Inside 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-3 requirements. Validation is performed by accredited laboratories, and a module is considered FIPS 140-3 validated only when it appears on the CMVP validated modules list. Readers should verify a module's current status directly against the official CMVP list.

Security Levels

FIPS 140-3 generally defines multiple security levels reflecting increasing rigor of physical and logical protections for a cryptographic module. The appropriate level depends on the system's risk profile and the sensitivity of the data being protected; the specific level required is typically determined by agency policy or applicable baselines rather than by FIPS 140-3 alone.

Relationship to ISO/IEC Standards

FIPS 140-3 aligns with international standards for cryptographic module requirements and testing, representing a shift from the self-contained structure of the prior revision. Practitioners should confirm the precise referenced standards and their applicability against the current authoritative NIST publication.

Scope: Cryptographic Modules, Not Systems

FIPS 140-3 addresses the security requirements for the cryptographic module itself, including its design, implementation, and testing. It does not, on its own, address how the module is deployed, configured, or integrated into a larger information system, which remains the responsibility of the implementing organization.

Governing Authority

FIPS 140-3 is a Federal Information Processing Standard issued by NIST. Its use is generally required for the protection of sensitive but unclassified information in federal systems where cryptography is employed; classified national security systems may be subject to separate requirements outside the scope of this standard.

Common questions

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

Does a FIPS 140-3 validation certify that an entire product or system is secure?

No. FIPS 140-3 validation applies to a specific cryptographic module, not to a whole product, application, or information system. The validation attests that the defined cryptographic boundary meets the applicable requirements at a stated security level; it does not certify the security of surrounding components, the correctness of how the module is deployed, or the overall system posture. Treating a module validation as a product-wide security guarantee is a common error, compliance of a component is not the same as security of the system, and the module must still be operated in its validated (approved mode) configuration to remain within scope.

Is FIPS 140-3 just a newer name for FIPS 140-2, so the two are interchangeable?

No. FIPS 140-3 is a distinct successor standard, not merely a rebranding. While it addresses the same general subject, security requirements for cryptographic modules, it references different underlying international standards and has its own testing and validation processes administered under the Cryptographic Module Validation Program (CMVP). Modules are validated against one standard or the other, and a FIPS 140-2 certificate is not automatically equivalent to a FIPS 140-3 certificate. Readers should verify the specific standard a given module was validated against and confirm the current status of legacy certificates against authoritative CMVP sources rather than assuming equivalence.

How do I confirm that a cryptographic module I intend to use is actually FIPS 140-3 validated?

Confirmation generally comes from checking the module against the official validation list maintained under the Cryptographic Module Validation Program (CMVP), rather than relying on a vendor's marketing claim of being 'FIPS compliant' or 'FIPS ready.' You should verify the specific module name, version, and certificate details, the standard it was validated against, and its current status, since certificate status can change over time. This entry does not track individual certificates or their status; consult the current authoritative CMVP listings to confirm.

What is the difference between a module being 'FIPS validated' and a system being configured to use it correctly?

Validation is a property of the cryptographic module as tested by an accredited laboratory and confirmed under the CMVP. Correct configuration is an operational responsibility: a validated module must typically be operated in its approved (FIPS) mode of operation, using only the algorithms and key management practices covered by its validation, for the deployment to be considered consistent with the validation. Deploying a validated module outside its approved mode can place operations outside the scope of the validation. Implementation and configuration specifics should be confirmed against the module's security policy and current official guidance.

Where might FIPS 140-3 validated cryptography be expected within a compliance program?

FIPS 140-3 is commonly referenced where cryptographic protection of information is required, and various federal frameworks point to validated cryptographic modules when cryptography is used to protect covered information. The precise expectation depends on the governing authority, the type of information (for example, Controlled Unclassified Information versus national security systems), applicable baselines, and any agency or contractual tailoring. Because these requirements are set by the relevant framework or contract rather than by the standard itself, readers should confirm where and how validated cryptography is required against the current authoritative sources for their specific context.

What should I do if a FIPS 140-3 certificate for a module I rely on changes status or moves toward a legacy or historical state?

Certificate status is time-sensitive and can transition over time, so it should be treated as something to monitor rather than a one-time check. If a module's status changes, you should evaluate the impact on any authorization or compliance posture that relied on it, since continued reliance on a module whose status has changed may affect assessments. This entry does not define transition timelines or remediation steps; verify current certificate status and applicable transition guidance through the authoritative CMVP sources and confirm any resulting obligations with the relevant authorizing or contracting authority.

Common misconceptions

A product that uses FIPS-approved algorithms is automatically FIPS 140-3 compliant.

Using approved cryptographic algorithms is not equivalent to validation. A module must undergo testing by an accredited laboratory and appear on the CMVP validated modules list to be considered FIPS 140-3 validated. Algorithm use alone does not confer validation status.

FIPS 140-3 fully replaced FIPS 140-2 immediately upon its introduction.

The transition between revisions is phased. Previously validated modules and the acceptance of validations under the prior revision have generally been governed by CMVP transition timelines. Readers should verify the current status of any given validation and the applicable sunset dates against official CMVP guidance rather than assuming a single hard cutover.

FIPS 140-3 validation means a system as a whole is secure or compliant.

Validation applies to the cryptographic module, not to the surrounding information system. Proper configuration, key management, and deployment within an approved mode of operation remain the implementer's responsibility, and validation of a module does not by itself satisfy broader compliance obligations under frameworks such as FISMA or the RMF.

Best practices

Confirm a module's validation status directly against the official CMVP validated modules list rather than relying on vendor marketing claims of FIPS support.

Determine the required security level based on your system's risk profile, data sensitivity, and applicable agency policy or control baseline, since FIPS 140-3 alone does not dictate which level applies.

Ensure the validated module is operated in its approved mode of operation, as configuration outside that mode can void the applicability of the validation.

Track CMVP transition timelines and the status of any modules validated under the prior revision, and plan remediation before applicable sunset dates.

Treat module validation as one component of system security, and separately address key management, integration, and deployment to meet broader compliance requirements.

Verify all specific requirements, referenced standards, and effective dates against the current authoritative NIST publication and CMVP guidance before making procurement or accreditation decisions.