Artifact GuideGLOBALFIPS 140-3

FIPS 140-3 Module Boundary and Service Mapping

Define what is inside the cryptographic module, which services cross that boundary, and what evidence supports approved-mode claims.

Use this as validation planning guidance alongside FIPS 140-3, CMVP implementation guidance, and current certificate records.

Back to main artifact Review sources

Author

Sorena AI

Published

May 9, 2026

Updated

May 9, 2026

Sections

Structured answer sets in this page tree.

Primary sources

Cited legal and guidance references.

Publication metadata

Sorena AI

Published May 9, 2026

Updated May 9, 2026

Overview

Use this page when a product team needs to turn a FIPS 140-3 module design into a boundary diagram, service table, approved-mode claim, and CMVP evidence pack. The useful question is not whether the product uses cryptography; it is which cryptographic module is being validated, what is inside its boundary, which services operators can invoke, and which certificate or test evidence supports each claim.

Section 1

Start with the cryptographic module boundary

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.

Create a boundary diagram that names included hardware, software, firmware, interfaces, and excluded surrounding system components.
Tie each claimed FIPS 140-3 security area to the boundary: module specification, interfaces, roles and services, software or firmware security, operating environment, physical security, SSP management, self-tests, and lifecycle assurance.
Record the tested operational environment for software, firmware, and hybrid modules before reusing algorithm certificates or module evidence.
Keep customer-facing scope language aligned with the CMVP certificate, security policy, validation test report, and any caveats.

Sources for this answer

NIST FIPS 140-3 security requirements for cryptographic modules

Supports the page scope: FIPS 140-3 is a cryptographic module standard covering module specification, interfaces, roles and services, operating environment, self-tests, and related security areas.

CMVP Implementation Guidance for FIPS 140-3

Supports boundary handling for bound or embedded modules, service-table marking, operational environment matching, and approved service indicators.

NIST CAVP validation search

Use this public search endpoint to verify algorithm certificate evidence referenced by the module mapping.

Section 2

Map every service to approved-mode status

After the boundary is stable, build the service map. Each operator-visible or internally invoked cryptographic service should identify the role that can call it, the algorithm or security function used, whether it is approved, non-approved but allowed, or non-approved, and whether the service changes CSPs or other SSPs.

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.

List approved services separately from non-approved services and non-security-relevant functions.
For each approved service, capture role, service name, algorithm or security function, CAVP certificate, key or SSP access, and approved service indicator behavior.
For non-approved functions used with no security claimed, document why the processed data can be treated as plaintext and why the function does not support a security claim; also confirm approved and non-approved services do not share keys or CSPs in a way that would undermine the approved-mode security objectives.

Sources for this answer

NIST FIPS 140-3 security requirements for cryptographic modules

Supports service mapping as part of the FIPS 140-3 roles, services, authentication, interfaces, and security-function requirements.

CMVP Implementation Guidance for FIPS 140-3

Supports approved-service indicators, approved and non-approved service separation, and security-policy tables used in CMVP submissions.

NIST CAVP validation search

Use this source to check the certificate number, algorithm name, implementation version, and operating environment behind an approved-service claim.

Recommended next step

Operationalize FIPS 140-3 module mapping

Use the boundary, service, algorithm, and operating-environment map as the intake record for FIPS 140-3 validation planning and customer assurance reviews.

Assessment workflow

Open Assessment Autopilot for FIPS 140-3

Convert the module boundary and service map into evidence requests, owners, and review gates.

Explore next step

Research workflow

Research FIPS 140-3 source questions

Use cited NIST and CMVP material to resolve boundary, service, algorithm, and certificate-scope questions before implementation.

Explore next step

Talk to Sorena

Talk through FIPS 140-3 implementation

Review module scope, approved-mode evidence, owners, and the next validation-planning actions with Sorena.

Explore next step

Section 3

Handle bound and embedded modules explicitly

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.

Mark EVM-dependent entries in security-policy tables so readers can see which services, algorithms, SSPs, roles, self-tests, and error states belong to the existing validated module.
For bound software, firmware, or hybrid modules, compare the IUT and EVM tested operational environments before relying on the EVM.
Verify that a bound EVM has the required validation status and security level relationship for the IUT claim.
Cite only the EVM functionality actually used by the IUT; do not import the whole certificate scope into the IUT evidence pack.

Sources for this answer

NIST FIPS 140-3 security requirements for cryptographic modules

Supports focusing validation evidence on the cryptographic module and its applicable implementation and operating environment.

CMVP Implementation Guidance for FIPS 140-3

Supports the embedded-versus-bound module distinction, EVM identification requirements, and table markings for EVM functionality.

NIST CAVP validation search

Use this source when EVM services rely on separately validated algorithm implementations that must be checked against the IUT service map.

Section 4

Evidence checklist for a boundary and service map

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.

Boundary evidence: physical or logical diagram, included and excluded components, ports and interfaces, module type, and security level claims.
Service evidence: approved and non-approved service tables, roles, authentication behavior, service indicators, SSP access, and key/CSP separation rules.
Algorithm evidence: CAVP certificate numbers, implementation names and versions, operational environments, vendor-affirmed entries, and any EVM markings.
CMVP evidence: security policy excerpts, validation test report references, certificate number, certificate status, caveats, and change-impact notes.
Change triggers: boundary changes, software or firmware changes, operating environment changes, algorithm transitions, EVM status changes, or service behavior changes.

Sources for this answer

NIST FIPS 140-3 security requirements for cryptographic modules

Supports the evidence categories by naming the module security areas that must be addressed in design, implementation, and operation.

CMVP Implementation Guidance for FIPS 140-3

Supports operational environment matching, CAVP certificate binding, security-policy table treatment, and change-sensitive EVM evidence.

NIST CAVP validation search

Use this source to confirm that algorithm evidence still matches the implementation and operational environment used in the module submission.

Section 5

Review questions before relying on the mapping

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.

Does the boundary diagram match the module named in the security policy and certificate, rather than the broader product or deployment?
Can every approved service point to an approved algorithm or approved process, a role, a service indicator, and relevant CAVP or CMVP evidence?
Are non-approved services, non-approved but allowed algorithms, and no-security-claimed functions separated from approved-mode services?
If an EVM is bound or embedded, are its name, certificate number, version, validation status, tested operational environment, and used services explicitly identified before the claim is reused after software, firmware, operating environment, EVM, algorithm-transition, or boundary changes?

Sources for this answer

NIST FIPS 140-3 security requirements for cryptographic modules

Supports reviewing whether claimed security levels and services are appropriate for the application, environment, and module validation scope.

CMVP Implementation Guidance for FIPS 140-3

Supports the review questions around approved service indicators, non-approved security functions, operational environments, and EVM reliance.

NIST CAVP validation search

Use this source during review to check whether algorithm certificates still support the mapped service claims.

Primary sources