Summary
The Key Management Cheat Sheet is excellent on algorithm selection and the core key lifecycle, but it has a few gaps when read against NIST SP 800-57 Part 1 and the secret/key-management requirements in OWASP ASVS 5.0 (V13 Configuration). This issue proposes a small set of surgical, additive edits, no restructuring of the existing document, to close those gaps and keep the cheat sheet aligned with both standards.
Gap analysis
| Gap in current cheat sheet |
Source requirement |
| No concrete cryptoperiods / rotation intervals (only "as long as needed") |
NIST SP 800-57 Pt1 §5.3 (e.g., ~1–2 yr for symmetric data keys, TLS server keys ≤1 yr) |
| No documented rotation schedule tied to a threat model |
ASVS 13.1.4, 13.3.4 |
| Automated rotation (KMS / ACME) not mentioned |
NIST SP 800-57 lifecycle guidance |
| Secrets "never in source code or build artifacts" not stated explicitly |
ASVS 13.3.1 |
| Least-privilege access to key/secret material only covered generically |
ASVS 13.3.2 |
| Isolated-module framing is weak — should state crypto operations occur inside the module so key material never leaves it; high-assurance = hardware-backed (HSM) |
ASVS 13.3.3, 13.3.1 |
| Destruction language is vague — NIST calls for zeroization and a defined key-state model |
NIST SP 800-57 Pt1 §7 (key states) and §8.3.4 (destruction) |
Proposed surgical edits
-
Add a "Cryptoperiods and Rotation" subsection under Key Management Lifecycle Best Practices: cite NIST SP 800-57 cryptoperiod guidance with representative intervals, require a documented rotation schedule driven by the threat model (ASVS 13.1.4 / 13.3.4), prefer automated rotation (KMS/ACME), and require manual rotations to be logged with date, operator, and authorization.
-
Strengthen "Storage": add an explicit statement that secrets and key material must never be committed to source code or embedded in build artifacts, and should live in a secrets-management solution / key vault (ASVS 13.3.1). Cross-link the Secrets Management Cheat Sheet.
-
Add least-privilege access to key/secret assets as an explicit control under Accountability and Audit (or Storage) (ASVS 13.3.2).
-
Clarify "Cryptographic Module Topics": cryptographic operations should be performed inside an isolated security module so key material is never exposed outside it; note that high-assurance deployments (e.g., ASVS L3) require a hardware-backed module such as an HSM (ASVS 13.3.3 / 13.3.1).
-
Strengthen destruction language: reference NIST key states (pre-activation, active, suspended, deactivated, compromised, destroyed, revoked) and require zeroization when the cryptoperiod plus any retention period expires — vendor zeroize commands for HSM keys, overwriting for software keys.
-
References: add OWASP ASVS 5.0 V13 (Configuration) and confirm the NIST SP 800-57 Part 1 citation is to the current revision.
Summary
The Key Management Cheat Sheet is excellent on algorithm selection and the core key lifecycle, but it has a few gaps when read against NIST SP 800-57 Part 1 and the secret/key-management requirements in OWASP ASVS 5.0 (V13 Configuration). This issue proposes a small set of surgical, additive edits, no restructuring of the existing document, to close those gaps and keep the cheat sheet aligned with both standards.
Gap analysis
Proposed surgical edits
Add a "Cryptoperiods and Rotation" subsection under Key Management Lifecycle Best Practices: cite NIST SP 800-57 cryptoperiod guidance with representative intervals, require a documented rotation schedule driven by the threat model (ASVS 13.1.4 / 13.3.4), prefer automated rotation (KMS/ACME), and require manual rotations to be logged with date, operator, and authorization.
Strengthen "Storage": add an explicit statement that secrets and key material must never be committed to source code or embedded in build artifacts, and should live in a secrets-management solution / key vault (ASVS 13.3.1). Cross-link the Secrets Management Cheat Sheet.
Add least-privilege access to key/secret assets as an explicit control under Accountability and Audit (or Storage) (ASVS 13.3.2).
Clarify "Cryptographic Module Topics": cryptographic operations should be performed inside an isolated security module so key material is never exposed outside it; note that high-assurance deployments (e.g., ASVS L3) require a hardware-backed module such as an HSM (ASVS 13.3.3 / 13.3.1).
Strengthen destruction language: reference NIST key states (pre-activation, active, suspended, deactivated, compromised, destroyed, revoked) and require zeroization when the cryptoperiod plus any retention period expires — vendor zeroize commands for HSM keys, overwriting for software keys.
References: add OWASP ASVS 5.0 V13 (Configuration) and confirm the NIST SP 800-57 Part 1 citation is to the current revision.