---
title: "FIPS 140-3: Module Boundary Selector"
canonical_url: "https://www.sorena.io/artifacts/global/fips-140-3/module-boundary-selector"
source_url: "https://www.sorena.io/artifacts/global/fips-140-3/module-boundary-selector"
author: "Sorena AI"
description: "Select and document a FIPS 140-3 cryptographic module boundary across hardware, software, firmware, operational environment, services, and validation evidence."
published_at: "2026-05-09"
updated_at: "2026-05-09"
keywords:
  - "FIPS 140-3 module boundary"
  - "cryptographic module boundary"
  - "CMVP validation"
  - "FIPS security policy"
  - "FIPS 140-3"
  - "module boundary"
  - "cryptographic module validation"
  - "CMVP"
  - "security policy"
---
**[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform

[Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io)

---

# FIPS 140-3: Module Boundary Selector

Select and document a FIPS 140-3 cryptographic module boundary across hardware, software, firmware, operational environment, services, and validation evidence.

*Artifact Guide* *GLOBAL* *FIPS 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.

Use this selector to separate in-boundary components, excluded components, operational environment dependencies, and embedded or bound validated modules.

A FIPS 140-3 boundary decision defines what hardware, software, firmware, interfaces, services, sensitive security parameters, and operational environment are part of the cryptographic module being validated. Use this page when a product team needs to decide whether to validate a full product, a software module, a firmware image, a hardware component, a hybrid module, a sub-chip subsystem, or a module that depends on another validated module.

## 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?

- 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 excluded components separately and explain why they are not security relevant to the FIPS 140-3 claims.
- Tie the chosen boundary to the security policy, test report, service table, operational environment list, and certificate wording.

Sources for this answer:

- [NIST FIPS 140-3 security requirements for cryptographic modules](https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.140-3.pdf?ref=sorena.io) - Defines the standard's security requirement areas that become boundary-scoping checks for a cryptographic module.
- [CMVP Implementation Guidance for FIPS 140-3](https://csrc.nist.gov/csrc/media/Projects/cryptographic-module-validation-program/documents/FIPS%20140-3/FIPS%20140-3%20IG.pdf?ref=sorena.io) - Clarifies how the module under validation, existing validated modules, operational environments, and documentation affect boundary choices.

*Recommended next step*

*Placement: after boundary evidence*

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

- [Open Assessment Autopilot for FIPS 140-3](/solutions/assessment.md): Convert the selected module boundary into accountable evidence requests and validation tasks.
- [Research FIPS 140-3 source questions](/solutions/research-copilot.md): Resolve boundary, algorithm, operational environment, and certificate questions against cited source material.
- [Talk through implementation](/contact.md): Review the module boundary, validation evidence, owners, and next FIPS 140-3 actions with Sorena.

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

- 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](https://csrc.nist.gov/csrc/media/Projects/cryptographic-module-validation-program/documents/FIPS%20140-3/FIPS%20140-3%20IG.pdf?ref=sorena.io) - 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](https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.140-3.pdf?ref=sorena.io) - Provides the FIPS 140-3 context for choosing a boundary appropriate to the module's application, environment, and security services.

## 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 in-boundary components, excluded components, ports, interfaces, 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 cryptographic boundary.
- 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](https://csrc.nist.gov/csrc/media/Projects/cryptographic-module-validation-program/documents/FIPS%20140-3/FIPS%20140-3%20IG.pdf?ref=sorena.io) - Grounds the evidence requirements for tested operational environments, algorithm certificate binding, service indicators, and security policy distinctions.
- [NIST CAVP project](https://csrc.nist.gov/projects/cryptographic-algorithm-validation-program?ref=sorena.io) - Official NIST program page for algorithm validation context used when preserving algorithm evidence alongside a module-boundary decision.

## 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 cryptographic boundary 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](https://csrc.nist.gov/csrc/media/Projects/cryptographic-module-validation-program/documents/FIPS%20140-3/FIPS%20140-3%20IG.pdf?ref=sorena.io) - Defines embedded and bound module handling, including tested operational environment, security-level, documentation, and certificate-identification expectations.
- [NIST CMVP validated modules](https://csrc.nist.gov/projects/cryptographic-module-validation-program/validated-modules?ref=sorena.io) - Official CMVP search page for checking certificate identity and validation status before relying on another module in a boundary decision.

## Release gate for the selected boundary

Use this gate before a team sends a module to a laboratory, reuses certificate language, responds to procurement questions, or publishes FIPS 140-3 claims. The selected boundary should be specific enough that an engineer, lab, 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.
- Change trigger: software, firmware, hardware, algorithm implementation, operational environment, embedded module, bound module, certificate status, or service-table changes require boundary review before reusing the claim.

Sources for this answer:

- [CMVP Implementation Guidance for FIPS 140-3](https://csrc.nist.gov/csrc/media/Projects/cryptographic-module-validation-program/documents/FIPS%20140-3/FIPS%20140-3%20IG.pdf?ref=sorena.io) - 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](https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.140-3.pdf?ref=sorena.io) - Provides the FIPS 140-3 requirement areas that release evidence must align with before relying on a boundary claim.

## 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.
- Calling a component excluded while still relying on it to protect sensitive security parameters, provide approved services, or enforce approved-mode behavior.
- 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](https://csrc.nist.gov/csrc/media/Projects/cryptographic-module-validation-program/documents/FIPS%20140-3/FIPS%20140-3%20IG.pdf?ref=sorena.io) - Grounds the listed failure modes in CMVP guidance on boundaries, certificate binding, existing validated modules, and operational environment matching.
- [NIST CMVP validated modules](https://csrc.nist.gov/projects/cryptographic-module-validation-program/validated-modules?ref=sorena.io) - Official source for checking module certificate details before reusing validation language in a boundary claim.

## Primary sources

- [NIST FIPS 140-3 security requirements for cryptographic modules](https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.140-3.pdf?ref=sorena.io) - Primary standard for the module requirement areas that drive boundary selection and evidence alignment.
  - Quote: "secure design, implementation and operation"
- [CMVP Implementation Guidance for FIPS 140-3](https://csrc.nist.gov/csrc/media/Projects/cryptographic-module-validation-program/documents/FIPS%20140-3/FIPS%20140-3%20IG.pdf?ref=sorena.io) - CMVP guidance for boundary-sensitive issues such as embedded modules, bound modules, tested operational environments, algorithm certificate binding, interfaces, and security policy documentation.
  - Quote: "Implementation Guidance for FIPS PUB 140-3"
- [NIST CMVP validated modules](https://csrc.nist.gov/projects/cryptographic-module-validation-program/validated-modules?ref=sorena.io) - Official CMVP search page for checking certificate identity and validation status when a selected boundary relies on another validated module.
  - Quote: "validated-modules"
- [NIST CAVP project](https://csrc.nist.gov/projects/cryptographic-algorithm-validation-program?ref=sorena.io) - Official NIST program page for algorithm validation context used when mapping algorithm implementation evidence into the selected module boundary.
  - Quote: "Cryptographic Algorithm Validation Program"

## Related Topic Guides

- [FIPS 140-3 algorithm certificate mapping: ACVTS certificates to module boundary](/artifacts/global/fips-140-3/algorithm-certificate-mapping.md): Map CAVP algorithm certificates to FIPS 140-3 module services, approved security functions, security policy tables, and validation evidence.
- [FIPS 140-3 Algorithm Certificates FAQ](/artifacts/global/fips-140-3/faq/algorithm-certificates.md): How CAVP algorithm certificates support, but do not replace, FIPS 140-3 cryptographic module validation evidence.
- [FIPS 140-3 Applicability Test](/artifacts/global/fips-140-3/applicability-test.md): Check whether FIPS 140-3 applies to a cryptographic module claim by testing agency use, module boundary, security level, approved functions, CMVP status, and procurement evidence.
- [FIPS 140-3 Approved and Non-Approved Mode Workflow](/artifacts/global/fips-140-3/approved-and-non-approved-mode-workflow.md): Classify FIPS 140-3 module services by approved security service, allowed no-security-claimed use, and non-approved service evidence.
- [FIPS 140-3 approved-mode evidence workflow](/artifacts/global/fips-140-3/approved-mode-evidence-workflow.md): A grounded workflow for collecting FIPS 140-3 approved-mode evidence: module boundary, approved services, service indicators, CAVP certificates, Security Policy entries, and change review.
- [FIPS 140-3 Certificate Maintenance FAQ](/artifacts/global/fips-140-3/faq/certificate-maintenance.md): How to maintain FIPS 140-3 certificate evidence after validation by checking module status, version, caveats, Security Policy, and revalidation records.
- [FIPS 140-3 Change Impact Review](/artifacts/global/fips-140-3/change-impact.md): Review FIPS 140-3 module changes against boundary, version, operational environment, embedded module, software loading, CVE, and certificate evidence.
- [FIPS 140-3 compliance guide](/artifacts/global/fips-140-3/compliance.md): A grounded FIPS 140-3 compliance guide for cryptographic module scope, security-level claims, CMVP validation evidence, and procurement review.
- [FIPS 140-3 Entropy and DRBG Evidence](/artifacts/global/fips-140-3/entropy-and-drbg.md): FIPS 140-3 entropy and DRBG guidance for module boundary decisions, entropy caveats, Security Policy evidence, ESV references, and DRBG CSP handling.
- [FIPS 140-3 Entropy Evidence FAQ](/artifacts/global/fips-140-3/faq/entropy-evidence.md): How FIPS 140-3 entropy evidence should document entropy source location, GetEntropy access, SP 800-90B testing, Security Policy text, and certificate caveats.
- [FIPS 140-3 FAQ for Cryptographic Modules](/artifacts/global/fips-140-3/faq.md): Answers to common FIPS 140-3 questions about scope, CMVP validation, algorithm certificates, module boundaries, approved mode, and validation evidence.
- [FIPS 140-3 Module Boundaries FAQ](/artifacts/global/fips-140-3/faq/module-boundaries.md): Understand how FIPS 140-3 module boundaries affect cryptographic module scope, interfaces, software and firmware components, and bound or embedded validated modules.
- [FIPS 140-3 Module Boundary Selector Workflow](/artifacts/global/fips-140-3/module-boundary-selector-workflow.md): A FIPS 140-3 workflow for selecting a cryptographic module boundary, separating embedded and bound modules, and collecting CMVP validation evidence.
- [FIPS 140-3 operational environments FAQ](/artifacts/global/fips-140-3/faq/operational-environments.md): Learn what a FIPS 140-3 operational environment means for software, firmware, and hybrid cryptographic modules, and what evidence to check before relying on a validation claim.
- [FIPS 140-3 security levels: how to choose and evidence them](/artifacts/global/fips-140-3/faq/security-levels.md): A practical FAQ on FIPS 140-3 security levels, module scope, CMVP evidence, bound or embedded modules, and common claim mistakes.
- [FIPS 140-3 Security Policy Template](/artifacts/global/fips-140-3/security-policy-template.md): Build a FIPS 140-3 module Security Policy with sections for boundary, roles, services, approved algorithms, SSP handling, self-tests, and CMVP evidence.
- [FIPS 140-3 Validation Checklist](/artifacts/global/fips-140-3/fips-140-3-validation-checklist.md): Checklist for preparing a cryptographic module for FIPS 140-3 validation: boundary, levels, services, approved algorithms, entropy, tests, security policy, and change evidence.
- [FIPS 140-3 Validation Maintenance](/artifacts/global/fips-140-3/validation-maintenance.md): Maintain FIPS 140-3 validation claims by checking module identity, certificate status, boundary changes, operational environments, and CAVP evidence.
- [FIPS 140-3 Validation Maintenance Change Workflow](/artifacts/global/fips-140-3/validation-maintenance-change-impact-workflow.md): A FIPS 140-3 workflow for triaging module changes against CMVP validation scope, Security Policy evidence, CAVP certificates, software loading, and CVE records.
- [FIPS 140-3 Vendor Affirmation FAQ](/artifacts/global/fips-140-3/faq/vendor-affirmation.md): When vendor affirmation can support a FIPS 140-3 module claim, what it does not supersede, and which Security Policy, CAVP, CSTL, and test-report evidence to keep.
- [FIPS 140-3 vs ISO/IEC 19790 and ISO/IEC 24759](/artifacts/global/fips-140-3/fips-140-3-vs-iso-19790.md): Compare FIPS 140-3 with ISO/IEC 19790 and ISO/IEC 24759 for cryptographic module validation scope, evidence, testing, and procurement claims.
- [FIPS 140-3: CMVP Lifecycle Timeline](/artifacts/global/fips-140-3/cmvp-lifecycle-timeline.md): Practical FIPS 140-3 guidance for CMVP Lifecycle Timeline: scope, controls, evidence, source-linked decisions, and implementation checkpoints.
- [FIPS 140-3: FIPS 140-2 vs FIPS 140-3](/artifacts/global/fips-140-3/fips-140-2-vs-fips-140-3.md): Compare FIPS 140-2 legacy references with FIPS 140-3 requirements, ISO/IEC 19790 alignment, CMVP testing evidence, and guidance mappings.
- [FIPS 140-3: Module Boundary and Service Mapping](/artifacts/global/fips-140-3/module-boundary-and-service-mapping.md): Map a FIPS 140-3 cryptographic module boundary to services, approved algorithms, operational environments, and CMVP validation evidence.
- [FIPS 140-3: Operational Environment](/artifacts/global/fips-140-3/operational-environment.md): FIPS 140-3 operational environment guidance for software, firmware, hybrid, CAVP certificate, EVM, and PAA/PAI validation claims.
- [FIPS 140-3: Security Levels Explained](/artifacts/global/fips-140-3/security-levels-explained.md): Explain FIPS 140-3 Security Levels 1 through 4, what they cover, and how to document level claims for cryptographic module validation.
- [FIPS 140-3: step-by-step workflow for mapping algorithm certificates to CMVP modules](/artifacts/global/fips-140-3/algorithm-certificate-mapping-workflow.md): Map CAVP algorithm certificates to a FIPS 140-3 module by matching implementation identity, operational environment, module services, and security policy evidence.
- [How should teams handle approved mode under FIPS 140-3?](/artifacts/global/fips-140-3/faq/approved-mode.md): Answer the FIPS 140-3 approved-mode question with service-level indicators, Security Policy evidence, and limits on non-approved functions.


---

[Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us)

(c) 2026 Sorena AB (559573-7338). All rights reserved.

Source: https://www.sorena.io/artifacts/global/fips-140-3/module-boundary-selector