Artifact GuideGLOBALFIPS 140-3

FIPS 140-3 compliance guide

Turn 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

Jul 24, 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 Jul 24, 2026

Overview

Use "validated to FIPS 140-3" only for the , version, operational environment, and conditions covered by a validation record. "Uses FIPS-approved algorithms" is a narrower algorithm claim, while "contains a validated module" describes a product dependency; neither statement makes the whole product FIPS 140-3 validated. Review the boundary, security level, approved services, tested or affirmed environment, , certificate status, sunset date, and caveats before relying on any claim.

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 , 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 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.

Keep the authority layers separate. FIPS 140-3 is the federal publication and points to ISO/IEC 19790:2012 requirements and ISO/IEC 24759:2017 test methods. The NIST SP 800-140 series adds modifications and documentation requirements. The CMVP Implementation Guidance gives technical resolutions, while the Management Manual controls program processes and submission scenarios. Sorena's checklists explain how to inspect evidence; they do not replace any of those sources.

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.

NIST FIPS 140-3 standards and related references

Explains the relationship among FIPS 140-3, ISO/IEC 19790, ISO/IEC 24759, the SP 800-140 series, the Implementation Guidance, and the Management Manual.

Section 2

Use CMVP and CAVP evidence for validation and procurement checks

The 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 module record and to any relevant algorithm validation evidence rather than relying on a vendor statement alone.

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.

Responsibility is divided. The vendor designs the module and supplies its documentation; the CST laboratory performs conformance testing and submits the report; reviews the submission and issues the validation; and the buyer or operator verifies the public entry, , module version, required services, and deployment conditions. A listing on the voluntary IUT list or the Modules in Process list shows progress, not a validation decision or completion date.

Capture the certificate number, module name, version, status, , and tested operational environment when those are available for the module under review.
Check 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.
The Historical list should not be used for a new procurement decision. Historical records may support an agency's documented continued-use risk decision; Revoked records may not demonstrate FIPS 140 conformity.
Record the date of the status check and the sunset date. A standard FIPS 140-3 validation is normally Active for five years; an Interim Validation has a two-year sunset, and transitions or dependent-module status can shorten the period.

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.

FIPS 140-3 CMVP Management Manual, April 9, 2026

Defines vendor, CST laboratory, CMVP, and user responsibilities; public process lists; Interim Validation; and Historical and Revoked status.

Recommended next step

Operationalize FIPS 140-3 compliance

This FIPS 140-3 guide helps 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 , 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: 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: , 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. Check the public record for the module's current status and read the linked ; a certificate number without its version, status, caveats, and tested configurations is incomplete evidence.

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.

A permitted port can instead use or user affirmation under the Management Manual. That is not the same as adding a tested environment to the certificate: makes no statement about correct operation or generated-key strength in an environment not listed on the certificate. Record the affirmation basis and, for vendor affirmation, the warning instead of calling the environment tested.

Ask whether the claim is for a validated , an algorithm implementation, a product containing a module, or an internal configuration using a module.
Confirm the certificate number, module version, , 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.
Ask whether an unlisted environment is covered by vendor or user affirmation, and obtain the porting rationale and required statement.
Escalate gaps when the supplier cannot connect the public claim to certificate scope, tested or affirmed environment, approved services, or current 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.

FIPS 140-3 CMVP Management Manual, section 7.9

Supports the distinction between certificate-listed tested environments and permitted vendor or user affirmation after porting.

Section 5

Checklist for FIPS 140-3 compliance review

Review 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 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 certificate, , validation record, and 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, which were only affirmed after porting, and does the intended deployment match the applicable conditions?
Verify status and time: when was the public record checked, what is the sunset date, and is the module Active, Historical, Interim, or Revoked?
Verify changes: what module, algorithm, supplier, firmware, operational-environment, vulnerability, dependency-status, 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

References and citations

CMVP Implementation Guidance for FIPS 140-3

csrc.nist.gov

Referenced sections

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

"fully tested"

FIPS 140-3 CMVP Management Manual, April 9, 2026

csrc.nist.gov

Referenced sections

Defines vendor, CST laboratory, CMVP, and user responsibilities; public process lists; Interim Validation; and Historical and Revoked status.

FIPS 140-3 CMVP Management Manual, section 7.9

csrc.nist.gov

Referenced sections

Supports the distinction between certificate-listed tested environments and permitted vendor or user affirmation after porting.

NIST CAVP validation search

csrc.nist.gov

Referenced sections

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

NIST CMVP program page

nist.gov

Referenced sections

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

"CMVP"

NIST FIPS 140-3 security requirements for cryptographic modules

doi.org

Referenced sections

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

"conformance to this standard is not sufficient"

NIST FIPS 140-3 standards and related references

csrc.nist.gov

Referenced sections

Explains the relationship among FIPS 140-3, ISO/IEC 19790, ISO/IEC 24759, the SP 800-140 series, the Implementation Guidance, and the Management Manual.

Related guides