--- title: "FIPS 140-3 Module Boundary and Services Mapping (Approved Mode, Embedded Modules)" canonical_url: "https://www.sorena.io/artifacts/global/fips-140-3/module-boundary-and-service-mapping" source_url: "https://www.sorena.io/artifacts/global/fips-140-3/module-boundary-and-service-mapping" author: "Sorena AI" description: "Advanced guide to FIPS 140-3 cryptographic module boundary definition and services mapping: boundary diagrams, approved-mode indicators, SSP access." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "FIPS 140-3 module boundary" - "cryptographic boundary definition" - "FIPS 140-3 services mapping" - "approved mode of operation" - "approved security functions mapping" - "CMVP IG boundary guidance" - "FIPS 140-3 service indicator" - "FIPS 140-3 Security Policy boundary" - "FIPS 140-3 SSP mapping" - "FIPS 140-3" - "Cryptographic boundary" - "Approved mode" - "Services mapping" - "CMVP IG" --- **[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 Module Boundary and Services Mapping (Approved Mode, Embedded Modules) Advanced guide to FIPS 140-3 cryptographic module boundary definition and services mapping: boundary diagrams, approved-mode indicators, SSP access. *Deep dive* *GLOBAL* ## FIPS 140-3 Module boundary and services mapping Define the cryptographic boundary correctly and build a services map that makes approved mode provable. This is where many CMVP projects succeed or fail: boundary discipline plus service-to-function traceability. In FIPS 140-3, the module boundary and the services map are the backbone of the entire validation. The Security Policy, lab test plan, approved-mode story, SSP handling, self-tests, and operational-environment scope all have to match them. This guide explains how to define the boundary and services in a way that survives CSTL scrutiny and CMVP review. ## Start with the object of conformity FIPS 140-3 validates a cryptographic module. That module may be software, firmware, hardware, or a hybrid, but you must be able to describe exactly what that object is and where its boundary sits. Boundary mistakes are expensive because they force rework across documentation, testing, and release control. Treat boundary definition as an architecture decision with formal ownership. - Define the module embodiment: software, firmware, hardware, or hybrid - Define where approved security functions execute - Define what is explicitly excluded from the module - Pin versions and tested environments so the boundary maps to a specific release ## What a good boundary diagram must show A boundary diagram is not decorative. It is a contract between engineering, documentation, tests, and customer claims. It should be versioned and used consistently everywhere. - Clear perimeter showing in-scope and out-of-scope components - Every interface that crosses the boundary, including APIs, ports, admin channels, and debug paths - Roles and operator entry points - Where SSPs exist in memory, storage, or hardware-backed stores - What happens to module behavior when self-tests fail ## Build a services inventory before you argue about approved mode The services inventory should enumerate every callable service and every security-relevant function the module provides. Each service should have a stable identifier so the mapping remains consistent across code, documentation, and tests. The purpose of the inventory is to eliminate ambiguity. If a service could be interpreted as a security function, the inventory must classify it clearly and explain how it behaves in approved and non-approved states. - Service identifier, name, and short description - Roles allowed to invoke the service - Inputs and outputs, including any SSP exposure - Approved-mode behavior and non-approved behavior - Underlying approved security functions used by the service - Evidence links such as test case IDs, logs, config references, or policy sections ## Map services to approved security functions in a testable way A strong map lets the lab see which services are in scope, which are approved in approved mode, which algorithms and self-tests support them, and how SSP protection applies. Current Implementation Guidance places a lot of weight on consistency. Approved service indicators must not imply approval if the necessary conditions for approved operation are not actually met. - Map each service to approved functions or explicitly mark it non-approved - Tie each service to required self-tests and error-state behavior - Map each service to SSP access and zeroization expectations - Tie each service to the evidence artifacts that prove the claim - Define one approved-mode narrative and keep it consistent across all services ## Handle embedded or bound modules without overclaiming If you embed or bind to other validated modules, boundary clarity becomes even more important. Current CMVP FAQ and guidance materials distinguish your module under test from any embedded validated module it relies on. The common failure is overclaiming. A product that uses an embedded validated module is not automatically itself validated. Another failure is vague documentation that prevents the lab from telling what your own module actually does versus what the embedded module contributes. - Identify embedded or bound modules precisely with exact certificate and version information - Represent your module functionality separately from embedded functionality - Only cite embedded functionality the module actually uses - Keep marketing language aligned with the actual certificate scope ## Deliver a boundary-to-evidence blueprint The easiest way to reduce rework is to create a single boundary-to-evidence blueprint that engineering, documentation, QA, and the CSTL can all use. That blueprint should combine the boundary, services inventory, SSP map, approved-mode rules, and evidence references in one controlled place. - Boundary diagram and interface inventory - Roles, services, and authentication matrix - Approved-mode definition and service indicator behavior - SSP lifecycle map and zeroization evidence plan - Evidence register with ownership and update rules *Recommended next step* *Placement: after the template, evidence, or documentation block* ## Keep FIPS 140-3 Module boundary and services mapping in one governed evidence system SSOT can take FIPS 140-3 Module boundary and services mapping from reusing this material inside a governed evidence system 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 SSOT for FIPS 140-3 Module boundary and services mapping](/solutions/ssot.md): Start from FIPS 140-3 Module boundary and services mapping and keep documents, evidence, and control records in one governed system. - [Talk through FIPS 140-3](/contact.md): Review your current process, evidence gaps, and next steps for FIPS 140-3 Module boundary and services mapping. ## 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 requirement areas for module specification, interfaces, roles and services, and SSP management. - [CMVP FAQ](https://csrc.nist.gov/projects/cryptographic-module-validation-program/faqs?ref=sorena.io) - Official clarification that products using embedded validated modules are not automatically themselves validated. - [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 embedding, binding, approved security service indicators, and documentation expectations. - [NIST and CCCS CMVP program overview](https://csrc.nist.gov/projects/cryptographic-module-validation-program?ref=sorena.io) - Program context and supporting links for validation flow and accepted artifacts. ## 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 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/module-boundary-and-service-mapping