TemplateGLOBALFIPS 140-3

FIPS 140-3 Security Policy Template

A companion guide for preparing the narrative, diagrams, and structured module data used to produce a FIPS 140-3 CMVP Security Policy.

Use the official CMVP template and SP 800-140B Rev. 1 for submission. This page is not an official form and does not replace Web Cryptik, MIS data, or CST laboratory review.

Back to main artifact Review sources

Author

Sorena AI

Published

May 9, 2026

Updated

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

Overview

For a CMVP submission, use the current CMVP template with SP 800-140B Rev. 1, ISO/IEC 19790 Annex B, and ISO/IEC 24759 section 6.14. The vendor enters narrative and image content in the supplied Word template and provides structured Module Information Structure () data; CMVP combines those inputs, including selected CAVP information, into the final PDF. As of July 25, 2026, the official supplemental page lists template version 5.8, ModVerifyApp 4.6.3, and resource files dated July 15, 2026; recheck that page before preparing or updating a package. This page is a drafting companion for preparing accurate inputs, not an official template or substitute for the CST laboratory's submission process.

Section 1

Template front matter and module identity

Prepare the General and Cryptographic Module Specification inputs in the order required by SP 800-140B Rev. 1. Capture the module name, vendor, module type, embodiment, tested versions and components, intended purpose, overall and area-specific security levels, and the exact source version.

Keep this section narrower than a product brochure. FIPS 140-3 covers the cryptographic module and its secure design, implementation, and operation. If the commercial product includes components outside the module boundary, name them only to clarify what is excluded from the validation scope.

The vendor owns the accuracy of the module and narrative inputs, the owner controls the structured data, and the CST laboratory checks both against test evidence before submission. CMVP produces the final merged policy. Preserve the editable Word source, MIS JSON, selected CAVP capabilities, diagrams, tool and resource versions, review comments, and final published PDF as one controlled record.

Keep internal document control for source version, module version, owner, review status, and change summary, but do not present internal approval as CMVP validation.
State the module type and implementation form: hardware, software, firmware, hybrid software, or hybrid firmware.
List the overall claimed security level and any area-specific security levels without implying that the surrounding product is validated.
Add a short applicability note for federal procurement or private-sector use only when the claim is tied to the validated module, not to every deployment of the product.

Sources for this answer

NIST FIPS 140-3

Supports limiting the template to cryptographic modules, claimed security levels, and the FIPS 140-3 security requirement areas.

CMVP Implementation Guidance for FIPS 140-3

Supports keeping Security Policy statements aligned with validation evidence, implementation guidance, caveats, and CMVP submission expectations.

NIST SP 800-140B Rev. 1

Controls Security Policy content, required order, structured inputs, and formatting for CMVP submissions.

CMVP SP 800-140B supplemental information

Provides the current CMVP Security Policy template, completion instructions, MIS resources, merge process, tool versions, and dated resource files; as checked July 25, 2026, it lists template 5.8, ModVerifyApp 4.6.3, and July 15, 2026 resource files.

Section 2

Module boundary, interfaces, roles, and operational environment

Make both the cryptographic boundary and the Tested Operational Environment's Physical Perimeter (TOEPP) visible. SP 800-140B Rev. 1 requires a precise definition and, for software, firmware, hybrid, or sub-chip modules, a block diagram that shows the logical object, operating system, supporting applications, physical and logical layers, cryptographic boundary, TOEPP, and their interactions.

Then add role and authentication material. FIPS 140-3 explicitly covers cryptographic module interfaces and roles, services, and authentication. A useful therefore explains which operators or calling roles can invoke services and how those roles are authenticated where authentication is claimed.

Boundary working fields: component, inside or outside the cryptographic boundary, inside or outside the TOEPP, version or part number, interface used, and section cross-reference.
Interface table fields: interface name, FIPS interface category, direction, connected component, and data, control, status, or power purpose.
Role table fields: role name, role type, authentication method, authentication strength reference, and services authorized for the role.
Operational environment fields: operating system, processor or platform, hypervisor or container constraints, configuration requirements, and whether the environment is modifiable.

Sources for this answer

NIST FIPS 140-3

Grounds the boundary, interface, role, service, authentication, software or firmware, and operating-environment sections of the template.

CMVP Implementation Guidance for FIPS 140-3

Supports documenting module-specific evidence, including cases where an implementation under test relies on an existing validated module.

NIST SP 800-140B Rev. 1

Requires precise cryptographic-boundary and TOEPP definitions and the applicable module diagrams.

Section 3

Approved services, non-approved services, and indicators

Prepare complete service data for the . Each externally invoked service should show the authorized role, algorithm or process, key or SSP access, approved or non-approved classification, and applicable approved security service indicator. Keep services allowed in approved mode but not themselves approved security services distinct from approved security services.

CMVP implementation guidance says the must list approved and non-approved services with details and indicators where applicable. It also makes clear that a Security Policy description can explain an indicator, but the description alone is not the implemented indicator.

Approved service working fields: role, service, API or command, algorithm or security function, selected CAVP capability, key or SSP access, approved security service indicator, and error behavior.
Non-approved service row fields: service, algorithm or function, why it is not approved, whether it is available in approved mode, key or CSP separation evidence, and user guidance.
No-security-claimed row fields: function, data treated as plaintext or non-security-relevant, CMVP rationale, and warning text.
Indicator row fields: interface, returned value or status, timing, operator action, concurrency limits, and how ambiguous approved or non-approved states are prevented.

Sources for this answer

CMVP Implementation Guidance for FIPS 140-3

Grounds the approved-service indicator and Security Policy table guidance for approved and non-approved services.

NIST FIPS 140-3

Supports tying service claims to FIPS 140-3 requirements for roles, services, authentication, approved security functions, and module interfaces.

NIST CAVP validation search

This public search page helps verify algorithm certificates referenced in approved-service rows.

Section 4

Algorithms, SSP management, entropy, and self-tests

Prepare structured inputs for tested algorithms and SSPs, plus the required narrative for entropy, DRBG use, self-tests, and error states. Do not manually recreate CMVP-generated tables in the narrative source: Web Cryptik or data and selected CAVP capabilities populate much of the final .

FIPS 140-3 requires conforming modules to use approved security functions, and the CMVP guidance contains -specific expectations for items such as non-approved algorithms, entropy caveats, key agreement, key transport, and periodic self-test explanations. Where a caveat or restriction affects users, put the operational instruction in the Security Policy rather than only in internal test notes.

Tested-algorithm input fields: associated CAVP certificate, selected algorithm capability, mode or parameter set, implementation, operational environment, and usage restriction; map the resulting entry to the relevant service.
SSP input fields: SSP name and type, strength, security function and certificate, generation or establishment method, input and output method, storage area and format, persistence, related SSPs, zeroisation, and service access.
Entropy and DRBG table fields: entropy source, credited entropy, conditioning, DRBG mechanism, seeding path, health tests, ESV or ENT evidence, and certificate caveat text if applicable.
Self-test table fields: pre-operational test, conditional algorithm self-test, pairwise consistency test, periodic test where claimed, trigger, failure state, and operator-visible error handling.

Sources for this answer

NIST FIPS 140-3

Supports Security Policy sections for approved security functions, SSP management, self-tests, and lifecycle assurance.

CMVP Implementation Guidance for FIPS 140-3

Supports documenting entropy caveats, approved-service indicators, key establishment annotations, algorithm restrictions, and self-test details in the Security Policy.

NIST CAVP validation search

This source helps check certificate numbers for approved algorithms named in the Security Policy.

NIST SP 800-140B Rev. 1

Specifies the SSP information and explains how structured MIS data and selected CAVP capabilities generate Security Policy tables.

Section 5

Security Policy review checklist

Before submission, compare the Word-template narrative and images with the data, selected CAVP capabilities, module boundary, service and SSP records, operational environments, and test evidence. After CMVP generates the final policy, repeat the comparison against the published certificate record. Narrow any product claim that exceeds the listed module versions, environments, services, or caveats.

Treat the as a controlled validation artifact. Reopen it when a change affects the cryptographic boundary, module version, approved services, algorithm implementation, key management, entropy source, self-test behavior, operational environment, embedded or bound module dependency, or certificate caveat.

The review outcome should be ready for laboratory submission, blocked by an identified evidence mismatch, or returned for source correction. A clean Word document is not enough when data, CAVP selections, or the tested implementation disagree; correct the controlling source and regenerate the merged policy.

Check that module name, version, vendor, module type, embodiment, boundary, TOEPP, and security levels agree across the narrative source, data, test evidence, and final validation record.
Verify every approved service has a role, algorithm or process, CAVP or CMVP evidence, SSP access description, and implemented indicator.
Confirm non-approved and no-security-claimed functions are separated from approved services and do not share keys or CSPs in a way that undermines approved-mode claims.
Compare entropy, DRBG, key establishment, key transport, self-test, and caveat text against the latest evidence used for the module submission.
Record unresolved lab or CMVP questions as open issues; do not turn them into public claims until the evidence is settled.

Sources for this answer

NIST FIPS 140-3

Supports reviewing whether module security levels and services are appropriate for the application and operational environment.

CMVP Implementation Guidance for FIPS 140-3

Supports the checklist items for service indicators, Security Policy caveats, algorithm evidence, and change-sensitive validation claims.

Recommended next step

Operationalize FIPS 140-3 Security Policy evidence

This template helps align module boundaries, service tables, algorithm certificates, and review tasks before teams rely on a FIPS 140-3 claim.

Assessment workflow

Open Assessment Autopilot for FIPS 140-3

Convert Security Policy sections into accountable evidence requests, validation tasks, and change-review checkpoints.

Explore next step

Research workflow

Research FIPS 140-3 source questions

Use cited NIST and CMVP materials to resolve boundary, approved-service, algorithm, entropy, and Security Policy questions.

Explore next step

Talk to Sorena

Talk through FIPS 140-3 Security Policy evidence

Review module scope, service tables, certificate evidence, and the next validation actions with Sorena.

Explore next step

Primary sources

References and citations

CMVP Implementation Guidance for FIPS 140-3

csrc.nist.gov

Referenced sections

Supports the checklist items for service indicators, Security Policy caveats, algorithm evidence, and change-sensitive validation claims.

"Security Policy shall"

CMVP SP 800-140B supplemental information

csrc.nist.gov

Referenced sections

Provides the current CMVP Security Policy template, completion instructions, MIS resources, merge process, tool versions, and dated resource files; as checked July 25, 2026, it lists template 5.8, ModVerifyApp 4.6.3, and July 15, 2026 resource files.

NIST CAVP validation search

csrc.nist.gov

Referenced sections