Artifact GuideGLOBALFIPS 140-3

FIPS 140-3 compliance guide

A practical guide for turning FIPS 140-3 cryptographic module requirements into scoped claims, validation evidence, and procurement checks.

Use it to prepare independent review or supplier due diligence; it is not a substitute for CMVP validation, CST laboratory testing, or operational guidance.

Back to main artifact Review sources

Author

Sorena AI

Published

May 9, 2026

Updated

May 9, 2026

Sections

Structured answer sets in this page tree.

Primary sources

Cited legal and guidance references.

Publication metadata

Sorena AI

Published May 9, 2026

Updated May 9, 2026

Overview

FIPS 140-3 applies to cryptographic modules used by U.S. federal agencies to protect sensitive information, and private or commercial organizations may also adopt it. A useful compliance review starts with the module boundary, the claimed security level, the approved cryptographic services, the tested operational environment, and the evidence that ties each public or procurement claim to the CMVP validation record.

Section 1

Define the cryptographic module claim before using compliance language

FIPS 140-3 compliance is a module claim, not a blanket product or platform claim. Start by naming the cryptographic module, its version, its boundary, and the product or service configurations that rely on it.

The standard covers hardware, software, firmware, and hybrid modules. It organizes requirements across cryptographic module specification, interfaces, roles and authentication, software or firmware security, operating environment, physical security, non-invasive security, sensitive security parameter management, self-tests, life-cycle assurance, and mitigation of other attacks.

Record the exact module name, version, boundary, and operational environment before writing marketing, procurement, or control text.
Separate the module from the surrounding application, cloud service, appliance, or deployment environment so readers can see what is actually validated or under review.
State the claimed FIPS 140-3 security level only for the module and requirement areas supported by the validation evidence.
Keep approved and non-approved services distinct, especially when the same product exposes both FIPS-approved and non-approved cryptographic functions.

Sources for this answer

NIST FIPS 140-3 security requirements for cryptographic modules

Supports the page scope: FIPS 140-3 specifies security requirements for cryptographic modules, provides four qualitative security levels, and lists the requirement areas covered by the standard.

CMVP Implementation Guidance for FIPS 140-3

Supports the need to distinguish module boundaries, approved services, operational environments, binding or embedding cases, and the evidence expected in CMVP submissions.

Section 2

Use CMVP and CAVP evidence for validation and procurement checks

The Cryptographic Module Validation Program validates cryptographic modules to FIPS 140-3 using testing performed by accredited Cryptographic and Security Testing laboratories. For procurement or customer review, the evidence pack should point to the CMVP module record and to any relevant algorithm validation evidence rather than relying on a vendor statement alone.

CAVP evidence matters because algorithm validation certificates identify the validated algorithm implementation, version, and tested operational environment. A module review should confirm that the algorithm evidence matches the module configuration being claimed.

Capture the CMVP certificate number, module name, version, status, security policy, and tested operational environment when those are available for the module under review.
Check CAVP certificates for the approved algorithms the module claims to use, including the implementation version and operational environment.
For embedded or bound modules, identify the existing validated module by name, certificate number, and version, and separate its services, algorithms, sensitive security parameters, self-tests, and zeroization mechanisms from the module under review.
Do not use the CMVP Historical list as procurement evidence for a new purchasing decision unless the procurement policy explicitly accepts that status.

Sources for this answer

NIST FIPS 140-3 security requirements for cryptographic modules

Explains that CMVP validates cryptographic modules and that accredited CST laboratories perform conformance testing; it also warns that the Historical list should not be used for procurement decisions.

CMVP Implementation Guidance for FIPS 140-3

Supports certificate-level evidence requirements for algorithm implementations, module validations, operational environments, and bound or embedded module claims.

NIST CAVP validation search

Public NIST search entry point for checking cryptographic algorithm validation records used in a FIPS 140-3 evidence pack.

Recommended next step

Operationalize FIPS 140-3 compliance

Use this FIPS 140-3 guide to scope module claims, request certificate evidence, and prepare review tasks before procurement, audit, or customer assurance.

Assessment workflow

Open Assessment Autopilot for FIPS 140-3

Convert FIPS 140-3 module-scope questions into evidence requests, owners, and review tasks.

Explore next step

Research workflow

Research FIPS 140-3 source questions

Use cited NIST and CMVP sources to resolve scope, validation, algorithm, and procurement questions before implementation.

Explore next step

Talk to Sorena

Talk through implementation

Review module scope, supplier evidence, validation records, and next FIPS 140-3 compliance actions with Sorena.

Explore next step

Section 3

Build a FIPS 140-3 compliance evidence pack

A FIPS 140-3 evidence pack should make the claim reviewable without expanding it beyond the validated module. The pack should connect each assertion to the module boundary, the approved services, the security policy, the tested operational environment, and the certificate or test evidence that supports the assertion.

The security level should be chosen for the application and environment in which the module will be used. Conformance to FIPS 140-3 does not, by itself, prove that the whole system is secure; operators still need to decide whether the system security is sufficient for the actual use case.

Boundary evidence: module diagrams, physical or logical boundary descriptions, interfaces, ports, and excluded components.
Service evidence: roles, services, authentication, approved service indicators, non-approved functions, and any mode-selection behavior users must follow.
Algorithm evidence: CAVP certificates, approved security functions, key management methods, entropy source evidence, and DRBG or self-test records where applicable.
Operational evidence: tested operating systems, processors, hardware platforms, firmware versions, cloud or appliance configurations, and change-impact notes.
Assurance evidence: security policy, validation test report references, lifecycle records, vulnerability or CVE handling notes, and reassessment triggers for module or environment changes.

Sources for this answer

NIST FIPS 140-3 security requirements for cryptographic modules

Grounds the evidence categories in the standard's module requirement areas and its statement that security level selection depends on the application, environment, and services.

CMVP Implementation Guidance for FIPS 140-3

Supports evidence expectations for approved service indicators, algorithm certificates, operational environments, entropy, self-tests, and module change analysis.

Section 4

Review supplier and product claims without overstating validation

Treat every supplier claim as a scope question. A product that contains a FIPS 140-3 validated module is not automatically validated as an entire product, and a certificate for one operational environment does not automatically cover a different environment.

For software, firmware, and hybrid modules, operational environment matching is a recurring validation issue. If the algorithm or module evidence was tested in one environment, confirm whether the claimed deployment is identical to, or fully included in, the tested environment before relying on the claim.

Ask whether the claim is for a validated cryptographic module, an algorithm implementation, a product containing a module, or an internal configuration using a module.
Confirm the certificate number, module version, security policy, and operational environment against the public validation record.
Check whether the deployment requires a specific approved mode of operation, service indicator, configuration step, or user procedure.
If the module relies on another validated module, confirm the bound or embedded module is identified and that only the used functionality is cited.
Escalate gaps when the supplier cannot connect the public claim to certificate scope, tested environment, approved services, or current CMVP guidance.

Sources for this answer

CMVP Implementation Guidance for FIPS 140-3

Grounds the warning about operational environment matching, bound or embedded module evidence, and certificate-scope checks.

NIST CMVP program page

Public NIST program page for the Cryptographic Module Validation Program referenced by FIPS 140-3.

Section 5

Checklist for FIPS 140-3 compliance review

Use this checklist before publishing a claim, accepting a supplier assertion, or relying on a module for a federal, regulated, or customer-driven security requirement.

Define the module boundary and version: what exact cryptographic module is under review, and what surrounding product or service is outside the claim?
Define the security claim: which FIPS 140-3 security level and requirement areas are supported by evidence?
Verify validation evidence: which CMVP certificate, security policy, validation record, and CAVP algorithm certificates support the claim?
Verify operation: what approved mode, service indicators, roles, authentication, self-tests, entropy assumptions, and key-management behavior must be in place?
Verify environment: which operating systems, processors, firmware, appliances, or cloud configurations were tested, and does the intended deployment match?
Verify changes: what module, algorithm, supplier, firmware, operational-environment, or configuration changes would require re-review before the claim is reused?

Sources for this answer

NIST FIPS 140-3 security requirements for cryptographic modules

Supports checklist items for security levels, approved functions, module requirement areas, and the limits of relying on conformance alone.

CMVP Implementation Guidance for FIPS 140-3

Supports checklist items for certificate scope, approved services, operational environment matching, and change-sensitive validation evidence.

Primary sources