--- title: "FIPS 140-3 Security Levels (Level 1 to Level 4) Explained" canonical_url: "https://www.sorena.io/artifacts/global/fips-140-3/security-levels-explained" source_url: "https://www.sorena.io/artifacts/global/fips-140-3/security-levels-explained" author: "Sorena AI" description: "FIPS 140-3 security levels explained: what Level 1, Level 2, Level 3, and Level 4 mean, how they affect boundary and deployment assumptions." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "FIPS 140-3 security levels" - "FIPS 140-3 Level 1 Level 2 Level 3 Level 4" - "CMVP security level selection" - "FIPS 140-3 physical security level" - "FIPS 140-3 assurance level" - "cryptographic module security level" - "GLOBAL compliance" - "FIPS 140-3" - "Security levels" - "CMVP" --- **[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 (Level 1 to Level 4) Explained FIPS 140-3 security levels explained: what Level 1, Level 2, Level 3, and Level 4 mean, how they affect boundary and deployment assumptions. *Explainer* *GLOBAL* ## FIPS 140-3 Security levels explained FIPS 140-3 defines four increasing, qualitative security levels. Choose the level like an assurance decision, not a marketing label. This guide focuses on practical selection signals and evidence implications. FIPS 140-3 provides four increasing, qualitative security levels and applies security requirements across 11 requirement areas. The level you target affects engineering scope, documentation, testing, and the evidence your CST laboratory will expect. This page explains how to select a level in a defensible way. ## What the security levels represent FIPS 140-3 security levels are qualitative and increasing. Higher levels generally require stronger protections and stronger proof across requirement areas, especially where physical access and tampering are realistic risks. Because the levels apply across multiple requirement areas, a level decision influences boundary design, physical assumptions, operator controls, SSP handling, and the final Security Policy. - Levels are assurance targets, not feature bundles - Higher levels usually mean stronger physical and operational controls - The chosen level should match the actual deployment environment and threat model ## How to choose a level that survives review The defensible way to choose a level is to tie it to measurable assumptions: physical access risk, operator access, attacker capability, and the impact of SSP compromise. Teams often get into trouble when they choose a level only because a customer asked for it. If the boundary, physical design, or operations model cannot support the choice, the level selection collapses under lab review. - Physical access: who can reach the module, host, ports, or debug surfaces? - Operator model: who administers the module and how are privileged actions controlled? - Impact: what happens if keys or other SSPs are extracted or corrupted? - Environment control: controlled facility, enterprise environment, field deployment, or hostile environment? ## What changes as you move up levels The difference between levels is not mainly more paperwork. It is stronger design constraints and stronger proof obligations. That affects physical security evidence, role and authentication evidence, SSP handling evidence, and sometimes the practicality of the chosen boundary. If you decide the target level late, you usually pay for it with redesign work and test-plan churn. - Boundary scrutiny increases because interface and trust assumptions matter more - Physical security evidence becomes more important as tamper risk increases - Role and authentication evidence usually becomes stricter - SSP protection and zeroization proof must be clearer and more attributable ## Practical starting heuristics These are not substitutes for CSTL advice, but they are useful early filters when you are deciding what is realistic. - If physical access risk is low and you need a baseline assurance target, evaluate Level 1 first - If you need stronger tamper evidence and stronger operator discipline, evaluate Level 2 - If you need stronger physical and logical protections in environments where tampering is plausible, evaluate Level 3 - If the module must resist the harshest or least controlled physical environments, evaluate Level 4 - If you cannot write down the physical and operator assumptions, the level selection is not defensible yet *Recommended next step* *Placement: near the end of the main content before related guides* ## Use FIPS 140-3 Security levels explained as a cited research workflow Research Copilot can take FIPS 140-3 Security levels explained from getting cited answers and faster research on this topic 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 Research Copilot for FIPS 140-3 Security levels explained](/solutions/research-copilot.md): Start from FIPS 140-3 Security levels explained and answer scope, timing, and interpretation questions with cited outputs. - [Talk through FIPS 140-3](/contact.md): Review your current process, evidence gaps, and next steps for FIPS 140-3 Security levels explained. ## 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) - Defines the four qualitative security levels and the 11 requirement areas. - [NIST and CCCS CMVP program overview](https://csrc.nist.gov/projects/cryptographic-module-validation-program?ref=sorena.io) - Program context for how modules are tested and validated under FIPS 140-3. - [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 clarifications that affect how level expectations are interpreted in practice. ## Related Topic Guides - [FIPS 140-3 Compliance (CMVP Validation Playbook, Approved Mode, Transition)](/artifacts/global/fips-140-3/compliance.md): A practical FIPS 140-3 compliance and validation playbook for CMVP cryptographic module validation: boundary, security level selection, approved mode. - [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 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/security-levels-explained