FIPS 140-3 Security Policy Template

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 Security Policy 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 MIS 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.

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 Security Policy therefore explains which operators or calling roles can invoke services and how those roles are authenticated where authentication is claimed.

Prepare complete service data for the Security Policy. Each externally invoked service should show the authorized role, algorithm or process, key or sensitive security parameter (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 Security Policy 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.

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

FIPS 140-3 requires conforming modules to use approved security functions, and the CMVP guidance contains Security Policy-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.

Before submission, compare the Word-template narrative and images with the MIS 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 Security Policy 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 MIS data, CAVP selections, or the tested implementation disagree; correct the controlling source and regenerate the merged policy.