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.
1
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, sensitive security parameter (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.
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.
At security levels 3 and 4, the module is required to contain the logic to automatically perform
2
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 (including an Interim Validation), , or Revoked and read its caveats before accepting a supplier statement that uses only the phrase FIPS 140-3 compliant. Historical status does not mean revocation. FIPS 140-3 warns against using the Historical list for procurement decisions; the current page specifies that federal agencies should not include Historical modules in new systems but can procure them for legacy systems. Agencies may make a risk determination on continued use based on where and how the module is used; check the certificate caveats and applicable agency procurement rules.
Reassess the choice when the module boundary, embodiment, services, environment, authentication model, SSP paths, physical design, dependencies, or procurement threat model changes.
Defines Active, Historical, and Revoked status and explains that certificates are issued to cryptographic modules rather than automatically to the products that contain them.
Current CMVP guidance distinguishes Historical modules in new systems, procurement for legacy systems, and agency risk decisions on continued use.
3
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 .
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.
same or higher security level
4
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 .
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.
Explains CMVP expectations for bound and embedded module scenarios that can affect security-level claims.
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 1.A defines binding and embedding and sets the section-rating, status, tested-environment, and documentation conditions for reliance on an existing validated module.
"same or higher security level"
More quoted passages
"At security levels 3 and 4, the module is required to contain the logic to automatically perform"
Official explanations of product-versus-module scope and Active, Historical, and Revoked validation status.
Defines Active, Historical, and Revoked status and explains that certificates are issued to cryptographic modules rather than automatically to the products that contain them.
Explains product-versus-module scope and the practical meaning of Active, Historical, and Revoked validation status.