TemplateGLOBALFIPS 140-3

FIPS 140-3 Security Policy Template

A practical structure for writing a FIPS 140-3 cryptographic module Security Policy that matches the module boundary, services, approved-mode evidence, and CMVP validation record.

Use it as validation planning and drafting guidance alongside FIPS 140-3, current CMVP implementation guidance, and public certificate evidence.

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

A FIPS 140-3 Security Policy should let a reader understand exactly which cryptographic module was validated, what is inside its boundary, which roles and services are available, when approved security services are in use, and which evidence supports the certificate claim. This template focuses on those public-facing sections and the evidence needed to keep the Security Policy aligned with CMVP validation materials.

Section 1

Template front matter and module identity

Start the Security Policy with identifiers that can be compared directly with the CMVP validation record: module name, vendor, hardware, software or firmware version, module type, validation status, certificate number when available, claimed security levels, and the exact document 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.

Include a document control table with Security Policy version, module version, release date, owner, review status, and change summary.
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.

Section 2

Module boundary, interfaces, roles, and operational environment

The next section should make the validation boundary visible. Include a boundary diagram or table that names included components, excluded components, physical or logical interfaces, ports, data paths, control inputs, status outputs, power interfaces, and any trusted operational environment assumptions.

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.

Boundary table fields: component, inside or outside boundary, version or part number, interface used, and Security Policy 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.

Section 3

Approved services, non-approved services, and indicators

Use a service table as the core of the Security Policy. Each externally invoked cryptographic service should show the role that can call it, the algorithm or process used, key or SSP access, whether it is approved, allowed with no security claimed, non-security, or non-approved, and how the operator can identify an approved security service.

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.

Approved service row fields: role, service, API or command, algorithm or security function, CAVP certificate or evidence, key or SSP access, approved 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 Security Policy 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

Use this public search page to verify algorithm certificates referenced in approved-service rows.

Section 4

Algorithms, SSP management, entropy, and self-tests

Add separate evidence tables for approved algorithms, sensitive security parameters, entropy, DRBG use, self-tests, and error states. These tables keep the Security Policy from becoming a broad assurance narrative and make it possible to compare the public policy with the validation test report and certificate caveats.

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.

Algorithm table fields: service, algorithm, mode or parameter set, approved function source, CAVP certificate, implementation version, operational environment, and usage restriction.
SSP table fields: SSP name, generation or establishment method, storage location, input and output path, zeroisation method, service access, and approved or non-approved service separation.
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

Use this source to check certificate numbers for approved algorithms named in the Security Policy.

Section 5

Security Policy review checklist

Before the Security Policy is submitted, published, or reused in procurement evidence, run a consistency review against the module boundary, service tables, algorithm certificates, operational environment, validation test report inputs, and CMVP certificate record. The review should narrow claims when evidence only supports a subset of products, versions, environments, or services.

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.

Check that the module name, version, vendor, certificate number, boundary, and security levels match the 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 Security Policy 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