FIPS 140-3 Module Boundary and Service Mapping

FIPS 140-3 applies to cryptographic modules, not to every surrounding product feature. Draw the physical or logical boundary first, then identify the module type, hardware, software, firmware, hybrid components, ports, interfaces, operational environment, and security level claims that sit inside that boundary.

Use the boundary to separate module evidence from system evidence. Product documentation can describe a platform, appliance, cloud service, or application, but the FIPS validation package must make clear which components, interfaces, roles, services, algorithms, self-tests, and sensitive security parameter handling belong to the module itself.

An excluded component is still inside the cryptographic boundary. The vendor must identify it, justify why correct operation or malfunction cannot interfere with approved secure operation, and support the laboratory's test approach. Examples in CMVP guidance include memory, power supplies, line cards, fans, switches, resistors, capacitors, and inductors; exclusion is a tested design claim, not a label for an out-of-scope dependency.

After the boundary is stable, build the service map. Each operator-visible service, and each internal service that supports a security claim, should identify the role or caller, inputs and outputs, algorithm or security function, approved or non-approved treatment, SSP access, self-test dependencies, error behavior, and approved-service indicator.

The CMVP implementation guidance expects approved services to indicate use of approved algorithms, including cases where the module requests an approved algorithm from an existing validated module. Treat the service table as the control surface for approved-mode claims: if a service cannot identify the algorithm, certificate, role, and state separation behind the claim, it should not be described as approved.

Boundary mistakes often appear when a module depends on an existing validated module. CMVP guidance distinguishes embedded modules, which are wholly contained within the module boundary and provide services only to the module under validation, from bound modules, which have separate disjoint boundaries and can expose application services from either module.

For an IUT that binds to or embeds an existing validated module, the submission should identify the existing module by name, CMVP certificate number, and version. The security policy and validation report should distinguish IUT functionality from existing validated module functionality, including services, algorithms, SSPs, self-tests, and zeroization mechanisms.

The existing validated module must be Active when the IUT is submitted, and a FIPS 140-3 IUT cannot bind to or embed a FIPS 140-2 module under IG 1.A. The IUT may claim only the dependency's services and algorithms that are approved at submission. If the dependency later becomes Historical, the relying IUT inherits Historical status.

A defensible mapping package should let a reviewer trace each approved-mode statement from the public claim back to the module boundary, service table, algorithm evidence, and operating environment. Keep the package versioned with the module release and validation submission rather than as a generic product compliance note.

Use these questions before procurement, customer assurance, or a CMVP submission relies on the map. They are designed to catch overbroad FIPS claims, stale certificate reuse, and service tables that do not match the actual module boundary.