Artifact GuideGLOBALFIPS 140-3

FIPS 140-3 Security Levels Explained

What Levels 1, 2, 3, and 4 mean in FIPS 140-3 and what evidence should back a module-level claim.

Grounded in FIPS 140-3 and CMVP implementation guidance for cryptographic modules.

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 page when a product, procurement, or validation record needs to explain a FIPS 140-3 security level without overstating what the level proves. FIPS 140-3 defines four increasing qualitative levels for cryptographic modules and applies them across requirement areas such as 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.

Section 1

What FIPS 140-3 security levels mean

FIPS 140-3 does not use security levels as marketing tiers. The standard specifies four increasing qualitative levels, Level 1 through Level 4, for cryptographic modules used to protect sensitive information in federal systems and systems operated for federal agencies.

A level claim is meaningful only with the module boundary, the claimed validation scope, and the requirement areas that support it. FIPS 140-3 states that requirements for a particular level include both requirements specific to that level and requirements that apply to all modules regardless of level.

In practice, the levels build on each other like this: Level 1 establishes the basic cryptographic module requirements; Level 2 adds more control over the role, authentication, and physical protection story; Level 3 requires stronger physical security and stronger handling of sensitive security parameters; and Level 4 requires the highest level of physical security and the strongest protection against environmental and fault-based attacks.

Level 1: the baseline level for cryptographic modules; it still requires the module to satisfy the FIPS 140-3 requirements that apply to all levels.
Level 2: adds stronger evidence and controls around physical security and operator authentication than Level 1.
Level 3: adds stronger physical tamper resistance, stronger response to tampering, and stronger protection of sensitive security parameters than Level 2.
Level 4: adds the most robust physical protections and attack resistance, intended for the most demanding environments.
Do not describe a whole product as Level 2, Level 3, or Level 4 unless the referenced CMVP validation covers the cryptographic module and version in question.
Tie the level explanation to the module boundary, services, roles, operational environment, and security policy rather than to broad product claims.
Explain the use environment: FIPS 140-3 says the selected level should be appropriate for the application, environment, and security services the module provides.
Keep the level claim separate from adjacent procurement, agency, or customer requirements that may require a validated module.

Sources for this answer

NIST FIPS 140-3 security requirements for cryptographic modules

Defines the four qualitative security levels and the requirement areas used to evaluate cryptographic modules.

NIST Cryptographic Module Validation Program

Identifies CMVP as the program for validating cryptographic modules to FIPS 140-3.

Section 2

How to choose and document a level

Start with the actual cryptographic module, not the platform around it. The level decision should describe the boundary under validation, the environment where the module operates, and the cryptographic services the module provides.

Procurement and assurance teams should ask for the certificate or validation listing, the security policy, the module version, and any caveats before relying on a level claim. If those artifacts do not match the deployed module, the level statement is not enough.

Record the module name, version, type, and cryptographic boundary that the level statement covers.
List the relevant requirement areas: specification, interfaces, roles and authentication, software or firmware, operating environment, physical security, non-invasive security, SSP management, self-tests, life-cycle assurance, and mitigation of other attacks.
State whether the level is a target for an in-progress validation or a completed CMVP validation already listed for that module.
Check certificate status and caveats before accepting a supplier statement that uses only the phrase FIPS 140-3 compliant.

Sources for this answer

NIST FIPS 140-3 security requirements for cryptographic modules

Supports choosing the level based on application, environment, and cryptographic services.

NIST Cryptographic Module Validation Program

Supports using CMVP validation status and module listings rather than unsupported supplier shorthand.

Section 3

Bound and embedded module level checks

Security-level explanations become more fragile when one module relies on another validated module. CMVP implementation guidance distinguishes binding and embedding scenarios and uses the implementation under test and existing validated module to explain how level claims interact.

For bound modules, the existing validated module is expected to be the same or a higher security level as the implementation under test for all FIPS 140-3 sections except mitigation of other attacks. For embedded modules, the existing validated module can be lower only when the lab or vendor demonstrates that the higher-level requirements are still met by the existing module or by the implementation under test on its behalf.

Identify whether the design is standalone, bound to another validated module, or embedding an existing validated module.
For a bound design, compare the relied-on module level with the implementation-under-test level by FIPS 140-3 section.
For an embedded design, keep the lab or vendor demonstration showing how the higher-level requirement is met.
Track historical status risk when a relied-on existing validated module changes status, is sunset, or is affected by an algorithm transition.

Sources for this answer

CMVP Implementation Guidance for FIPS 140-3

Provides the bound and embedded module rules used to verify whether a relied-on module can support the claimed level.

Section 4

Evidence to keep with a level claim

Keep evidence that lets a reviewer connect the level statement to the validated module and the deployed design. The evidence should be precise enough to distinguish a completed CMVP validation from an engineering target or procurement requirement.

CMVP certificate or validation listing for the module, including module name, version, validation number, status, and caveats.
Security policy that describes the module boundary, roles, services, approved mode behavior, and level-related claims.
Module boundary diagram and operating-environment record for software, firmware, hardware, or hybrid modules.
Section-by-section rationale for the claimed level, especially where physical security, non-invasive security, roles and authentication, or operational environment drives the selected level.
Bound or embedded module evidence when the implementation under test relies on another validated module.

Sources for this answer

NIST FIPS 140-3 security requirements for cryptographic modules

Supports evidence tied to the module boundary, security services, and covered FIPS 140-3 requirement areas.

NIST Cryptographic Module Validation Program

Supports keeping validation records tied to the CMVP module validation process.

Recommended next step

Operationalize FIPS 140-3 security levels

Use this guide to connect level statements to module boundaries, CMVP validation records, security policies, and deployment evidence.

Assessment workflow

Open Assessment Autopilot for FIPS 140-3

Convert security-level claims into accountable tasks, certificate checks, and evidence requests.

Explore next step

Research workflow

Research FIPS 140-3 source questions

Use cited source material to resolve module scope, validation status, and level-claim questions before implementation.

Explore next step

Talk to Sorena

Talk through FIPS 140-3 security levels

Review scope, evidence, owners, and the next compliance actions with Sorena.

Explore next step

Section 5

Claims to avoid

Most weak level explanations fail because they replace validation scope with shorthand. A level number should not be used as a promise that every part of a product, platform, cloud service, or supplier environment has the same assurance.

Avoid saying a product is FIPS 140-3 Level 3 when only one cryptographic module inside the product is validated.
Avoid treating a higher level as automatically better for every deployment; FIPS 140-3 links level selection to the application, environment, and security services.
Avoid mixing algorithm validation with module validation; a validated algorithm alone does not establish a FIPS 140-3 module level.
Avoid relying on historical-list entries for procurement decisions without checking current CMVP status and customer requirements.

Sources for this answer

NIST FIPS 140-3 security requirements for cryptographic modules

Supports limiting security-level claims to the selected module, application, environment, and security services.

NIST Cryptographic Module Validation Program

Supports checking module validation status rather than relying on unscoped FIPS shorthand.

Primary sources