Artifact GuideGLOBALFIPS 140-3

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

A direct answer on approved mode, approved security services, service indicators, and Security Policy evidence under FIPS 140-3.

Grounded in NIST FIPS 140-3 and CMVP Implementation Guidance. Use it to scope evidence, not to claim validation.

Back to main artifact Review sources

Author

Sorena AI

Published

May 9, 2026

Updated

May 27, 2026

Questions

Structured answer sets in this page tree.

Primary sources

Cited legal and guidance references.

Publication metadata

Sorena AI

Published May 9, 2026

Updated May 27, 2026

Overview

Short answer: do not treat approved mode as a general compliance label. Under FIPS 140-3, the useful question is whether each claimed approved security service uses approved security functions in an approved manner, gives the operator an unambiguous indicator, and is described correctly in the module Security Policy.

Search this module

Find a question or answer quickly

3 of 3 questions

Question 1

Handle approved-mode claims at the service level

Start with the validated cryptographic module, not the product or platform around it. FIPS 140-3 specifies requirements for cryptographic modules, and CMVP guidance treats approved-mode analysis at the level of module services, security functions, indicators, and Security Policy descriptions.

For a customer, procurement, or audit answer, identify the specific module certificate and version, the service being called, the approved algorithm or process used by that service, and the operator-visible indicator that shows the service is approved. A broad statement that a product is "in FIPS mode" is not enough when the module can expose approved and non-approved services or use context-sensitive algorithms.

Map the claim to the validated cryptographic module boundary and the service table in the module Security Policy.
Classify each callable service as an approved security service, a non-security service allowed in approved mode, a non-approved algorithm with no security claimed, or a service not available in approved mode.
Use the module's service indicator, return code, status output, log message, or other externally accessible signal only if it lets the operator unambiguously determine when an approved security service is in use.

Citations

NIST FIPS 140-3 security requirements for cryptographic modules

Grounds the page scope: FIPS 140-3 applies to cryptographic modules and lists roles, services, authentication, self-tests, lifecycle assurance, and other module security requirement areas.

CMVP Implementation Guidance for FIPS 140-3

Grounds the distinction between approved mode, approved security services, service indicators, and services that are not available for approved-mode use.

Question 2

What evidence supports an approved-mode answer?

The strongest evidence is the set of records that let a reader trace the answer from a module certificate and Security Policy to the exact service behavior. The CMVP guidance says the Security Policy must list approved and non-approved services with details and applicable indicators; the Security Policy can explain the indicators, but its text alone does not satisfy the indicator requirement.

Evidence should also show the treatment of non-approved algorithms. CMVP guidance allows some non-approved algorithms in approved mode only when no security is claimed and the use is documented in the Security Policy; non-approved security functions must not be used in approved mode.

Module certificate number, module name, version, operational environment, and security level claims for the validated configuration.
Security Policy service table showing approved and non-approved services, approved security service indicators, and any operator guidance needed to use a service in an approved manner.
Algorithm validation evidence for the approved security functions used by the claimed service, plus records showing required self-tests and approved parameters where applicable.
Configuration or runtime evidence showing that disallowed services are unavailable in approved mode and that non-approved algorithms with no security claimed are not presented as security functions.

Citations

NIST FIPS 140-3 security requirements for cryptographic modules

Supports the need to keep approved-mode evidence tied to the cryptographic module and its required security areas rather than to a whole product label.

CMVP Implementation Guidance for FIPS 140-3

Supports the Security Policy evidence requirements for service lists, indicators, and non-approved algorithms allowed in approved mode with no security claimed.

NIST CAVP validation search

Public NIST search page for algorithm validation entries that can support service-level evidence when a FIPS 140-3 approved security service relies on a tested algorithm implementation.

Recommended next step

Operationalize FIPS 140-3 approved-mode evidence

Use this answer to connect approved-mode claims to module certificates, Security Policy service tables, service indicators, and algorithm validation evidence.

Assessment workflow

Map services to evidence

Convert approved-mode questions into service tables, indicator checks, and certificate evidence requests.

Explore next step

Research workflow

Ask a scoped follow-up

Use cited research support when module boundary, service indicator, or Security Policy interpretation is unclear.

Explore next step

Talk to Sorena

Talk through implementation

Review the module certificate, service evidence, approved indicators, and claim wording with Sorena.

Explore next step

Question 3

What mistakes should teams avoid?

Most approved-mode mistakes come from treating the mode as a switch that validates every cryptographic operation. FIPS 140-3 and the CMVP guidance require a more precise answer: which module, which service, which approved security function, which indicator, and which Security Policy rule.

Do not use a global approved-mode indicator by itself when the module can run approved and non-approved security services concurrently or when not all approved services are configured for the mode.
Do not rely on Security Policy narrative alone as the service indicator; the indicator must be externally accessible from the module's status interface and verifiable by the operator.
Do not call a non-approved cryptographic algorithm an approved-mode security function just because it is present while the module is in approved mode.
Do not reuse evidence from another certificate, module version, operational environment, or service table unless the validated boundary and configuration match the claim.

Citations

NIST FIPS 140-3 security requirements for cryptographic modules

Supports keeping the approved-mode answer within the cryptographic module security requirements and validated configuration.

CMVP Implementation Guidance for FIPS 140-3

Supports the cautions on global indicators, Security Policy-only explanations, non-approved algorithms, and disallowed non-approved security functions.

Primary sources

References and citations

CMVP Implementation Guidance for FIPS 140-3

csrc.nist.gov

Referenced sections

Supports the cautions on global indicators, Security Policy-only explanations, non-approved algorithms, and disallowed non-approved security functions.

"does not fulfill the requirement"

NIST CAVP validation search

csrc.nist.gov

Referenced sections

Public NIST search page for algorithm validation entries that can support service-level evidence when a FIPS 140-3 approved security service relies on a tested algorithm implementation.