Artifact GuideGLOBALFIPS 140-3

FIPS 140-3 Approved-mode evidence workflow

A practical workflow for proving which cryptographic-module services are approved, how the module signals approved security services, and what certificate evidence supports the claim.

Grounded in FIPS 140-3, CMVP implementation guidance, and CAVP validation sources. Use it for evidence planning, not as a validation guarantee.

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

Use this workflow when a product, procurement review, assessor question, or customer security questionnaire asks how a FIPS 140-3 module operates in approved mode. The evidence should show the module boundary, the service being invoked, the indicator visible to the operator or calling application, and the algorithm or component certificate evidence behind the approved security service.

Section 1

Start with the module boundary and service inventory

FIPS 140-3 applies to cryptographic modules, not to every surrounding product feature. Start the evidence file with the validated or candidate module name and version, its cryptographic boundary, its operational environment, and the services exposed to operators, applications, or another module.

For approved-mode evidence, the service inventory is the control surface. CMVP guidance treats a service as an externally operator-invoked operation or function and explains that services may be documented differently from individual API calls. A single API can provide different services depending on parameters, and a service can invoke multiple API functions.

Record the module name, version, security level claim, cryptographic boundary, and operational environment before describing any approved-mode behavior.
List externally invoked services in service language: encryption, signature generation, random bit generation, key establishment, status output, self-test invocation, or zeroization service.
Separate approved security services from non-security services and from services that use non-approved functions without claiming security.
Do not use an algorithm certificate alone as evidence that the full module, product, or service is validated.

Sources for this answer

NIST FIPS 140-3 security requirements for cryptographic modules

Supports the page scope: FIPS 140-3 specifies cryptographic-module requirements, security levels, requirement areas, CMVP validation, and federal-agency use.

CMVP Implementation Guidance for FIPS 140-3

Supports service-inventory work by explaining approved-mode operation, approved and non-approved services, service indicators, CAVP certificates, and Security Policy expectations.

Section 2

Classify each service before calling it approved

Approved mode is not a broad marketing label. CMVP guidance defines approved mode as a set of services that includes at least one service using an approved security function or process, while excluding non-approved security functions or processes.

Classify each service into one of four evidence buckets: approved security service, non-security service allowed to run in approved mode, service using a non-approved algorithm with no security claimed, or service that is not available in approved mode. This classification prevents a customer-facing claim from implying that every callable cryptographic operation is approved.

For approved security services, tie the service to the approved algorithm, security function, process, certificate entry, and approved-use conditions.
For non-security services such as status or version output, document why they do not need the same service indicator unless they are part of another approved security service.
For non-approved algorithms used with no security claimed, record the Security Policy treatment and why processed data can be treated as plaintext for FIPS 140-3 purposes.
For disallowed services, make the operator guidance and configuration controls clear enough that they cannot be mistaken for approved-mode services.

Sources for this answer

CMVP Implementation Guidance for FIPS 140-3

Supports the approved-mode classification because IG 2.4.A defines approved mode and explains when non-approved algorithms may or may not appear in approved mode.

Section 3

Prove the approved security service indicator

FIPS 140-3 evidence should show how the operator, calling application, or another module can tell whether an approved security service is in use. CMVP guidance says the indicator can be externally accessible through the module status interface and does not have to be physical or human-readable only.

The Security Policy can explain how to interpret an indicator, but the description alone is not the indicator. The evidence should include the module behavior: return code, status output, log value, API result, configuration state, or other externally accessible signal that can be tested.

For each approved security service, capture the exact indicator value or condition and the interface where it is visible.
If the module uses a global approved-mode indicator, verify that it unambiguously identifies the approved security service actually in use.
If approved and non-approved services can run concurrently, collect per-service or per-thread evidence instead of relying on a broad module-level statement.
Keep test evidence showing that the service indicator changes or remains unambiguous across relevant parameter choices, configuration states, and error paths.

Sources for this answer

CMVP Implementation Guidance for FIPS 140-3

Supports the indicator evidence requirements from IG 2.4.C, including vendor documentation, tester verification, operator visibility, and Security Policy interpretation limits.

Section 4

Match algorithm evidence to the module and environment

CAVP certificates are evidence inputs, not substitutes for module validation. CMVP guidance states that algorithm validation certificates identify the algorithm implementation and tested operational environment, while module validation certificates identify the cryptographic module and its tested operational environment.

For software, firmware, or hardware modules using embedded algorithm implementations, the evidence should show that the implementation was not modified during integration and that the CAVP-tested operational environment is identical to, or fully included in, the environment tested by the CST laboratory.

Record CAVP certificate numbers, algorithm names, implementation versions, modes, revisions, and any component-validation restrictions.
Map each certificate to the exact approved security service that uses it; avoid free-floating certificate screenshots.
Check operational environment fields such as operating system, platform, processor, and hypervisor where applicable.
When using CVL entries, preserve the usage restriction in operator guidance and the Security Policy evidence.

Sources for this answer

CMVP Implementation Guidance for FIPS 140-3

Supports certificate matching by describing CAVP certificates, module certificates, operational-environment matching, and component validation list restrictions.

NIST CAVP validation search

External public search source for verifying CAVP certificate entries used as evidence for algorithm or component claims.

Recommended next step

Operationalize FIPS 140-3 approved-mode evidence

Use the workflow to align services, indicators, certificate entries, and Security Policy evidence before a procurement, audit, or validation discussion.

Assessment workflow

Open Assessment Autopilot for FIPS 140-3

Convert approved-mode service evidence into accountable review tasks and evidence requests.

Explore next step

Research workflow

Research FIPS 140-3 source questions

Use cited NIST and CMVP material to resolve service, indicator, certificate, and scope questions before implementation.

Explore next step

Talk to Sorena

Talk through implementation

Review module scope, approved security service indicators, certificate evidence, and change triggers with Sorena.

Explore next step

Section 5

Approved-mode evidence table

Use this table structure in the evidence pack. It keeps the FIPS 140-3 claim tied to a service, an indicator, and a cited certificate or Security Policy entry.

Service | Classification | Indicator evidence | Certificate or policy evidence | Reviewer check

Encrypt customer data | Approved security service | Return code or status output showing approved use for the selected algorithm, key length, and mode | CAVP certificate entry plus module Security Policy service row | Does the indicator distinguish approved and non-approved parameter choices?

Show module status | Non-security service allowed in approved mode | Status interface output, if used by another approved service | Security Policy service list | Is the service being used only as status output, not as a security claim?

Use proprietary obfuscation for internal storage | Non-approved algorithm with no security claimed | Operator guidance showing data is treated as plaintext for FIPS purposes | Security Policy list of non-approved algorithms allowed in approved mode with no security claimed | Does the service avoid sharing keys or CSPs in a prohibited way?

Legacy or unsupported cryptographic service | Not available in approved mode | Disabled configuration, rejected call, or non-approved indicator | Security Policy and test evidence | Can an operator confuse this service with an approved security service?

Review every row against the shipped module version and operational environment; stale service evidence is not reusable after material changes.
Keep screenshots, logs, API traces, and Security Policy excerpts close to the service row they support.
Write the reviewer check as a question that can be answered from the evidence, not from institutional memory.

Sources for this answer

CMVP Implementation Guidance for FIPS 140-3

Supports the evidence table categories by distinguishing approved security services, non-security services, non-approved algorithms with no security claimed, and services unavailable in approved mode.

Section 6

Change triggers for approved-mode evidence

Approved-mode evidence should be refreshed when a change can affect the module boundary, service classification, indicator behavior, algorithm implementation, operational environment, or Security Policy statements. The workflow is not a promise that a change is validation-neutral; it is a triage record for deciding what needs laboratory, CMVP, procurement, or customer review.

Treat binding or embedding another validated module as a separate evidence branch. CMVP guidance requires precise identification of an embedded or bound module by name, certificate number, and version, and it requires clear separation between the implementation under test and the externally validated module.

Recheck evidence after changes to API parameters, service availability, configuration defaults, firmware or software version, operational environment, processor acceleration, entropy source, key establishment method, or certificate dependency.
For embedded or bound modules, record the other module's certificate number, version, operating mode, services used, algorithms used, SSP handling, self-tests, and zeroization separation.
Do not claim an embedded module's service or algorithm as approved unless it is approved at the time of the implementation-under-test submission and is actually used within the documented scope.
Escalate unclear changes to the validation path instead of preserving old approved-mode language in public or procurement materials.

Sources for this answer

CMVP Implementation Guidance for FIPS 140-3

Supports change-trigger guidance for embedded or bound validated modules, certificate/version identification, and separation of IUT and EVM evidence.

Primary sources

References and citations

CMVP Implementation Guidance for FIPS 140-3

csrc.nist.gov

Referenced sections

Supports change-trigger guidance for embedded or bound validated modules, certificate/version identification, and separation of IUT and EVM evidence.

"precisely identify the EVM"

NIST CAVP validation search

csrc.nist.gov

Referenced sections

External public search source for verifying CAVP certificate entries used as evidence for algorithm or component claims.

"Cryptographic Algorithm Validation Program"

NIST FIPS 140-3 security requirements for cryptographic modules

doi.org

Referenced sections

Supports the page scope: FIPS 140-3 specifies cryptographic-module requirements, security levels, requirement areas, CMVP validation, and federal-agency use.