Artifact GuideGLOBALFIPS 140-3

FIPS 140-3 Module Boundary Selector

Choose the cryptographic module boundary before writing FIPS 140-3 service tables, security policy claims, or CMVP validation evidence.

This selector helps separate in-boundary components, excluded components, operational environment dependencies, and embedded or bound validated modules.

Back to main artifact Review sources

Author

Sorena AI

Published

May 9, 2026

Updated

Jul 24, 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 Jul 24, 2026

Overview

Select the smallest that contains every component needed to deliver and protect the claimed cryptographic services, while leaving dependencies outside only when the module can use them through defined interfaces without assigning them module security functions. The selected hardware, software, firmware, interfaces, services, sensitive security parameters, and operational-environment assumptions must remain consistent across the Security Policy, test evidence, and certificate.

Section 1

Boundary decision to make before validation planning

Start by naming the implementation under test and the exact perimeter that will become the cryptographic module boundary. FIPS 140-3 covers multiple requirement areas, including cryptographic module specification, interfaces, roles, services, authentication, software and firmware security, operating environment, physical security, sensitive security parameter management, self-tests, life-cycle assurance, and mitigation of other attacks.

The selector should answer one question: which components are inside the module that must satisfy those requirements, and which components are outside the module but interact with it through defined ports, interfaces, services, or operational environment dependencies?

Engineering proposes the perimeter and component inventory; the vendor owns the validation claim and controlled Security Policy; the tests whether the selected module meets the applicable requirements; and CMVP reviews the submission. Product, security, and release owners should use the same boundary record so a later product change can be traced to the validated module.

Select the module type: hardware, software, firmware, hybrid software, or hybrid firmware.
Draw the physical or logical boundary before listing algorithms or approved services.
Name every in-boundary component that performs, stores, controls, or protects cryptographic functionality or sensitive security parameters.
List components designated as excluded separately, keep them inside the , explain why they do not affect module security, and version them as CMVP guidance requires.
Tie the chosen boundary to the security policy, test report, service table, operational environment list, and certificate wording.
Record the owner, drawing or inventory version, build identifier, decision date, unresolved dependencies, and change events that require the boundary to be selected again.

Sources for this answer

NIST FIPS 140-3 security requirements for cryptographic modules

Defines the standard's security requirement areas that become boundary-scoping checks for a cryptographic module.

CMVP Implementation Guidance for FIPS 140-3

Clarifies how the module under validation, existing validated modules, operational environments, and documentation affect boundary choices.

Recommended next step

Operationalize FIPS 140-3 boundary evidence

Use the boundary decision to assign the diagram, service table, security policy, certificate checks, and change-review work that a validation or procurement review will inspect.

Assessment workflow

Open Assessment Autopilot for FIPS 140-3

Convert the selected module boundary into accountable evidence requests and validation tasks.

Explore next step

Research workflow

Research FIPS 140-3 source questions

Resolve boundary, algorithm, operational environment, and certificate questions against cited source material.

Explore next step

Talk to Sorena

Talk through implementation

Review the module boundary, validation evidence, owners, and next FIPS 140-3 actions with Sorena.

Explore next step

Section 2

Selector tests for common boundary shapes

Use the boundary that matches how cryptographic services are actually delivered. A software module usually needs a precise tested operational environment. A hardware module needs a physical boundary. A hybrid module needs the disjoint hardware, software, or firmware pieces to be distinguishable. A sub-chip subsystem needs a single-chip physical boundary plus a defined hardware module interface for the subsystem.

Do not use the largest product enclosure as the boundary if only a smaller module is being validated, and do not use a narrow library boundary if the validated service depends on surrounding code, firmware, platform controls, or an embedded validated module.

For each candidate boundary, run the dependency test: if removing an outside component would stop an approved service, expose an SSP, bypass a self-test or service indicator, or move a security function outside the module, either include that component or document the CMVP-supported interface and reliance model. Do not call a component excluded merely to avoid testing it.

Full hardware module: use the physical perimeter that contains the cryptographic hardware, firmware, ports, interfaces, and physical security evidence.
Software or firmware module: define the executable module and the tested operating system, platform, processor, and hypervisor when applicable.
Hybrid module: identify the disjoint hardware and software or firmware components and show how services and sensitive security parameters cross between them.
Sub-chip subsystem: define the single-chip physical boundary and the hardware module interface for the cryptographic subsystem.
Product with another validated module: decide whether the existing module is embedded within the implementation under test or bound through a separate disjoint boundary.

Sources for this answer

CMVP Implementation Guidance for FIPS 140-3

Supports the selector tests for embedded modules, bound modules, operational environments, and sub-chip cryptographic subsystems.

NIST FIPS 140-3 security requirements for cryptographic modules

Provides the FIPS 140-3 context for choosing a boundary appropriate to the module's application, environment, and security services.

Section 3

Evidence the boundary must produce

A boundary is ready for review only when it can be represented consistently across the security policy, validation test report, diagrams, service tables, algorithm records, operational environment records, and change-control evidence. If those artifacts describe different boundaries, the selector has not finished its job.

For software, firmware, and hybrid modules that reuse validated algorithm implementations, confirm that the algorithm implementation has not been modified after integration and that the CAVP-tested operational environment is identical to, or fully included in, the module's test environment.

Boundary diagram showing security-relevant in-boundary components, in-boundary components designated as excluded, ports, interfaces, outside dependencies, and data or control paths.
Service table separating approved services, non-approved services, and any service indicators needed for approved-mode claims.
Sensitive security parameter map showing generation, entry, output, storage, zeroisation, and whether each movement crosses the .
Operational environment record listing the tested operating system, platform, processor, hypervisor, firmware version, or hardware version as applicable.
Algorithm and certificate evidence tied to the same implementation name, version, and tested environment used by the module submission.

Sources for this answer

CMVP Implementation Guidance for FIPS 140-3

Grounds the evidence requirements for tested operational environments, algorithm certificate binding, service indicators, and security policy distinctions.

NIST CAVP project

Official NIST program page for algorithm validation context used when preserving algorithm evidence alongside a module-boundary decision.

Section 4

Embedded and bound module checks

When the implementation under test uses another validated module, classify the relationship before drafting public or procurement claims. An embedded module is wholly contained within the implementation under test and provides services only to that implementation. A bound module has a separate, disjoint and the implementation under test depends on it.

The CMVP guidance adds consequences that affect the selector. A bound software, firmware, or hybrid implementation must operate in the same tested operational environment as the existing validated module, or in an environment contained within it. The submission also has to explain how any requirement satisfied through the existing module is met without violating other FIPS 140-3 requirements.

Identify the existing validated module by name, CMVP certificate number, validation status, version, and approved-mode use.
Mark existing validated module functionality distinctly in the security policy and test report instead of blending it into the implementation under test.
For bound modules, check that the existing validated module is at the same or higher security level for the relevant FIPS 140-3 sections, except where CMVP guidance allows a difference.
Do not claim functionality from an existing validated module unless that functionality is actually used by the implementation under test.
Treat a change to the tested operational environment, existing validated module status, or relied-upon service as a boundary-impact review trigger.

Sources for this answer

CMVP Implementation Guidance for FIPS 140-3

Defines embedded and bound module handling, including tested operational environment, security-level, documentation, and certificate-identification expectations.

NIST CMVP validated modules

Official CMVP search page for checking certificate identity and validation status before relying on another module in a boundary decision.

Section 5

Release gate for the selected boundary

Apply this gate before a team sends a module to a laboratory, reuses certificate language, answers a procurement question, or publishes a FIPS 140-3 claim. The selected boundary should be specific enough that an engineer, laboratory, buyer, and auditor can identify the same module without private context.

Boundary statement: one sentence that names the cryptographic module, module type, physical or logical perimeter, and tested operational environment.
Diagram match: the architecture diagram, service table, security policy, and test report all describe the same in-boundary and out-of-boundary components.
Interface match: data input, data output, control input, control output, and status output are mapped to the boundary where those interfaces are evaluated.
Service match: every approved service names the algorithm implementation, certificate evidence, sensitive security parameters, approved-mode condition, and indicator when needed.
Exclusion match: every excluded component remains inside the boundary, has a version and rationale, does not affect module security, and is described consistently in the Security Policy and test evidence.
Change trigger: software, firmware, hardware, algorithm implementation, operational environment, embedded module, bound module, certificate status, excluded component, or service-table changes require boundary review before reusing the claim.
Outcome: approve the boundary for laboratory planning, return it for missing evidence, or pause the claim because the product and validation materials identify different modules.

Sources for this answer

CMVP Implementation Guidance for FIPS 140-3

Supports release-gate checks for interfaces, tested environments, approved algorithms, and change impacts tied to the selected boundary.

NIST FIPS 140-3 security requirements for cryptographic modules

Provides the FIPS 140-3 requirement areas that release evidence must align with before relying on a boundary claim.

Section 6

Boundary mistakes that break FIPS 140-3 evidence

Most boundary failures show up as inconsistent evidence rather than bad labels. The usual pattern is a diagram that shows one module, a security policy that claims another, and algorithm or operational environment evidence that was tested under different conditions.

Using a product, appliance, or cloud service name as the module boundary without identifying the actual hardware, software, firmware, or hybrid module under validation.
Treating algorithm certificates as enough for a module claim without matching the implementation version and tested operational environment.
Designating an in-boundary component as excluded while relying on it to protect sensitive security parameters, provide approved services, or enforce approved-mode behavior, or treating "excluded" as if the component were outside the .
Binding to or embedding another module without separating the existing validated module's services, algorithms, self-tests, zeroisation, and sensitive security parameters in the evidence.
Reusing certificate language after changing the operational environment, firmware, loaded software image, service table, or existing validated module dependency.

Sources for this answer

CMVP Implementation Guidance for FIPS 140-3

Grounds the listed failure modes in CMVP guidance on boundaries, certificate binding, existing validated modules, and operational environment matching.

NIST CMVP validated modules

Official source for checking module certificate details before reusing validation language in a boundary claim.

Primary sources

References and citations

CMVP Implementation Guidance for FIPS 140-3

csrc.nist.gov

Referenced sections

Grounds the listed failure modes in CMVP guidance on boundaries, certificate binding, existing validated modules, and operational environment matching.