---
title: "FIPS 140-3 Security Policy Template"
canonical_url: "https://www.sorena.io/artifacts/global/fips-140-3/security-policy-template"
source_url: "https://www.sorena.io/artifacts/global/fips-140-3/security-policy-template"
author: "Sorena AI"
description: "Build a FIPS 140-3 module Security Policy with sections for boundary, roles, services, approved algorithms, SSP handling, self-tests, and CMVP evidence."
published_at: "2026-05-09"
updated_at: "2026-05-09"
keywords:
  - "FIPS 140-3 Security Policy"
  - "CMVP security policy"
  - "cryptographic module"
  - "approved services"
  - "CAVP certificates"
  - "FIPS 140-3"
  - "Security Policy"
  - "CMVP"
  - "cryptographic modules"
---
**[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 Security Policy Template

Build a FIPS 140-3 module Security Policy with sections for boundary, roles, services, approved algorithms, SSP handling, self-tests, and CMVP evidence.

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

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.

## 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](https://doi.org/10.6028/NIST.FIPS.140-3?ref=sorena.io) - 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](https://csrc.nist.gov/csrc/media/Projects/cryptographic-module-validation-program/documents/FIPS%20140-3/FIPS%20140-3%20IG.pdf?ref=sorena.io) - Supports keeping Security Policy statements aligned with validation evidence, implementation guidance, caveats, and CMVP submission expectations.

## 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](https://doi.org/10.6028/NIST.FIPS.140-3?ref=sorena.io) - Grounds the boundary, interface, role, service, authentication, software or firmware, and operating-environment sections of the template.
- [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 documenting module-specific evidence, including cases where an implementation under test relies on an existing validated module.

## 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](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 approved-service indicator and Security Policy table guidance for approved and non-approved services.
- [NIST FIPS 140-3](https://doi.org/10.6028/NIST.FIPS.140-3?ref=sorena.io) - Supports tying service claims to FIPS 140-3 requirements for roles, services, authentication, approved security functions, and module interfaces.
- [NIST CAVP validation search](https://csrc.nist.gov/projects/cryptographic-algorithm-validation-program/validation-search?ref=sorena.io) - Use this public search page to verify algorithm certificates referenced in approved-service rows.

## 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](https://doi.org/10.6028/NIST.FIPS.140-3?ref=sorena.io) - Supports Security Policy sections for approved security functions, SSP management, self-tests, and lifecycle assurance.
- [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 documenting entropy caveats, approved-service indicators, key establishment annotations, algorithm restrictions, and self-test details in the Security Policy.
- [NIST CAVP validation search](https://csrc.nist.gov/projects/cryptographic-algorithm-validation-program/validation-search?ref=sorena.io) - Use this source to check certificate numbers for approved algorithms named in the Security Policy.

## 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](https://doi.org/10.6028/NIST.FIPS.140-3?ref=sorena.io) - Supports reviewing whether module security levels and services are appropriate for the application and operational environment.
- [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 checklist items for service indicators, Security Policy caveats, algorithm evidence, and change-sensitive validation claims.

*Recommended next step*

*Placement: after practical guidance*

## Operationalize FIPS 140-3 Security Policy evidence

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

- [Open Assessment Autopilot for FIPS 140-3](/solutions/assessment.md): Convert Security Policy sections into accountable evidence requests, validation tasks, and change-review checkpoints.
- [Research FIPS 140-3 source questions](/solutions/research-copilot.md): Use cited NIST and CMVP materials to resolve boundary, approved-service, algorithm, entropy, and Security Policy questions.
- [Talk through FIPS 140-3 Security Policy evidence](/contact.md): Review module scope, service tables, certificate evidence, and the next validation actions with Sorena.

## Primary sources

- [NIST FIPS 140-3](https://doi.org/10.6028/NIST.FIPS.140-3?ref=sorena.io) - Primary FIPS source for cryptographic module scope, security levels, approved security functions, and the requirement areas a Security Policy must describe.
  - Quote: "Security Requirements for Cryptographic Modules"
- [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 source for approved and non-approved service treatment, approved service indicators, Security Policy caveats, algorithm evidence, and validation guidance.
  - Quote: "Implementation Guidance for FIPS PUB 140-3"
- [NIST CAVP validation search](https://csrc.nist.gov/projects/cryptographic-algorithm-validation-program/validation-search?ref=sorena.io) - Public source for checking algorithm validation certificates cited in Security Policy service and algorithm tables.
  - Quote: "Validation Search"

## 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 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: Module Boundary Selector](/artifacts/global/fips-140-3/module-boundary-selector.md): Select and document a FIPS 140-3 cryptographic module boundary across hardware, software, firmware, operational environment, services, and 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/security-policy-template