Cryptographic Key Management Policy Template: Key States, Custody and Compromise Recovery

Encryption is only as strong as the custody of its keys, and most key failures come from keys that live too long, sit on a developer's laptop, survive the person who created them, or cannot be replaced quickly when compromised. This template sets the rules for the whole key lifecycle: key classes and their protection, the key states defined in NIST SP 800-57 Part 1 Rev. 5, generation, storage and distribution, cryptoperiods, separation of duties and dual control, backup and archive, destruction, and a key compromise recovery plan. It sits beneath an encryption policy, which decides when encryption is required and which algorithms are approved; see the Encryption Policy Template. It is written for CISOs, PKI and cryptography leads, platform teams and key custodians.

How to use this template

• Replace text in square brackets, such as [Organisation], [Cryptography lead] and [2 years], with your own terms and values. Bracketed values are suggested defaults, not external requirements.
• "Must" indicates a mandatory requirement. "Should" indicates a recommended practice where a documented exception may be justified.
• Algorithms and key sizes are not repeated here. Reference your approved algorithms standard, usually maintained under the encryption policy.
• Terms such as key states, cryptoperiod, split knowledge and originator usage period follow NIST SP 800-57 Part 1 Rev. 5 (final, May 2020).

1. Purpose

This policy sets the requirements for managing cryptographic keys and related keying material at [Organisation] across their full lifecycle, so that every key is generated securely, protected in proportion to what it protects, used only for its authorised purpose by authorised identities, replaced before its cryptoperiod ends, recoverable where availability requires it, and destroyed when no longer needed. It also sets how [Organisation] responds when a key is suspected to be compromised.

2. Scope

This policy applies to all cryptographic keys used by or on behalf of [Organisation], wherever they are held, including:

• Symmetric data encryption keys, key encryption (wrapping) keys and message authentication keys.
• Private keys for digital signatures, token and assertion signing (for example JWT, SAML and OIDC signing keys), code and firmware signing, TLS and mutual TLS, SSH host and user authentication, and certificate authorities.
• Key agreement and key transport keys, and master keys in hardware security modules (HSMs) and key management services (KMS).
• Keys held by cloud providers, SaaS providers and other third parties on [Organisation]'s behalf.

Passwords, API keys and other shared secrets are governed by [the secrets management standard]; where such a secret is used as a cryptographic key (for example an HMAC key), this policy also applies. See the Secrets Management Guide.

3. Roles and responsibilities

4. Policy statements

4.1 Key classes

Every key must be assigned a class when it is requested. The class sets its minimum protection.

4.2 Key states and permitted operations

Each key must be in exactly one of the six states defined in section 7 of NIST SP 800-57 Part 1 Rev. 5, and its state must be recorded in the inventory.

4.3 Generation

1. Keys must be generated by an approved cryptographic module using an approved random bit generator, inside the HSM or KMS that will hold them, or on the device that will use them.
2. Class A keys must be generated in a documented ceremony with at least [two] custodians and [one] independent witness, with the script, attendees and outcomes signed and retained.

4.4 Storage, distribution and use

1. Private and secret keys must never be stored in plaintext outside a cryptographic module, and never in source code, container images, configuration files, tickets, chat, email or personal password vaults.
2. Where keys must leave a module (for example to distribute a wrapped data key), they must be wrapped by a key of equal or greater strength or transported under split knowledge.
3. Each key must have a single purpose. A key used for signing must not be used for encryption, and a key for one environment (production, test) must not be used in another.
4. Applications must access keys at runtime through [approved KMS or HSM APIs] using a workload identity, not a static credential. The identity's permission must be limited to the operations it needs (for example decrypt only).

4.5 Cryptoperiods and rotation

A cryptoperiod is the time a key is authorised for use. NIST SP 800-57 Part 1 Rev. 5 separates the originator usage period (when protection may be applied) from the recipient usage period (when protected data may still be processed), and gives suggested cryptoperiods by key type in section 5.3.6. Set values with those suggestions and your risk assessment.

1. Rotation must be automated where the platform supports it. Keys approaching the end of their originator usage period must alert the owner at least [30 days] before.
2. A key must be rotated early when a person who had access to its plaintext or to its administrative credentials leaves or changes role, when a system it protects is compromised, or when its algorithm or size is no longer approved.

4.6 Separation of duties, dual control and split knowledge

1. Permission to administer a key (create, change policy, disable, delete, export) must be held by different identities from permission to use it (encrypt, decrypt, sign) and from access to the protected data store.
2. Operations on Class A keys and deletion or policy changes on Class B keys must require two authorised people (dual control). No single person may hold enough key shares or credentials to reconstruct a Class A key (split knowledge, for example [3 of 5] shares).
3. Custodians must be employees in [named roles], recorded in the key inventory, with a deputy for each share. Shares and smart cards must be stored in [separate tamper-evident safes].

4.7 Backup, archive and recovery

1. Keys whose loss would make data unrecoverable (key encryption keys, data encryption keys for retained data, CA keys) must be backed up in wrapped form to [a separate HSM partition or offline media in a separate location] and the backup tested by restore at least [annually].
2. Signing keys and authentication private keys should not be backed up unless their loss cannot be handled by issuing a new key. Prefer re-issuance.
3. Deactivated keys needed to decrypt archived data must be archived under the same protection as when active, for the retention period of that data.
4. Key backups must not be stored alongside the data backups they protect.

4.8 Key compromise recovery plan

[Organisation] must maintain a key compromise recovery plan, approved by the [CISO] and tested at least [annually]. It must cover:

1. Who must be notified and how, including key owners, relying parties, customers, and certificate authorities or providers.
2. How the compromised key is moved to the Compromised state and how relying systems are told to stop trusting it (revocation, removal from published key sets, KMS disable).
3. How a replacement key is generated and distributed, and how affected data is re-encrypted or re-signed.
4. Target times: [24 hours] for Class A and token signing keys, [72 hours] for Class B, [5 working days] for Class C.
5. How tokens, sessions and artefacts signed with the compromised key are found and invalidated.

Suspected compromise must be reported to [security operations] immediately and handled under the incident response plan. For signing certificates, see the Compromised Code Signing Certificate Playbook.

4.9 Destruction

1. Keys must be destroyed when their recipient usage period ends and no archive requirement applies, using the module's zeroisation or deletion function. KMS scheduled deletion must use a waiting period of at least [7 to 30 days] with alerting.
2. Destruction of Class A and Class B keys requires dual control and must be recorded in the inventory, including key identifier, date and approvers.

4.10 Personnel changes

1. When a custodian, key administrator or any person with access to plaintext keys leaves or changes role, [Organisation] must, within [5 working days], revoke their credentials, reassign their shares, and rotate every key they could have copied.
2. Key owners must be reassigned before the owner's departure; keys with no owner must be disabled after [10 working days].

5. Exceptions

1. Exceptions (for example a legacy system that cannot rotate keys, or a key held outside an HSM) must be recorded in [the exception register] with compensating controls and an expiry no later than [12 months].
2. Exceptions for Class A and Class B keys are approved by [CISO]; others by [Cryptography lead].

6. Compliance and monitoring

1. All HSM and KMS administrative events and key use must be logged and forwarded to [the SIEM], with logs protected from alteration. Alerts must cover: key deletion or scheduled deletion, disable, policy and grant changes, export attempts, use by unexpected identities, unusual decrypt or sign volumes, and use of Deactivated or Compromised keys.
2. The [Cryptography lead] must reconcile the key inventory against KMS, HSM and certificate sources at least [quarterly] and report:
   • Percentage of keys with a named owner and class.
   • Keys past their originator usage period still Active.
   • Class A and B keys without dual control enforced.
   • Leaver-triggered rotations completed within target.
   • Key compromise recovery plan test date and result.
3. Compliance is subject to internal audit at least [annually].

7. Review and approval

Implementation guidance

Rollout

1. Inventory and classify: export keys from every KMS, HSM and CA, scan code repositories and hosts for private keys, and assign a class and owner. See the Cryptographic Inventory and CBOM Guide.
2. Fix custody of Class A keys first: move token signing and code signing keys off developer machines and into HSM-backed services. Run old and new keys in parallel during rollover so relying systems are not broken.
3. Test the compromise plan: rotate one token signing key on a schedule as a rehearsal and time it. A key that cannot be rotated in a rehearsal will not be rotated in an incident.

Failure patterns this policy is written to prevent

• Keys surviving the leaver: in the Coupang breach, a former developer kept a token signing key that was never rotated after he left, signing keys were held on developer computers, and reported validity periods ran to years. Sections 4.4, 4.5 and 4.10 address each point.
• Old keys still trusted: in the Storm-0558 key breach, an old consumer signing key was used to forge tokens. Section 4.2 requires deactivation and removal from trusted sets.
• Keys stored with the data: see the GoTo breach, where encrypted backups were taken with a key for part of them. Section 4.7 keeps key backups apart.

Framework mapping

Sources

• NIST: SP 800-57 Part 1 Rev. 5, Recommendation for Key Management: Part 1, General
• NIST: SP 800-53 Rev. 5, Security and Privacy Controls
• NIST: Cybersecurity Framework 2.0

Related NHI Mgmt Group resources: Cryptographic Key Management Guide · Encryption Policy Template · HSM Deployment and Operations Guide · NIST SP 800-57 and 800-131A Cryptographic Key Management and Algorithm Transition Guide · Cryptographic Key Ceremony Template