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.

Based on FIPS 140-3 and CMVP implementation guidance for cryptographic modules.

Back to main artifact Review sources

Author

Sorena AI

Published

May 9, 2026

Updated

Jul 24, 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 Jul 24, 2026

Overview

A FIPS 140-3 describes a cryptographic module, not every feature or deployment of the product that contains it. Levels 1 through 4 increase assurance through section-specific requirements for interfaces, roles and authentication, software and firmware security, the operating environment, physical security, non-invasive security, sensitive security parameter management, self-tests, life-cycle assurance, and mitigation of other attacks. Use the module's live record and Security Policy to state the overall and section ratings, boundary, version, environments, services, caveats, status, and sunset date.

Section 1

What FIPS 140-3 security levels mean

FIPS 140-3 is the U.S. federal standard that adopts ISO/IEC 19790:2012 requirements, with modifications and documentation rules in the SP 800-140 series. It applies to cryptographic modules that U.S. federal departments and agencies operate or that contractors operate for them. Private organizations may adopt it, and contracts or procurement policies may require a validated module even when the standard does not directly bind the supplier.

A level claim is meaningful only with the module boundary, version, tested operational environment, claimed services, and validation status. Requirements for a particular level include the requirements specific to that level and requirements that apply to every module. The public record and Security Policy show what was validated; a design target, CAVP algorithm certificate, or laboratory submission is not a completed module validation.

The level number is not a whole-product security grade. A validation can have an overall security rating and different section ratings, so the practical change from one level to the next depends on the requirement area. Authentication, trusted-channel use, sensitive-security-parameter entry and output, physical protections, error logging, and periodic self-testing do not all change in the same way.

Read the levels as engineering and evidence consequences, not product tiers. A software library targeting Level 1 still needs the applicable module specification, approved functions, SSP management, self-tests, and life-cycle evidence. A module targeting Level 2, 3, or 4 must add the higher requirements in each claimed section; physical-security evidence depends on the hardware embodiment, while roles, authentication, interfaces, operating environment, and self-tests have separate rules.

Level 1 is the baseline, but it still requires every generally applicable requirement and every Level 1 requirement. It does not mean 'encryption only' or 'no assurance.' The roles-and-authentication section does not require operator authentication at Level 1; Level 2 introduces the minimum of role-based authentication.
Level 2 adds requirements by section. For example, the roles-and-authentication section requires at least role-based authentication, which authenticates permission to assume a role without necessarily identifying the individual operator. Do not summarize Level 2 only as tamper evidence: physical requirements depend on the module embodiment, and other sections have their own criteria.
Level 3 requires identity-based authentication in the roles-and-authentication section. It also requires a trusted channel when unprotected plaintext critical security parameters, key components, or authentication data cross the module interface, protected entry or output of those values, an operator-accessible self-test error log, and automatic periodic self-test logic, subject to the detailed conditions and permitted implementations in guidance.
Level 4 requires multi-factor identity-based authentication in the roles-and-authentication section and adds multi-factor separate identity-based authentication when plaintext secret or private key components are entered or output under split knowledge. It is the highest qualitative level, but the applicable evidence still depends on the requirement section, module type, implementation guidance, and tested design.
Do not describe a whole product as Level 2, Level 3, or Level 4 unless the product and the validated cryptographic module are the same defined object.
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.

CMVP Implementation Guidance for FIPS 140-3

Sections 3.4.A, 4.4.A, 9.5.A, 10.3.D, and 10.3.E support the section-specific examples for trusted channels, authentication, SSP entry and output, error logs, and periodic self-tests.

Section 2

How to choose and document a level

Start with the actual cryptographic module, not the platform around it. For a planned validation, select target ratings that match the application's risks, operating environment, required services, module embodiment, and procurement criteria, then confirm feasibility with an accredited CST laboratory. For an existing module, copy ratings from the record instead of choosing or inferring them.

Procurement and assurance teams should obtain the public validation entry and Security Policy, then compare the module name, version, certificate number, status, caveats, tested environments, and approved services with the deployed configuration. If those facts do not match, the level number does not establish that the deployment uses the validated module as tested.

Assign the work explicitly. The system owner states the threat and procurement need; the vendor defines the boundary and target section ratings; the CST laboratory tests every applicable requirement for the claimed levels; issues the validation; and the buyer or operator verifies that the deployed module and required services match the public record.

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.
Record the overall rating and each section rating exactly as shown in the validation evidence; do not infer that every section has the same level from the overall label.
State whether each level is only an engineering target, a laboratory-tested submission claim, or a completed validation already listed for that module.
Check whether the record is Active, , Interim, or Revoked and read its caveats before accepting a supplier statement that uses only the phrase FIPS 140-3 compliant. A Historical record is not the same as a Revoked validation, but NIST warns against using the Historical list for procurement decisions.
Reassess the choice when the module boundary, embodiment, services, environment, authentication model, SSP paths, physical design, dependencies, or procurement threat model changes.

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 CMVP FAQs

Defines Active, Historical, and Revoked status and explains that certificates are issued to cryptographic modules rather than automatically to the products that contain them.

FIPS 140-3 CMVP Management Manual, April 9, 2026

Defines participant responsibilities, Interim Validation, and the current administrative meaning of validation status.

Section 3

Bound and embedded module level checks

A module may rely on another validated module by binding or embedding. In guidance, an embedded validated module is wholly inside the implementation under test's boundary and provides services only to it. A bound module has a separate boundary; the implementation under test depends on it, and application services can be available from either module.

For binding, the existing validated module must have the same or a higher section rating as the implementation under test for every FIPS 140-3 section except mitigation of other attacks. For embedding, the existing module may have a lower section rating only if the vendor and laboratory show that it already meets the higher requirement or that the implementation under test meets the requirement on its behalf. A FIPS 140-3 implementation under test cannot bind to or embed a FIPS 140-2 validated module.

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 dependency status. The implementation under test inherits status if the existing validated module moves to the Historical list, and the existing module must be Active when the implementation under test is submitted to .

Sources for this answer

CMVP Implementation Guidance for FIPS 140-3

Section 1.A defines binding and embedding and sets the section-rating, status, tested-environment, and documentation conditions for reliance on an existing validated module.

Section 4

Evidence to keep with a level claim

Keep enough evidence to connect the level statement to both the public record and the deployed design. The record should let a reviewer distinguish a completed validation from a design target, a module in testing, or a procurement requirement.

certificate or validation listing for the module, including module name, version, validation number, status, and caveats.
Non-proprietary Security Policy that describes the module boundary, roles, services, approved-mode behavior, SSPs, self-tests, operational environments, and level-related claims.
Module boundary diagram and operating-environment record for software, firmware, hardware, or hybrid modules.
Section-by-section rating and rationale, especially where physical security, non-invasive security, roles and authentication, sensitive-security-parameter handling, self-tests, or operational environment differs from the overall shorthand.
Bound or embedded module evidence when the implementation under test relies on another validated module.
Status evidence showing the review date, Active or Interim period, sunset date, dependencies, caveats, and any transition that could move the validation to .

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

Verify FIPS 140-3 security-level claims

This guide helps 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

A level number cannot replace validation scope. It does not promise that every part of a product, platform, cloud service, or supplier environment has the same assurance, or that the product invokes the module correctly in every configuration.

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 -list entries for procurement decisions. If an agency is considering continued use of an already deployed Historical module, document the agency's risk decision and confirm how the module is used; a Revoked validation may not be cited to demonstrate FIPS 140 conformity.

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 CMVP FAQs

Explains product-versus-module scope and the practical meaning of Active, Historical, and Revoked validation status.

Primary sources

References and citations

CMVP Implementation Guidance for FIPS 140-3

csrc.nist.gov

Referenced sections

Section 1.A defines binding and embedding and sets the section-rating, status, tested-environment, and documentation conditions for reliance on an existing validated module.