---
title: "FIPS 140-3 Compliance (CMVP Validation Playbook, Approved Mode, Transition)"
canonical_url: "https://www.sorena.io/artifacts/global/fips-140-3/compliance"
source_url: "https://www.sorena.io/artifacts/global/fips-140-3/compliance"
author: "Sorena AI"
description: "A practical FIPS 140-3 compliance and validation playbook for CMVP cryptographic module validation: boundary, security level selection, approved mode."
published_at: "2026-03-04"
updated_at: "2026-03-04"
keywords:
  - "FIPS 140-3 compliance"
  - "FIPS 140-3 validation"
  - "CMVP validation playbook"
  - "cryptographic module validation program"
  - "NVLAP CSTL"
  - "FIPS 140-3 approved mode"
  - "FIPS 140-3 security policy"
  - "FIPS 140-3 evidence pack"
  - "FIPS 140-3 documentation requirements"
  - "FIPS 140-2 transition 2026"
  - "GLOBAL compliance"
  - "FIPS 140-3"
  - "CMVP"
  - "Cryptographic module validation"
---
**[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 Compliance (CMVP Validation Playbook, Approved Mode, Transition)

A practical FIPS 140-3 compliance and validation playbook for CMVP cryptographic module validation: boundary, security level selection, approved mode.

*Playbook* *GLOBAL*

## FIPS 140-3 Compliance playbook

A practical path from scope to CMVP-ready evidence: boundary, approved mode, services mapping, documentation, and lab readiness.

Optimized for teams shipping crypto libraries, HSMs, secure elements, firmware, and embedded modules under the current CMVP program rules.

FIPS 140-3 compliance is not a document-only exercise. It is an engineering and assurance program: you must define a defensible cryptographic module boundary, implement the required protections, and produce an evidence pack that an accredited CST laboratory can test and the CMVP can validate. This page gives a practical sequence that matches how strong teams actually get through validation.

## What FIPS 140-3 compliance means in practice

FIPS PUB 140-3 specifies security requirements for cryptographic modules and defines four increasing, qualitative security levels across 11 requirement areas. In practice, teams use the term compliance in two different ways: a vendor may design to the standard and claim internal compliance, or the team may pursue formal CMVP validation through a CST laboratory and receive a CMVP certificate.

That distinction matters because the CMVP FAQ expressly separates a vendor claim of compliance from a validated module. If a certificate does not exist, the module is not CMVP validated, even if the engineering team designed around FIPS 140-3 requirements.

- Compliance is a design and evidence target
- Validation is the formal CMVP outcome after CSTL testing and CMVP review
- Current planning should assume FIPS 140-3, not FIPS 140-2, because FIPS 140-2 active use for new systems ends on 21 September 2026

*Recommended next step*

*Placement: after the compliance steps*

## Turn FIPS 140-3 Compliance playbook into an operational assessment

Assessment Autopilot can take FIPS 140-3 Compliance playbook from operationalizing the guidance into a tracked program to a reusable workflow inside Sorena. Teams working on FIPS 140-3 can keep owners, evidence, and next steps aligned without copying this guide into separate documents.

- [Open Assessment Autopilot for FIPS 140-3 Compliance playbook](/solutions/assessment.md): Start from FIPS 140-3 Compliance playbook and turn the guidance into owned tasks, evidence requests, and review checkpoints.
- [Talk through FIPS 140-3](/contact.md): Review your current process, evidence gaps, and next steps for FIPS 140-3 Compliance playbook.

## Step 1: Define the module and freeze the boundary

The module boundary is the foundation of the whole project. Interfaces, roles, services, SSP handling, self-tests, physical assumptions, and the Security Policy all depend on that boundary staying stable.

If the boundary changes in the middle of lab work, you usually have to rework documentation, test procedures, and sometimes even the selected security level. Treat the boundary as an architecture decision with explicit change control.

- Define what code, firmware, hardware, and services are inside the module
- List every interface that crosses the boundary, including admin paths, debug paths, and API entry points
- Pin the tested operational environments and build identifiers early
- Document any embedded or bound modules with exact names, certificate numbers, and versions

## Step 2: Select the right security level and environment assumptions

Security levels are not procurement labels. They are assurance decisions tied to real deployment conditions, physical access risk, operator model, and the impact of SSP compromise.

Choose the level early because it changes engineering scope, evidence requirements, and lab expectations. A weak level decision usually shows up later as physical-security or operator-control rework.

- Level 1 is the baseline entry point for many software modules and lower physical-risk deployments
- Level 2 and Level 3 usually demand stronger physical and role-control discipline
- Level 4 is for the harshest or least controlled environments and should be justified by actual threat assumptions
- Write down the physical and operator assumptions so the level decision survives audit and customer review

## Step 3: Build an approved-mode design that you can prove

Approved mode is an operational state, not a slogan. Your services map, approved algorithms, self-tests, SSP protections, and mode indicators all have to support the same approved-mode story.

This is where current CMVP program material matters. The base standard is not enough by itself. Teams need the SP 800-140 series, the current Management Manual, and the current Implementation Guidance revision the lab will use.

- Define approved mode entry and exit conditions
- Map each service to approved security functions or clearly mark it as non-approved
- Make service indicators and runtime behavior match the Security Policy
- Ensure non-approved functions cannot be mistaken for approved security services

## Step 4: Build the documentation and test-evidence pack the CSTL will use

Validation speed depends heavily on documentation quality. The Security Policy, boundary diagrams, service inventory, SSP handling description, self-test behavior, and operational-environment definition must all align with what the CSTL will test.

Use version control and stable identifiers across the evidence pack. If the service list in the Security Policy does not match the code, logs, or test scripts, the CSTL will find it quickly and the project will slow down.

- Prepare a Security Policy that matches the tested build and tested environments
- Version every boundary diagram, service table, and build artifact
- Package repeatable test materials, expected outputs, and failure-state evidence
- Record the exact CMVP guidance baseline the submission was prepared against

## Step 5: Run the validation as a managed delivery process

The practical flow is vendor scope and evidence, CSTL testing, then CMVP review and validation. Teams that treat the submission as an ongoing delivery program do better than teams that treat it as a one-time documentation drop.

The current CMVP overview also distinguishes full five-year active validations from two-year interim validations. That matters for roadmap planning, customer messaging, and release governance.

- Enter lab work only after the boundary, service map, and Security Policy are stable
- Track CSTL questions and evidence deltas in a single controlled backlog
- Keep validated version identifiers tied to release management and customer claims
- Plan for certificate type, active-list duration, and any interim-validation implications

## Step 6: Protect the validated state after release

The post-validation risk is uncontrolled change. Platform updates, compiler changes, dependency changes, and module refactors can break the evidence story even when the feature set looks similar.

A practical maintenance model classifies changes, gates releases that affect boundary or approved mode, and keeps the evidence pack current enough that audits and customer reviews stay predictable.

- Pin validated versions, environments, and toolchains internally
- Run validation-impact review for boundary changes, algorithm changes, SSP changes, and major platform changes
- Refresh evidence for self-tests, SSP handling, and lifecycle controls on a defined cadence
- Keep marketing and procurement language aligned to the exact validated scope

## Primary sources

- [FIPS PUB 140-3 (Security Requirements for Cryptographic Modules)](https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.140-3.pdf?ref=sorena.io) - Primary standard defining the four qualitative levels and 11 requirement areas.
- [NIST and CCCS Cryptographic Module Validation Program](https://csrc.nist.gov/projects/cryptographic-module-validation-program?ref=sorena.io) - Official CMVP overview and current transition status.
- [CMVP FAQ](https://csrc.nist.gov/projects/cryptographic-module-validation-program/faqs?ref=sorena.io) - Official FAQ covering compliant versus validated claims and embedded-module treatment.
- [FIPS 140-3 CMVP Management Manual](https://csrc.nist.gov/csrc/media/Projects/cryptographic-module-validation-program/documents/fips%20140-3/FIPS-140-3-CMVP%20Management%20Manual.pdf?ref=sorena.io) - Current management manual governing submission and maintenance expectations.
- [Implementation Guidance for FIPS 140-3 and the CMVP](https://csrc.nist.gov/csrc/media/Projects/cryptographic-module-validation-program/documents/fips%20140-3/FIPS%20140-3%20IG.pdf?ref=sorena.io) - Current guidance for issues such as embedding, approved security service indicators, SSP handling, and self-tests.

## Related Topic Guides

- [FIPS 140-3 FAQ (CMVP Validation, Approved Mode, Embedded Modules, Transition)](/artifacts/global/fips-140-3/faq.md): FIPS 140-3 FAQ for cryptographic module teams: what FIPS 140-3 covers, how CMVP validation works, what approved mode means.
- [FIPS 140-3 Module Boundary and Services Mapping (Approved Mode, Embedded Modules)](/artifacts/global/fips-140-3/module-boundary-and-service-mapping.md): Advanced guide to FIPS 140-3 cryptographic module boundary definition and services mapping: boundary diagrams, approved-mode indicators, SSP access.
- [FIPS 140-3 Security Levels (Level 1 to Level 4) Explained](/artifacts/global/fips-140-3/security-levels-explained.md): FIPS 140-3 security levels explained: what Level 1, Level 2, Level 3, and Level 4 mean, how they affect boundary and deployment assumptions.
- [FIPS 140-3 Validation Checklist (CMVP Lab Readiness, Approved Mode, Transition)](/artifacts/global/fips-140-3/fips-140-3-validation-checklist.md): A practical FIPS 140-3 validation checklist for CMVP lab readiness: boundary, services, approved mode, documentation, self-tests, SSP management.


---

[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/compliance