# Encryption and Key Management Standard

**Template version:** 1.0.0 · **Edition:** Ready to adopt · **NIST basis:** SP 800-53 Rev. 5, release 5.2.0

*Tailor this template before adoption; it is not legal advice.* Latest version: <https://kston83.github.io/nist-guide/templates/standards/encryption-and-key-management-standard/>. Dedicated to the public domain under CC0 1.0 (<https://creativecommons.org/publicdomain/zero/1.0/>): adopt and change it without attribution.

| Owner | Approved by | Version | Effective date |
| --- | --- | --- | --- |
| [Chief Information Security Officer] | [Fill in: name and title] | [Fill in: version] | [Fill in: date] |

## 1. Purpose and scope

This standard sets the minimum requirements for using cryptography and managing cryptographic keys and certificates in the systems of [Organization name]. It applies to every system in the system inventory, including cloud services, and to every use of cryptography in them: protocols, storage encryption, digital signatures, authentication and code the organization develops.

## 2. Roles

| Role | Responsibilities |
| --- | --- |
| [Chief Information Security Officer] | Owns this standard; keeps the list of approved cryptography; provides the enterprise key management and certificate services; approves exceptions |
| [Fill in: key management function, for example the security engineering team] | Runs the key management service and hardware security modules, the certificate authority and the certificate inventory; keeps the cryptographic inventory |
| Key custodians | Administer keys for a system: create, rotate, suspend and destroy them. They do not use the keys to read the information they protect |
| [System owner] | Applies this standard to the system, records its cryptographic uses and keys, and requests exceptions |

## 3. Approved cryptography

- The [Chief Information Security Officer] shall determine the cryptographic uses for the organization's systems, which include [Fill in: cryptographic uses. Typical: encryption in transit and at rest, digital signatures and authentication]. (SC-13a)
- The [System owner] shall implement the following types of cryptography for each cryptographic use: [Fill in: types of cryptography for each specified cryptographic use. Typical: NIST-approved algorithms in cryptographic modules validated under FIPS 140-3 (or FIPS 140-2 for existing systems)]. (SC-13b)
- Cryptography shall provide at least 112 bits of security strength, and shall use no algorithm, key length or mode that the table below does not approve. (SC-13b)
- Cryptographic modules shall run in their approved (validated) mode, where the module has one. (SC-13b)
- Code the organization develops shall call approved cryptographic modules, and shall not implement its own cryptographic algorithms. (SC-13b)

| Use | Approved | Not allowed |
| --- | --- | --- |
| Symmetric encryption | [Fill in: for example AES with 128-bit or 256-bit keys, in GCM, CCM, XTS (storage) or CBC mode] | [Fill in: for example DES, three-key TDEA (3DES), RC4] |
| Hashing | [Fill in: for example SHA-256, SHA-384, SHA-512, SHA-3] | [Fill in: for example MD5; SHA-1 for digital signatures] |
| Digital signatures | [Fill in: for example RSA with 3072-bit or larger keys, ECDSA on P-256 or P-384, EdDSA, ML-DSA] | [Fill in: for example RSA below 2048 bits, DSA] |
| Key establishment | [Fill in: for example ECDH on P-256 or P-384, RSA with 3072-bit or larger keys, ML-KEM] | [Fill in: for example finite-field Diffie-Hellman below 2048 bits] |
| Message authentication | [Fill in: for example HMAC with SHA-256 or stronger, CMAC, KMAC] | [Fill in: for example HMAC with keys shorter than 112 bits] |
| Password storage | [Fill in: for example a salted, iterated key derivation function such as PBKDF2 with SHA-256] | [Fill in: for example unsalted hashes, reversible encryption] |

## 4. Information in transit

- Each system shall protect the [Select one or more: confidentiality; integrity. Typical: confidentiality and integrity] of transmitted information, inside the system as well as across its boundary. (SC-8)
- Each system shall implement cryptographic mechanisms to [Select one or more: prevent unauthorized disclosure of information; detect changes to information. Typical: prevent unauthorized disclosure of information and detect changes to information] during transmission. (SC-8(1))
- Connections shall use the protocols in the table below; cleartext protocols that carry information or credentials shall be disabled. (SC-8(1))
- TLS shall end no earlier than the component that needs the information; where a load balancer or gateway ends TLS, traffic from it to the system's components shall be encrypted again. (SC-8(1))
- Clients shall validate the certificates of the services they connect to, and shall not be configured to accept any certificate. (SC-8(1))

| Connection | Approved | Not allowed |
| --- | --- | --- |
| Web, APIs and service to service | [Fill in: for example TLS 1.2 or 1.3 with approved cipher suites; TLS 1.3 supported] | [Fill in: for example SSL, TLS 1.0 and 1.1, HTTP] |
| Administration | [Fill in: for example SSH version 2, or TLS to a management console] | [Fill in: for example Telnet, rlogin] |
| File transfer | [Fill in: for example SFTP, FTPS or HTTPS] | [Fill in: for example FTP] |
| Site-to-site and remote access networks | [Fill in: for example IPsec or TLS virtual private networks, or a zero trust access service using TLS] | [Fill in: for example PPTP] |
| Database, directory and message queue connections | [Fill in: for example TLS, or LDAPS for directories] | [Fill in: for example unencrypted database or LDAP connections] |
| Email between mail servers | [Fill in: for example STARTTLS offered on every internet-facing mail server] | [Fill in: for example SSLv2, SSLv3, 3DES and RC4] |

## 5. Information at rest

- Each system shall protect the [Select one or more: confidentiality; integrity. Typical: confidentiality and integrity] of [Fill in: information at rest requiring protection. Typical: all information stored by the system, including backups]. (SC-28)
- Each system shall implement cryptographic mechanisms to prevent unauthorized disclosure and modification of [Fill in: information requiring cryptographic protection. Typical: all organizational information] at rest on [Fill in: system components or media requiring cryptographic protection. Typical: servers, databases, storage services, backups, end-user devices and removable media]. (SC-28(1))
- Encryption shall be enforced by default, through cloud policy, device management or storage configuration, so that a new store or device is encrypted without a separate step. (SC-28(1))
- Backups, snapshots, replicas and exports shall be encrypted as strongly as the store they come from. (SC-28(1))

| Store | Method | Key |
| --- | --- | --- |
| Laptops, desktops and mobile devices | [Fill in: for example full-disk encryption managed by the endpoint management service] | [Fill in: for example device keys, with recovery keys escrowed centrally] |
| Cloud storage, block volumes and managed databases | [Fill in: for example provider encryption enabled by default] | [Fill in: for example customer-managed keys in the cloud key management service for sensitive data] |
| Databases the organization runs | [Fill in: for example transparent database encryption, and field-level encryption for the most sensitive values] | [Fill in: for example keys held in the key management service, not on the database server] |
| Backups | [Fill in: for example encrypted by the backup service] | [Fill in: for example keys stored apart from the backup copies] |
| Removable media | [Fill in: for example hardware-encrypted drives, or encryption applied by the endpoint management service] | [Fill in: for example a password or key held by the user, with recovery by the service desk] |

## 6. Key management

- Each system that uses cryptography shall establish and manage its cryptographic keys in accordance with the requirements in this section for key generation, distribution, storage, access and destruction. (SC-12)
- Keys shall be generated inside approved cryptographic modules, such as the key management service or a hardware security module, using an approved random bit generator. (SC-12)
- Keys shall be distributed only by approved key establishment methods or by wrapping them with another key, never in cleartext. (SC-12)
- Keys shall be stored in the key management service, a hardware security module or another approved module, and never in source code, configuration files, container images or the same store as the information they protect. (SC-12)
- Access to each key shall be limited to the services and people that need it. People who administer a key shall not also be able to use it to read the information it protects, and every use and administrative action on a key shall be logged. (SC-12)
- Keys shall be replaced at the end of the periods in the table below, and at once when a key is suspected to be compromised or a person with access to it leaves. (SC-12)
- Keys no longer needed shall be destroyed, together with every copy, once no information that needs them is kept; the destruction shall be recorded. (SC-12)
- The key management function shall keep an inventory of keys for each system: purpose, algorithm and length, location, owner, custodians, creation date and next replacement date. (SC-12)
- The key management function shall keep a key compromise plan saying who is told, how affected keys are revoked and replaced, and how information protected by them is re-protected. (SC-12)

This paragraph applies to High systems.

- The [System owner] shall maintain the availability of information when users lose cryptographic keys, by escrowing or backing up the keys that protect stored information, such as recovery keys for full-disk encryption. (SC-12(1))

| Key type | Maximum period of use | Notes |
| --- | --- | --- |
| Symmetric data encryption keys | [Fill in: for example 2 years for applying protection] | [Fill in: for example automatic rotation in the key management service] |
| Key-wrapping (key encryption) keys | [Fill in: for example 2 years] | [Fill in: notes] |
| Private signature keys, including code signing | [Fill in: for example 1 to 3 years] | [Fill in: for example kept in a hardware security module] |
| TLS server certificates and their keys | [Fill in: for example the certificate's validity, and a new key at each renewal] | [Fill in: for example renewed automatically] |
| SSH host and user keys | [Fill in: for example 1 year for user keys; host keys when the host is rebuilt] | [Fill in: notes] |
| Secrets and API keys used by services | [Fill in: for example 90 days, or short-lived credentials issued at run time] | [Fill in: for example held in the secrets manager] |

## 7. Certificates

- Public key certificates shall be issued under [Fill in: a certificate policy for issuing public key certificates. Typical: the organization's certificate policy], or obtained from an approved service provider. (SC-17a)
- Only approved trust anchors shall be included in trust stores or certificate stores the organization manages. (SC-17b)
- The key management function shall keep an inventory of certificates in use, with their owners and expiry dates, and warn owners at least [Fill in: for example 30 days] before a certificate expires. (SC-17a)
- Certificates shall be renewed automatically where the service supports it. A certificate whose private key is compromised shall be revoked at once. (SC-17a)

## 8. Cryptographic inventory

- The [System owner] shall record in the system security plan where the system uses cryptography, the algorithm and module used for each use, and the module's validation certificate number. (SC-13b)
- The key management function shall keep an organization-wide cryptographic inventory from these records, and use it to find cryptography that must be replaced when an algorithm or module is no longer approved. (SC-13a)

### Federal systems

[FIPS 140-3](https://csrc.nist.gov/pubs/fips/140-3/final) (March 22, 2019) "is applicable to all Federal agencies that use cryptography-based security systems to protect sensitive information", and modules validated under NIST's Cryptographic Module Validation Program (CMVP) are considered to conform to it. The CMVP's [FIPS 140-3 transition page](https://csrc.nist.gov/projects/fips-140-3-transition-effort) sets the schedule for moving all FIPS 140-2 certificates to the Historical List on September 22, 2026; modules on the Historical List remain supported for existing systems, but should not be used for procurement decisions (as of September 2026).

CISA [Binding Operational Directive 18-01](https://www.cisa.gov/news-events/directives/bod-18-01-enhance-email-and-web-security), Enhance Email and Web Security (October 16, 2017), requires HTTPS-only service with HTTP Strict Transport Security for publicly accessible federal websites and web services, STARTTLS on internet-facing mail servers, and SSLv2, SSLv3, 3DES and RC4 disabled on mail servers. CISA's directive page does not mark it revoked (as of September 2026).

- Cryptography that protects sensitive information shall use modules validated by the CMVP, and new systems and new purchases shall use FIPS 140-3 validated modules. (SC-13b)
- Each publicly accessible website and web service shall provide service only through HTTPS, with HTTP Strict Transport Security. (SC-8)
- Each internet-facing mail server shall offer STARTTLS, with SSLv2, SSLv3, 3DES and RC4 disabled. (SC-8)

## 9. Exceptions

- A system that cannot meet this standard shall record the gap in its plan of action and milestones, with a planned date, and the [Chief Information Security Officer] shall approve any compensating measure. (CA-5)
- An exception shall name the system, the requirement not met, the reason, the compensating measures and an expiry date, and shall be reviewed [Fill in: for example quarterly] and at expiry. (RA-7)

## 10. Review

The [Chief Information Security Officer] reviews this standard [Fill in: for example annually], and whenever NIST approves, deprecates or disallows an algorithm, a module used by the organization loses its validation, or the system and communications protection policy changes.

| Version | Date | Change | Approved by |
| --- | --- | --- | --- |
| [Fill in: version] | [Fill in: date] | [Fill in: summary of change] | [Fill in: name and title] |