FIPS 140-3 Module Boundary Selector Workflow

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.

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.

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 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.

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.

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.