We use privacy-by-default, cookieless analytics.

Optional analytics cookies are used only if you accept them.

Read our Terms of Use and Privacy Policy.

Artifact GuideGLOBALFIPS 140-3

FIPS 140-3 compliance guide

Turn FIPS 140-3 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 validation, Cryptographic and Security Testing (CST) laboratory testing, or operational guidance.

Back to main artifactReview sources
Author
Sorena AI
Published
May 9, 2026
Updated
Oct 15, 2026
5 sections8 primary sources
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.
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 Implementation Under Test (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.
  • For federal procurement, distinguish new systems from legacy systems. Current guidance says Historical modules should not be included in new systems but can be procured for legacy systems. Agencies may separately make a documented risk determination about continued use. Historical is not Revoked, and older certificate documentation may no longer reflect current guidance or approved-mode use; 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.
Recommended next step

Prepare FIPS 140-3 compliance evidence

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 deterministic random bit generator (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 Common Vulnerabilities and Exposures (CVE) handling notes, and reassessment triggers for module or environment changes.
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. For algorithm certificate reuse under IG 2.3.A, the integrated implementation must remain unmodified and its -tested environment must be identical to, or fully included in, the module test environment. Separately compare the deployed module configuration with its record and ; use the affirmation branch below for a permitted unlisted environment.

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.
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?
Primary sources

References and citations

CMVP Implementation Guidance for FIPS 140-3
csrc.nist.gov6 citations
Referenced sections
  • Program guidance for FIPS 140-3 validation evidence, approved services, algorithm certificates, operational environments, bound or embedded modules, entropy, self-tests, and change-sensitive claims.
  • Supports the need to distinguish module boundaries, approved services, operational environments, binding or embedding cases, and the evidence expected in CMVP submissions.
  • Supports certificate-level evidence requirements for algorithm implementations, module validations, operational environments, and bound or embedded module claims.
Show 3 more
  • Supports evidence expectations for approved service indicators, algorithm certificates, operational environments, entropy, self-tests, and module change analysis.
  • Grounds the warning about operational environment matching, bound or embedded module evidence, and certificate-scope checks.
  • Supports checklist items for certificate scope, approved services, operational environment matching, and change-sensitive validation evidence.
"programmatic guidance of the CMVP"
More quoted passages
"Security Policy and validation test report"
"certificate states the name and version number"
"approved service / algorithm"
"tested operational environment"
"fully tested"
NIST FIPS 140-3 security requirements for cryptographic modules
doi.org5 citations
Referenced sections
  • Primary source for FIPS 140-3 scope, federal applicability, four qualitative security levels, requirement areas, approved security functions, CMVP testing, and procurement cautions.
  • 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.
  • 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.
Show 2 more
  • 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.
  • Supports checklist items for security levels, approved functions, module requirement areas, and the limits of relying on conformance alone.
"four increasing, qualitative levels of security"
More quoted passages
"cryptographic module specification; cryptographic module interfaces"
"accredited Cryptographic and Security Testing"
"appropriate for the security requirements"
"conformance to this standard is not sufficient"
FIPS 140-3 CMVP Management Manual, April 9, 2026
csrc.nist.gov2 citations
Referenced sections
  • Current source for CMVP roles, public process status, Interim Validation, certificate status, revalidation, and vendor or user affirmation.
  • Defines vendor, CST laboratory, CMVP, and user responsibilities; public process lists; Interim Validation; and Historical and Revoked status.
NIST CAVP validation search
csrc.nist.gov2 citations
Referenced sections
  • Public NIST search entry point for checking cryptographic algorithm validation records referenced in FIPS 140-3 evidence reviews.
  • Public NIST search entry point for checking cryptographic algorithm validation records used in a FIPS 140-3 evidence pack.
NIST FIPS 140-3 standards and related references
csrc.nist.gov2 citations
Referenced sections
  • Official map of FIPS 140-3, ISO/IEC 19790 and 24759, the SP 800-140 series, and CMVP-controlled documents.
  • 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.
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 CMVP validated modules: Historical and Revoked status
csrc.nist.gov
Referenced sections
  • Current CMVP guidance distinguishes Historical modules in new systems from procurement for legacy systems and agency risk decisions on continued use; Historical certificates and documentation may not reflect current guidance.

Related guides

FIPS 140-3 algorithm certificate mapping: ACVTS certificates to module boundary

Map CAVP algorithm certificates to FIPS 140-3 module services, approved security functions, security policy tables, and validation evidence.

FIPS 140-3 Applicability Test

Check whether FIPS 140-3 applies to a cryptographic module claim by testing agency use, module boundary, security level, approved functions, CMVP status, and procurement evidence.

FIPS 140-3 Approved and Non-Approved Mode Workflow

Classify FIPS 140-3 module services by approved security service, allowed no-security-claimed use, and non-approved service evidence.

FIPS 140-3 approved-mode evidence workflow

Collect FIPS 140-3 approved-mode evidence for a specific module service: boundary, indicator, selected CAVP capabilities, Security Policy entry, and deployment configuration.

FIPS 140-3 Change Impact Review

Review FIPS 140-3 module changes against boundary, version, operational environment, embedded module, software loading, CVE, and certificate evidence.

FIPS 140-3 CMVP Lifecycle and Status Guide

Follow a FIPS 140-3 module from scoping and CST-laboratory testing through CMVP review, publication, Active status, revalidation, and procurement checks.

Show all related guides (28)

FIPS 140-3 Entropy and DRBG Evidence

FIPS 140-3 entropy and DRBG guidance for module boundary decisions, entropy caveats, Security Policy evidence, ESV references, and DRBG CSP handling.

FIPS 140-3 FAQ for Cryptographic Modules

Answers to common FIPS 140-3 questions about scope, CMVP validation, algorithm certificates, module boundaries, approved mode, and validation evidence.

FIPS 140-3 Module Boundary Selector Workflow

A FIPS 140-3 workflow for selecting a cryptographic module boundary, separating embedded and bound modules, and collecting CMVP validation evidence.

FIPS 140-3 Security Policy Template

Draft the vendor-authored parts of a FIPS 140-3 CMVP Security Policy and prepare the structured module information that CMVP merges into the final policy.

FIPS 140-3 Validation Checklist

Checklist for preparing a cryptographic module for FIPS 140-3 validation: boundary, levels, services, approved algorithms, entropy, tests, security policy, and change evidence.

FIPS 140-3 Validation Maintenance

Decide whether a changed FIPS 140-3 module still matches its validation or needs a CMVP revalidation scenario, evidence update, or paused claim.

FIPS 140-3 Validation Maintenance Change Workflow

Triage a changed FIPS 140-3 module against current CMVP revalidation scenarios, Security Policy evidence, CAVP testing, operational environments, and CVE handling.

FIPS 140-3 vs ISO/IEC 19790 and ISO/IEC 24759

Compare FIPS 140-3 with ISO/IEC 19790 and ISO/IEC 24759 for cryptographic module validation scope, evidence, testing, and procurement claims.

FIPS 140-3: FIPS 140-2 vs FIPS 140-3

Compare FIPS 140-2 legacy references with FIPS 140-3 requirements, ISO/IEC 19790 alignment, CMVP testing evidence, and guidance mappings.

FIPS 140-3: Module Boundary and Service Mapping

Map a FIPS 140-3 cryptographic module boundary to services, approved algorithms, operational environments, and CMVP validation evidence.

FIPS 140-3: Module Boundary Selector

Select and document a FIPS 140-3 cryptographic module boundary across hardware, software, firmware, operational environment, services, and validation evidence.

FIPS 140-3: Operational Environment

FIPS 140-3 operational environment guidance for software, firmware, hybrid, CAVP certificate, EVM, and PAA/PAI validation claims.

FIPS 140-3: Security Levels Explained

Compare FIPS 140-3 Security Levels 1 through 4 by requirement area and document a level claim without extending it beyond the validated module.

FIPS 140-3: step-by-step workflow for mapping algorithm certificates to CMVP modules

Map CAVP algorithm certificates to a FIPS 140-3 module by matching the tested implementation, operational environment, service use, and CMVP Security Policy record.

FIPS 140-3 Algorithm Certificates FAQ

How CAVP algorithm certificates support, but do not replace, FIPS 140-3 cryptographic module validation evidence.

FIPS 140-3 Certificate Maintenance FAQ

How to maintain FIPS 140-3 certificate evidence after validation by checking module status, version, caveats, Security Policy, and revalidation records.

FIPS 140-3 Entropy Evidence FAQ

How FIPS 140-3 entropy evidence should document entropy source location, GetEntropy access, SP 800-90B testing, Security Policy text, and certificate caveats.

FIPS 140-3 Module Boundaries FAQ

Understand how FIPS 140-3 module boundaries affect cryptographic module scope, interfaces, software and firmware components, and bound or embedded validated modules.

FIPS 140-3 operational environments FAQ

Learn what a FIPS 140-3 operational environment means for software, firmware, and hybrid cryptographic modules, and what evidence to check before relying on a validation claim.

FIPS 140-3 security levels: how to choose and evidence them

A practical FAQ on FIPS 140-3 security levels, module scope, CMVP evidence, bound or embedded modules, and common claim mistakes.

FIPS 140-3 Vendor Affirmation FAQ

When vendor affirmation can support a FIPS 140-3 module claim, what it does not supersede, and which Security Policy, CAVP, CSTL, and test-report evidence to keep.

How should teams handle approved mode under FIPS 140-3?

Answer the FIPS 140-3 approved-mode question with service-level indicators, Security Policy evidence, and limits on non-approved functions.