--- title: "FIPS 140-3 Module Boundary Selector Workflow" canonical_url: "https://www.sorena.io/artifacts/global/fips-140-3/module-boundary-selector-workflow" source_url: "https://www.sorena.io/artifacts/global/fips-140-3/module-boundary-selector-workflow" author: "Sorena AI" description: "A FIPS 140-3 workflow for selecting a cryptographic module boundary, separating embedded and bound modules, and collecting CMVP validation evidence." published_at: "2026-05-09" updated_at: "2026-05-09" keywords: - "FIPS 140-3 module boundary" - "cryptographic boundary" - "CMVP validation" - "embedded module" - "bound module" - "FIPS 140-3" - "module boundary" - "cryptographic module validation" - "CMVP" - "security policy" --- **[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 Selector Workflow A FIPS 140-3 workflow for selecting a cryptographic module boundary, separating embedded and bound modules, and collecting CMVP validation evidence. *Artifact Guide* *GLOBAL* *FIPS 140-3* ## FIPS 140-3 Module Boundary Selector Workflow A workflow for choosing the FIPS 140-3 cryptographic module boundary before teams write the security policy, reuse a certificate, or brief a CST laboratory. Grounded in FIPS 140-3 and CMVP implementation guidance for cryptographic module validation. Use this workflow when a product team must decide what belongs inside a FIPS 140-3 cryptographic module and what remains part of the surrounding system. The result should be a boundary diagram, a service and interface inventory, and an evidence pack that matches the module submitted to or relied on through CMVP. ## Start by naming the implementation under test The first decision is not the algorithm list. It is the implementation under test: the hardware, software, firmware, or hybrid cryptographic module whose boundary will be described in the security policy and validation evidence. FIPS 140-3 covers cryptographic module specification, interfaces, roles, services, authentication, operating environment, physical security, sensitive security parameter management, self-tests, life-cycle assurance, and other attack mitigations. A boundary selector workflow should therefore capture each component, service, interface, and environment that affects those areas. - Name the module type: hardware, software, firmware, hybrid software, or hybrid firmware. - List the components proposed inside the cryptographic boundary and the platform, operating system, application, or host functions proposed outside it. - Record the target security level claims by requirement area before treating a boundary as final. - Assign one owner for the boundary diagram, one owner for the service/interface inventory, and one owner for the security policy evidence. Sources for this answer: - [NIST FIPS 140-3 security requirements for cryptographic modules](https://doi.org/10.6028/NIST.FIPS.140-3?ref=sorena.io) - Supports the workflow start point by identifying FIPS 140-3 as a cryptographic-module standard with defined security requirement areas and security levels. - [CMVP Implementation Guidance for FIPS 140-3](https://csrc.nist.gov/csrc/media/Projects/cryptographic-module-validation-program/documents/FIPS%20140-3/FIPS%20140-3%20IG.pdf?ref=sorena.io) - Supports the implementation-under-test framing and the need to distinguish module functionality, services, algorithms, SSPs, self-tests, and zeroisation mechanisms. - [NIST CMVP validated modules search](https://csrc.nist.gov/projects/cryptographic-module-validation-program/validated-modules/search?ref=sorena.io) - Public CMVP search source for checking whether an existing module certificate can be used as evidence for the named implementation. ## Choose the boundary branch Select one branch and make the drawing match the branch. A hardware module normally needs a physical perimeter. A software or firmware module needs a logical cryptographic boundary inside a tested operational environment. A sub-chip design may have a single-chip physical boundary plus a sub-chip cryptographic subsystem boundary. Do not move services across branches by wording alone. If a service, key, SSP, entropy path, self-test, or approved-mode indicator depends on code or hardware outside the proposed module, the workflow must show whether that dependency is outside the boundary, embedded inside the module, or a separate bound validated module. - Hardware branch: show the physical boundary, ports, interfaces, and any sub-chip cryptographic subsystem boundary. - Software or firmware branch: show the module executable components inside the cryptographic boundary and the operating system, computing platform, and applications outside it. - Hybrid branch: identify which hardware, software, or firmware components are inside the boundary and which interfaces carry parameters across it. - Sub-chip branch: document the single-chip physical boundary and the hard or soft circuitry cores and firmware that form the sub-chip subsystem. Sources for this answer: - [NIST FIPS 140-3 security requirements for cryptographic modules](https://doi.org/10.6028/NIST.FIPS.140-3?ref=sorena.io) - Supports branching by module implementation type because FIPS 140-3 covers hardware, software, firmware, and combinations of those implementations. - [CMVP Implementation Guidance for FIPS 140-3](https://csrc.nist.gov/csrc/media/Projects/cryptographic-module-validation-program/documents/FIPS%20140-3/FIPS%20140-3%20IG.pdf?ref=sorena.io) - Supports the branch rules for cryptographic boundary, hardware module interface, software/firmware module interface, operational environment, and sub-chip subsystem treatment. - [NIST CMVP validated modules search](https://csrc.nist.gov/projects/cryptographic-module-validation-program/validated-modules/search?ref=sorena.io) - Public CMVP search source for comparing the selected branch against existing validation listings and certificate scope. ## Decide whether another validated module is embedded or bound The CMVP IG treats embedded and bound modules differently. An embedded module is wholly contained within the implementation-under-test boundary and provides services solely to that implementation. A bound module has a separate, disjoint boundary and the implementation under test depends on it. This decision changes the evidence request. For bound modules, the workflow must verify tested operational environments, security-level compatibility, certificate status, and how SSPs or services cross independent boundaries. For embedded modules, the workflow must show what functionality is used inside the implementation under test and how the security policy separates implementation-under-test and existing-validated-module information. - If the existing validated module is wholly inside the proposed module boundary and only serves that module, document it as embedded. - If the existing validated module keeps a separate cryptographic boundary and either module exposes application services, document it as bound. - For a bound relationship, check that the existing validated module is active at submission and that relied-on services or algorithms are approved at submission. - In the security policy and test report evidence, identify the existing validated module by name, CMVP certificate number, and version, and cite only the functionality actually used. Sources for this answer: - [NIST FIPS 140-3 security requirements for cryptographic modules](https://doi.org/10.6028/NIST.FIPS.140-3?ref=sorena.io) - Supports the need to keep the boundary decision tied to the cryptographic module that will be designed, implemented, operated, or procured. - [CMVP Implementation Guidance for FIPS 140-3](https://csrc.nist.gov/csrc/media/Projects/cryptographic-module-validation-program/documents/FIPS%20140-3/FIPS%20140-3%20IG.pdf?ref=sorena.io) - Supports the embedded-versus-bound decision rules, including disjoint boundaries, certificate identification, active status, and security policy separation. - [NIST CMVP validated modules search](https://csrc.nist.gov/projects/cryptographic-module-validation-program/validated-modules/search?ref=sorena.io) - Public CMVP search source for checking certificate numbers and status before relying on an existing validated module. ## Workflow table: boundary question, evidence, and stop condition Use this table in architecture review before validation planning: Step | Boundary question | Evidence to collect | Stop condition. 1 | What is the implementation under test? | Module type, version, product name, target security levels, and owner list | Stop if the team cannot identify one module and one evidence owner. 2 | Where is the cryptographic boundary? | Boundary diagram, component list, interfaces, ports, operational environment, and excluded components | Stop if algorithms, SSPs, services, or self-tests are described without a boundary. 3 | Is any existing validated module embedded or bound? | Certificate number, module version, active status check, and functionality actually used | Stop if the team cannot tell whether the dependency is inside the boundary or has a separate disjoint boundary. 4 | What crosses the boundary? | Service table, interface descriptions, SSP entry/output paths, entropy path, software/firmware load path, and approved-mode indicators | Stop if keys, entropy, firmware, or status indicators cross an undocumented interface. 5 | Can the selected boundary survive change? | Security policy draft, validation test report notes, certificate-reuse rationale, and change-impact review | Stop if a version, operating environment, excluded component, or bound-module status change would alter the evidence. - Keep the table tied to a specific module version; do not reuse it as a generic product checklist. - Attach source references to the row where a customer, assessor, or procurement reviewer is most likely to challenge the boundary claim. - Treat undocumented movement across the boundary as a design question, not a documentation cleanup item. Sources for this answer: - [NIST FIPS 140-3 security requirements for cryptographic modules](https://doi.org/10.6028/NIST.FIPS.140-3?ref=sorena.io) - Supports the table structure by tying boundary review to FIPS 140-3 areas such as interfaces, operating environment, self-tests, and life-cycle assurance. - [CMVP Implementation Guidance for FIPS 140-3](https://csrc.nist.gov/csrc/media/Projects/cryptographic-module-validation-program/documents/FIPS%20140-3/FIPS%20140-3%20IG.pdf?ref=sorena.io) - Supports stop conditions for boundary-crossing SSPs, software/firmware loading, embedded or bound modules, and certificate-reuse evidence. - [NIST CMVP validated modules search](https://csrc.nist.gov/projects/cryptographic-module-validation-program/validated-modules/search?ref=sorena.io) - Public CMVP search source for the certificate-status checks used in the workflow table. *Recommended next step* *Placement: after practical guidance* ## Operationalize the FIPS 140-3 boundary decision Use this workflow to convert a boundary diagram into owners, service tables, certificate checks, and change triggers before validation or procurement review. - [Open Assessment Autopilot for FIPS 140-3](/solutions/assessment.md): Convert the selected module boundary into accountable tasks, evidence requests, and review milestones. - [Research FIPS 140-3 source questions](/solutions/research-copilot.md): Use cited source material to resolve boundary, certificate, evidence, and validation questions before implementation. - [Talk through FIPS 140-3 implementation](/contact.md): Review the module boundary, CMVP evidence, owners, and next validation actions with Sorena. ## Evidence checklist for the selected boundary The boundary decision is ready for review only when the evidence can be read without private assumptions. The security policy, test report notes, diagrams, and validation searches should all point to the same module version and the same boundary. For procurement use, also capture what the certificate does not cover. FIPS 140-3 conformance does not by itself prove that the surrounding system is secure, so the workflow should separate validated module evidence from system risk acceptance. - Boundary diagram with in-scope components, excluded components, interfaces, operational environment, and physical or logical perimeter. - Service and role table showing approved services, non-approved services, authentication expectations, and approved-mode indicators. - Algorithm and entropy evidence with CAVP or CMVP references where applicable, plus notes on whether the evidence belongs to the implementation under test or an existing validated module. - Security policy text and validation test report notes that identify any existing validated module by name, certificate number, version, and used functionality. - Change-control triggers for module version changes, operating environment changes, excluded-component changes, certificate status changes, and changes to software or firmware loaded within the module boundary. Sources for this answer: - [NIST FIPS 140-3 security requirements for cryptographic modules](https://doi.org/10.6028/NIST.FIPS.140-3?ref=sorena.io) - Supports separating module validation evidence from broader system-security claims and residual-risk acceptance. - [CMVP Implementation Guidance for FIPS 140-3](https://csrc.nist.gov/csrc/media/Projects/cryptographic-module-validation-program/documents/FIPS%20140-3/FIPS%20140-3%20IG.pdf?ref=sorena.io) - Supports the evidence checklist for security policy content, test report distinctions, certificate numbers, versions, services, algorithms, SSPs, and self-tests. - [NIST CMVP validated modules search](https://csrc.nist.gov/projects/cryptographic-module-validation-program/validated-modules/search?ref=sorena.io) - Public CMVP search source for attaching validation-list evidence to procurement or certificate-reuse records. ## Boundary decisions that should trigger reassessment Reassess the selected boundary when a product change changes what is inside the cryptographic boundary, what crosses it, or which validated module the implementation depends on. The highest-risk failure is a certificate or security policy that still describes an earlier boundary. For software modules, operating environment changes matter because the module executes within a tested environment even though the platform and operating system sit outside the cryptographic boundary. For hardware and sub-chip designs, changes inside the physical boundary or subsystem boundary can affect whether prior validation evidence still matches the implementation. - A component marked as excluded is modified, because excluded components are still inside the module boundary in CMVP guidance. - Software or firmware is loaded, replaced, or stored differently within the module boundary. - An entropy source, DRBG, key-entry path, SSP output path, or approved-mode indicator moves across a different interface. - A bound or embedded module changes certificate status, version, approved service set, or approved algorithm status. - The product team wants to reuse a certificate for a different product, operating environment, boundary diagram, or service table. Sources for this answer: - [NIST FIPS 140-3 security requirements for cryptographic modules](https://doi.org/10.6028/NIST.FIPS.140-3?ref=sorena.io) - Supports reassessment when the module design, operation, environment, or life-cycle assurance evidence no longer matches the FIPS 140-3 validation claim. - [CMVP Implementation Guidance for FIPS 140-3](https://csrc.nist.gov/csrc/media/Projects/cryptographic-module-validation-program/documents/FIPS%20140-3/FIPS%20140-3%20IG.pdf?ref=sorena.io) - Supports reassessment triggers for excluded components, software/firmware loading, operational environments, and bound or embedded module status changes. - [NIST CMVP validated modules search](https://csrc.nist.gov/projects/cryptographic-module-validation-program/validated-modules/search?ref=sorena.io) - Public CMVP search source for checking whether certificate status changes affect the selected boundary evidence. ## Primary sources - [NIST FIPS 140-3 security requirements for cryptographic modules](https://doi.org/10.6028/NIST.FIPS.140-3?ref=sorena.io) - Primary source for FIPS 140-3 scope, security levels, applicability, covered security requirement areas, and the warning that module conformance does not alone prove surrounding-system security. - Quote: "four increasing, qualitative levels of security" - [CMVP Implementation Guidance for FIPS 140-3](https://csrc.nist.gov/csrc/media/Projects/cryptographic-module-validation-program/documents/FIPS%20140-3/FIPS%20140-3%20IG.pdf?ref=sorena.io) - Primary CMVP grounding for implementation-under-test terminology, cryptographic boundary definitions, embedded and bound module handling, evidence distinctions, and change-impact considerations. - Quote: "separate, disjoint cryptographic boundary" - [NIST CMVP validated modules search](https://csrc.nist.gov/projects/cryptographic-module-validation-program/validated-modules/search?ref=sorena.io) - Public validation-list source for checking certificate numbers and status before a boundary workflow relies on an existing validated module. - Quote: "Validated Modules" ## Related Topic Guides - [FIPS 140-3 algorithm certificate mapping: ACVTS certificates to module boundary](/artifacts/global/fips-140-3/algorithm-certificate-mapping.md): Map CAVP algorithm certificates to FIPS 140-3 module services, approved security functions, security policy tables, and validation evidence. - [FIPS 140-3 Algorithm Certificates FAQ](/artifacts/global/fips-140-3/faq/algorithm-certificates.md): How CAVP algorithm certificates support, but do not replace, FIPS 140-3 cryptographic module validation evidence. - [FIPS 140-3 Applicability Test](/artifacts/global/fips-140-3/applicability-test.md): Check whether FIPS 140-3 applies to a cryptographic module claim by testing agency use, module boundary, security level, approved functions, CMVP status, and procurement evidence. - [FIPS 140-3 Approved and Non-Approved Mode Workflow](/artifacts/global/fips-140-3/approved-and-non-approved-mode-workflow.md): Classify FIPS 140-3 module services by approved security service, allowed no-security-claimed use, and non-approved service evidence. - [FIPS 140-3 approved-mode evidence workflow](/artifacts/global/fips-140-3/approved-mode-evidence-workflow.md): A grounded workflow for collecting FIPS 140-3 approved-mode evidence: module boundary, approved services, service indicators, CAVP certificates, Security Policy entries, and change review. - [FIPS 140-3 Certificate Maintenance FAQ](/artifacts/global/fips-140-3/faq/certificate-maintenance.md): How to maintain FIPS 140-3 certificate evidence after validation by checking module status, version, caveats, Security Policy, and revalidation records. - [FIPS 140-3 Change Impact Review](/artifacts/global/fips-140-3/change-impact.md): Review FIPS 140-3 module changes against boundary, version, operational environment, embedded module, software loading, CVE, and certificate evidence. - [FIPS 140-3 compliance guide](/artifacts/global/fips-140-3/compliance.md): A grounded FIPS 140-3 compliance guide for cryptographic module scope, security-level claims, CMVP validation evidence, and procurement review. - [FIPS 140-3 Entropy and DRBG Evidence](/artifacts/global/fips-140-3/entropy-and-drbg.md): FIPS 140-3 entropy and DRBG guidance for module boundary decisions, entropy caveats, Security Policy evidence, ESV references, and DRBG CSP handling. - [FIPS 140-3 Entropy Evidence FAQ](/artifacts/global/fips-140-3/faq/entropy-evidence.md): How FIPS 140-3 entropy evidence should document entropy source location, GetEntropy access, SP 800-90B testing, Security Policy text, and certificate caveats. - [FIPS 140-3 FAQ for Cryptographic Modules](/artifacts/global/fips-140-3/faq.md): Answers to common FIPS 140-3 questions about scope, CMVP validation, algorithm certificates, module boundaries, approved mode, and validation evidence. - [FIPS 140-3 Module Boundaries FAQ](/artifacts/global/fips-140-3/faq/module-boundaries.md): Understand how FIPS 140-3 module boundaries affect cryptographic module scope, interfaces, software and firmware components, and bound or embedded validated modules. - [FIPS 140-3 operational environments FAQ](/artifacts/global/fips-140-3/faq/operational-environments.md): Learn what a FIPS 140-3 operational environment means for software, firmware, and hybrid cryptographic modules, and what evidence to check before relying on a validation claim. - [FIPS 140-3 security levels: how to choose and evidence them](/artifacts/global/fips-140-3/faq/security-levels.md): A practical FAQ on FIPS 140-3 security levels, module scope, CMVP evidence, bound or embedded modules, and common claim mistakes. - [FIPS 140-3 Security Policy Template](/artifacts/global/fips-140-3/security-policy-template.md): Build a FIPS 140-3 module Security Policy with sections for boundary, roles, services, approved algorithms, SSP handling, self-tests, and CMVP evidence. - [FIPS 140-3 Validation Checklist](/artifacts/global/fips-140-3/fips-140-3-validation-checklist.md): Checklist for preparing a cryptographic module for FIPS 140-3 validation: boundary, levels, services, approved algorithms, entropy, tests, security policy, and change evidence. - [FIPS 140-3 Validation Maintenance](/artifacts/global/fips-140-3/validation-maintenance.md): Maintain FIPS 140-3 validation claims by checking module identity, certificate status, boundary changes, operational environments, and CAVP evidence. - [FIPS 140-3 Validation Maintenance Change Workflow](/artifacts/global/fips-140-3/validation-maintenance-change-impact-workflow.md): A FIPS 140-3 workflow for triaging module changes against CMVP validation scope, Security Policy evidence, CAVP certificates, software loading, and CVE records. - [FIPS 140-3 Vendor Affirmation FAQ](/artifacts/global/fips-140-3/faq/vendor-affirmation.md): When vendor affirmation can support a FIPS 140-3 module claim, what it does not supersede, and which Security Policy, CAVP, CSTL, and test-report evidence to keep. - [FIPS 140-3 vs ISO/IEC 19790 and ISO/IEC 24759](/artifacts/global/fips-140-3/fips-140-3-vs-iso-19790.md): Compare FIPS 140-3 with ISO/IEC 19790 and ISO/IEC 24759 for cryptographic module validation scope, evidence, testing, and procurement claims. - [FIPS 140-3: CMVP Lifecycle Timeline](/artifacts/global/fips-140-3/cmvp-lifecycle-timeline.md): Practical FIPS 140-3 guidance for CMVP Lifecycle Timeline: scope, controls, evidence, source-linked decisions, and implementation checkpoints. - [FIPS 140-3: FIPS 140-2 vs FIPS 140-3](/artifacts/global/fips-140-3/fips-140-2-vs-fips-140-3.md): Compare FIPS 140-2 legacy references with FIPS 140-3 requirements, ISO/IEC 19790 alignment, CMVP testing evidence, and guidance mappings. - [FIPS 140-3: Module Boundary and Service Mapping](/artifacts/global/fips-140-3/module-boundary-and-service-mapping.md): Map a FIPS 140-3 cryptographic module boundary to services, approved algorithms, operational environments, and CMVP validation evidence. - [FIPS 140-3: Module Boundary Selector](/artifacts/global/fips-140-3/module-boundary-selector.md): Select and document a FIPS 140-3 cryptographic module boundary across hardware, software, firmware, operational environment, services, and validation evidence. - [FIPS 140-3: Operational Environment](/artifacts/global/fips-140-3/operational-environment.md): FIPS 140-3 operational environment guidance for software, firmware, hybrid, CAVP certificate, EVM, and PAA/PAI validation claims. - [FIPS 140-3: Security Levels Explained](/artifacts/global/fips-140-3/security-levels-explained.md): Explain FIPS 140-3 Security Levels 1 through 4, what they cover, and how to document level claims for cryptographic module validation. - [FIPS 140-3: step-by-step workflow for mapping algorithm certificates to CMVP modules](/artifacts/global/fips-140-3/algorithm-certificate-mapping-workflow.md): Map CAVP algorithm certificates to a FIPS 140-3 module by matching implementation identity, operational environment, module services, and security policy evidence. - [How should teams handle approved mode under FIPS 140-3?](/artifacts/global/fips-140-3/faq/approved-mode.md): Answer the FIPS 140-3 approved-mode question with service-level indicators, Security Policy evidence, and limits on non-approved functions. --- [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-selector-workflow