---
title: "How should teams handle approved mode under FIPS 140-3?"
canonical_url: "https://www.sorena.io/artifacts/global/fips-140-3/faq/approved-mode"
source_url: "https://www.sorena.io/artifacts/global/fips-140-3/faq/approved-mode"
author: "Sorena AI"
description: "Answer the FIPS 140-3 approved-mode question with service-level indicators, Security Policy evidence, and limits on non-approved functions."
published_at: "2026-05-09"
updated_at: "2026-05-27"
keywords:
  - "FIPS 140-3 approved mode"
  - "approved security service indicator"
  - "CMVP Implementation Guidance"
  - "FIPS 140-3 Security Policy"
  - "FIPS 140-3"
  - "Approved Mode"
---
**[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform

[Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io)

---

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

*Artifact Guide* *GLOBAL* *FIPS 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.

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.

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

Sources for this answer:

- [NIST FIPS 140-3 security requirements for cryptographic modules](https://doi.org/10.6028/NIST.FIPS.140-3?ref=sorena.io) - 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](https://csrc.nist.gov/csrc/media/Projects/cryptographic-module-validation-program/documents/FIPS%20140-3/FIPS%20140-3%20IG.pdf?ref=sorena.io) - Grounds the distinction between approved mode, approved security services, service indicators, and services that are not available for approved-mode use.

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

Sources for this answer:

- [NIST FIPS 140-3 security requirements for cryptographic modules](https://doi.org/10.6028/NIST.FIPS.140-3?ref=sorena.io) - 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](https://csrc.nist.gov/csrc/media/Projects/cryptographic-module-validation-program/documents/FIPS%20140-3/FIPS%20140-3%20IG.pdf?ref=sorena.io) - 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](https://csrc.nist.gov/projects/cryptographic-algorithm-validation-program/validation-search?ref=sorena.io) - 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.

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

Sources for this answer:

- [NIST FIPS 140-3 security requirements for cryptographic modules](https://doi.org/10.6028/NIST.FIPS.140-3?ref=sorena.io) - Supports keeping the approved-mode answer within the cryptographic module security requirements and validated configuration.
- [CMVP Implementation Guidance for FIPS 140-3](https://csrc.nist.gov/csrc/media/Projects/cryptographic-module-validation-program/documents/FIPS%20140-3/FIPS%20140-3%20IG.pdf?ref=sorena.io) - Supports the cautions on global indicators, Security Policy-only explanations, non-approved algorithms, and disallowed non-approved security functions.

## Primary sources

- [NIST FIPS 140-3 security requirements for cryptographic modules](https://doi.org/10.6028/NIST.FIPS.140-3?ref=sorena.io) - Primary standard grounding for keeping approved-mode content tied to cryptographic modules and their required security areas.
  - Quote: "security requirements for cryptographic modules"
- [CMVP Implementation Guidance for FIPS 140-3](https://csrc.nist.gov/csrc/media/Projects/cryptographic-module-validation-program/documents/FIPS%20140-3/FIPS%20140-3%20IG.pdf?ref=sorena.io) - Primary guidance for approved-mode service classification, approved security service indicators, Security Policy service lists, and non-approved algorithm treatment.
  - Quote: "approved security service indicator"
- [NIST CAVP validation search](https://csrc.nist.gov/projects/cryptographic-algorithm-validation-program/validation-search?ref=sorena.io) - Public search page for recording algorithm validation evidence when an approved security service depends on a tested algorithm implementation.
  - Quote: "validation-search"

## Topic Guides

- [FIPS 140-3 algorithm certificate mapping: ACVTS certificates to module boundary](/artifacts/global/fips-140-3/algorithm-certificate-mapping.md): Map CAVP algorithm certificates to FIPS 140-3 module services, approved security functions, security policy tables, and validation evidence.
- [FIPS 140-3 Algorithm Certificates FAQ](/artifacts/global/fips-140-3/faq/algorithm-certificates.md): How CAVP algorithm certificates support, but do not replace, FIPS 140-3 cryptographic module validation evidence.
- [FIPS 140-3 Applicability Test](/artifacts/global/fips-140-3/applicability-test.md): 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](/artifacts/global/fips-140-3/approved-and-non-approved-mode-workflow.md): 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](/artifacts/global/fips-140-3/approved-mode-evidence-workflow.md): A grounded workflow for collecting FIPS 140-3 approved-mode evidence: module boundary, approved services, service indicators, CAVP certificates, Security Policy entries, and change review.
- [FIPS 140-3 Certificate Maintenance FAQ](/artifacts/global/fips-140-3/faq/certificate-maintenance.md): How to maintain FIPS 140-3 certificate evidence after validation by checking module status, version, caveats, Security Policy, and revalidation records.
- [FIPS 140-3 Change Impact Review](/artifacts/global/fips-140-3/change-impact.md): Review FIPS 140-3 module changes against boundary, version, operational environment, embedded module, software loading, CVE, and certificate evidence.
- [FIPS 140-3 compliance guide](/artifacts/global/fips-140-3/compliance.md): A grounded FIPS 140-3 compliance guide for cryptographic module scope, security-level claims, CMVP validation evidence, and procurement review.
- [FIPS 140-3 Entropy and DRBG Evidence](/artifacts/global/fips-140-3/entropy-and-drbg.md): 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 Entropy Evidence FAQ](/artifacts/global/fips-140-3/faq/entropy-evidence.md): 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 FAQ for Cryptographic Modules](/artifacts/global/fips-140-3/faq.md): Answers to common FIPS 140-3 questions about scope, CMVP validation, algorithm certificates, module boundaries, approved mode, and validation evidence.
- [FIPS 140-3 Module Boundaries FAQ](/artifacts/global/fips-140-3/faq/module-boundaries.md): 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 Module Boundary Selector Workflow](/artifacts/global/fips-140-3/module-boundary-selector-workflow.md): A FIPS 140-3 workflow for selecting a cryptographic module boundary, separating embedded and bound modules, and collecting CMVP validation evidence.
- [FIPS 140-3 operational environments FAQ](/artifacts/global/fips-140-3/faq/operational-environments.md): 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](/artifacts/global/fips-140-3/faq/security-levels.md): A practical FAQ on FIPS 140-3 security levels, module scope, CMVP evidence, bound or embedded modules, and common claim mistakes.
- [FIPS 140-3 Security Policy Template](/artifacts/global/fips-140-3/security-policy-template.md): Build a FIPS 140-3 module Security Policy with sections for boundary, roles, services, approved algorithms, SSP handling, self-tests, and CMVP evidence.
- [FIPS 140-3 Validation Checklist](/artifacts/global/fips-140-3/fips-140-3-validation-checklist.md): 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](/artifacts/global/fips-140-3/validation-maintenance.md): Maintain FIPS 140-3 validation claims by checking module identity, certificate status, boundary changes, operational environments, and CAVP evidence.
- [FIPS 140-3 Validation Maintenance Change Workflow](/artifacts/global/fips-140-3/validation-maintenance-change-impact-workflow.md): A FIPS 140-3 workflow for triaging module changes against CMVP validation scope, Security Policy evidence, CAVP certificates, software loading, and CVE records.
- [FIPS 140-3 Vendor Affirmation FAQ](/artifacts/global/fips-140-3/faq/vendor-affirmation.md): 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.
- [FIPS 140-3 vs ISO/IEC 19790 and ISO/IEC 24759](/artifacts/global/fips-140-3/fips-140-3-vs-iso-19790.md): 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: CMVP Lifecycle Timeline](/artifacts/global/fips-140-3/cmvp-lifecycle-timeline.md): Practical FIPS 140-3 guidance for CMVP Lifecycle Timeline: scope, controls, evidence, source-linked decisions, and implementation checkpoints.
- [FIPS 140-3: FIPS 140-2 vs FIPS 140-3](/artifacts/global/fips-140-3/fips-140-2-vs-fips-140-3.md): 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](/artifacts/global/fips-140-3/module-boundary-and-service-mapping.md): Map a FIPS 140-3 cryptographic module boundary to services, approved algorithms, operational environments, and CMVP validation evidence.
- [FIPS 140-3: Module Boundary Selector](/artifacts/global/fips-140-3/module-boundary-selector.md): 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](/artifacts/global/fips-140-3/operational-environment.md): FIPS 140-3 operational environment guidance for software, firmware, hybrid, CAVP certificate, EVM, and PAA/PAI validation claims.
- [FIPS 140-3: Security Levels Explained](/artifacts/global/fips-140-3/security-levels-explained.md): Explain FIPS 140-3 Security Levels 1 through 4, what they cover, and how to document level claims for cryptographic module validation.
- [FIPS 140-3: step-by-step workflow for mapping algorithm certificates to CMVP modules](/artifacts/global/fips-140-3/algorithm-certificate-mapping-workflow.md): Map CAVP algorithm certificates to a FIPS 140-3 module by matching implementation identity, operational environment, module services, and security policy evidence.

*Recommended next step*

*Placement: after practical guidance*

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

- [Map services to evidence](/solutions/assessment.md): Convert approved-mode questions into service tables, indicator checks, and certificate evidence requests.
- [Ask a scoped follow-up](/solutions/research-copilot.md): Use cited research support when module boundary, service indicator, or Security Policy interpretation is unclear.
- [Talk through implementation](/contact.md): Review the module certificate, service evidence, approved indicators, and claim wording with Sorena.


---

[Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us)

(c) 2026 Sorena AB (559573-7338). All rights reserved.

Source: https://www.sorena.io/artifacts/global/fips-140-3/faq/approved-mode