FIPS 140-3 Module Boundary Selector Workflow

Name the implementation under test before compiling the algorithm list: 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.

Select one branch and make the drawing match the branch. A hardware module has a physical cryptographic boundary. Software, firmware, hybrid, and sub-chip modules require diagrams that locate the logical object, supporting applications and operating system, cryptographic boundary, and relevant physical layers. SP 800-140B Rev. 1 also requires the Tested Operational Environment's Physical Perimeter (TOEPP) to be identified; the TOEPP may extend beyond the cryptographic boundary.

Do not move services across branches by wording alone. If a service, key, sensitive security parameter (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.

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.

Use these five steps in architecture review before validation planning.

Step 1: What is the implementation under test? Evidence: Module type, version, product name, target security levels, and owner list. Stop if the team cannot identify one module and one evidence owner.

Step 2: Where are the cryptographic boundary and TOEPP? Evidence: Boundary diagram, physical and logical layers, component list, interfaces, ports, operational environment, and excluded components. Stop if algorithms, SSPs, services, or self-tests are described without a boundary, or if the TOEPP is mistaken for the cryptographic boundary.

Step 3: Is any existing validated module embedded or bound? Evidence: 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.

Step 4: What crosses the boundary? Evidence: 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.

Step 5: Can the selected boundary survive change? Evidence: Security policy draft, validation test report notes, certificate-reuse rationale, and change-impact review. Hold the decision if no owner or review path is assigned for version, operating environment, excluded-component, or bound-module status changes that would alter the evidence.

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.

Approve the boundary for laboratory planning only when the architecture owner, module engineer, Security Policy owner, and CST laboratory contact can identify the same module, version, diagram, interfaces, and dependency treatment. Otherwise record the decision as revise boundary, split or combine the proposed module, document an embedded or bound dependency, or hold for CST laboratory guidance.

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.