---
title: "FIPS 140-3 security levels: how to choose and evidence them"
canonical_url: "https://www.sorena.io/artifacts/global/fips-140-3/faq/security-levels"
source_url: "https://www.sorena.io/artifacts/global/fips-140-3/faq/security-levels"
author: "Sorena AI"
description: "A practical FAQ on FIPS 140-3 security levels, module scope, CMVP evidence, bound or embedded modules, and common claim mistakes."
published_at: "2026-05-09"
updated_at: "2026-05-27"
keywords:
  - "FIPS 140-3 security levels"
  - "CMVP validation"
  - "cryptographic module"
  - "security policy"
  - "FIPS 140-3 FAQ"
  - "FIPS 140-3"
  - "CMVP"
  - "cryptographic module validation"
  - "FAQ"
---
**[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)

---

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

*Artifact FAQ* *GLOBAL* *FIPS 140-3*

## FIPS 140-3 How to handle security levels

Use FIPS 140-3 security levels as cryptographic-module validation claims tied to a module boundary, operating environment, CMVP certificate, and security policy.

This FAQ explains how to scope, choose, evidence, and avoid overstating FIPS 140-3 security-level claims.

FIPS 140-3 security levels are not a generic maturity score for a product or cloud service. They are validation claims for a cryptographic module, chosen for the application, operating environment, and security services the module provides, then evidenced through CMVP validation material.

## What do FIPS 140-3 security levels mean?

FIPS 140-3 defines four increasing qualitative security levels, Level 1 through Level 4, for cryptographic modules. The standard applies the levels across requirement areas such as module specification, interfaces, roles and authentication, software and firmware security, operating environment, physical security, non-invasive security, sensitive security parameter management, self-tests, life-cycle assurance, and mitigation of other attacks.

A security-level statement should therefore identify the cryptographic module and the requirement areas or certificate evidence behind the statement. It should not be written as a broad claim that an entire product, platform, tenant, or organization is "FIPS Level 3" unless the public CMVP evidence supports exactly that scope.

- Name the cryptographic module, version, boundary, and operating environment before using a level claim.
- Tie the selected level to the application, deployment environment, and cryptographic services the module will provide.
- Separate module validation evidence from wider system risk decisions; FIPS 140-3 conformance alone does not prove that the whole system is secure.

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) - Defines FIPS 140-3 as a cryptographic-module standard with four qualitative security levels and named 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) - Explains CMVP guidance, validation evidence, and how implementation details are clarified for FIPS 140-3 submissions.

## How should a team choose a FIPS 140-3 security level?

Start from the module's intended use, not from a desired marketing label. FIPS 140-3 says the security level must be appropriate for the application and environment in which the module will be used and for the security services it will provide.

For procurement or architecture work, record the use case, exposed environment, cryptographic services, selected module, expected security level, and whether the module is already listed by CMVP for that scope. If the answer depends on a supplier certificate, verify the certificate status and security policy before repeating the level in customer-facing material.

- Choose the level against the actual cryptographic module, not an adjacent application feature.
- Confirm whether the required evidence is a CMVP module validation, an algorithm certificate, a security policy entry, or a supplier statement that still needs validation support.
- For federal procurement language, avoid relying on the CMVP Historical list as the proof point for current procurement decisions.

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) - States that the validated security level is selected for the application, environment, and security services of the module.
- [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) - Distinguishes CMVP module validation from CAVP algorithm validation and identifies certificate and operating-environment evidence.

## What evidence should support a security-level claim?

A strong evidence packet links the claim to the CMVP certificate, the module security policy, module version, tested operating environment, cryptographic boundary, approved services, and any CAVP algorithm certificates used by the module. The evidence should also show whether the module is active for the intended procurement or use case.

If the implementation depends on another validated module, document whether the relationship is bound or embedded. CMVP guidance treats those cases differently: a bound existing validated module must be at the same or higher security level as the module under test for all FIPS 140-3 sections except mitigation of other attacks, while an embedded module may be lower only when the submission demonstrates that the higher-level requirements are still met.

- Keep the public certificate number, module name, module version, tested operating environment, and security policy together.
- For bound or embedded modules, identify the existing validated module by name, certificate number, version, and the functions actually used.
- Do not treat a CAVP algorithm certificate as proof that the containing cryptographic module has a FIPS 140-3 security level.

Sources for this answer:

- [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) - Gives evidence expectations for bound and embedded modules, including certificate, version, boundary, and security-level relationships.
- [NIST CAVP validation search](https://csrc.nist.gov/projects/cryptographic-algorithm-validation-program/validation-search?ref=sorena.io) - Official NIST search entry point for checking cryptographic algorithm validation certificates used as supporting evidence.

## What mistakes should teams avoid?

The most common mistake is changing the scope of the claim: a validated cryptographic module becomes a validated product, a product becomes a validated service, or an algorithm certificate becomes a module certificate. FIPS 140-3 evidence should keep those layers separate.

Another mistake is copying a supplier's security-level language without checking the exact certificate, module version, operational environment, and validation status. If those details do not match the deployed module, the public claim can be materially misleading even when the supplier has a real validation elsewhere.

- Do not use Level 2, Level 3, or Level 4 language unless the CMVP evidence supports that level for the exact module scope.
- Do not combine multiple module certificates into one product-level security-level claim without explaining each boundary.
- Do not ignore certificate status changes, algorithm transitions, module updates, or operating-environment changes when reusing older evidence.

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) - Warns that conformance to the standard is not by itself enough to prove the security of a particular module or system.
- [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 review triggers around bound or embedded modules, validation status, certificate status, and operating-environment evidence.

## 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 for FIPS 140-3 scope, security levels, application and environment selection criteria, approved security functions, CMVP validation context, and system-security qualifications.
  - Quote: "four increasing, qualitative levels of security"
- [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) - Official CMVP implementation guidance for module validation evidence, CAVP relationship, certificate details, bound and embedded modules, and validation-status handling.
  - Quote: "test for a cryptographic module's conformance"
- [NIST CAVP validation search](https://csrc.nist.gov/projects/cryptographic-algorithm-validation-program/validation-search?ref=sorena.io) - Official NIST validation-search entry point for algorithm certificate checks that may support, but do not replace, a FIPS 140-3 module validation claim.
  - 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 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.
- [How should teams handle approved mode under FIPS 140-3?](/artifacts/global/fips-140-3/faq/approved-mode.md): Answer the FIPS 140-3 approved-mode question with service-level indicators, Security Policy evidence, and limits on non-approved functions.

*Recommended next step*

*Placement: after practical guidance*

## Operationalize FIPS 140-3 security-level evidence

Use this FAQ to connect module scope, certificate status, security policy details, supplier evidence, and customer-facing wording before publishing or reusing a FIPS 140-3 security-level claim.

- [Review the module evidence](/solutions/assessment.md): Map certificate details, module boundaries, operating environments, and security-policy claims into accountable evidence tasks.
- [Check a scoped claim](/solutions/research-copilot.md): Use cited research support when a supplier, product, or procurement claim depends on a specific FIPS 140-3 security level.
- [Talk through implementation](/contact.md): Review security-level scope, evidence gaps, and public wording before publishing or submitting claims.


---

[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/security-levels