ASVS 5.0 V11.1.1 (Level 2) requires a written policy for managing cryptographic keys, covering the whole key lifecycle and following a recognised standard such as NIST SP 800-57. It also requires that keys are not overshared: a shared secret should be known to no more than two parties, and a private key to one.
Why it matters
Most crypto failures in production are key handling failures. A key that lives in a wiki page, a shared vault folder and three laptops is not a secret any more. A policy forces the team to decide who owns each key, how long it lives and what happens when someone leaves.
How to implement it
Write one page per key class (signing keys, data encryption keys, TLS private keys, HMAC secrets). For each, record:
- Owner and the single system allowed to hold the private half
- Generation method and where generation happens (KMS or HSM, not a laptop)
- Rotation interval and the trigger for emergency rotation
- Storage, backup and destruction rules
- Who may use the key, and for what purpose only
Then make the policy enforceable. In a cloud KMS, give each key a narrow policy and turn on automatic rotation where the service supports it.
How to test it
Pick three keys at random from your inventory. For each, ask the owner to show the policy entry, the current access list and the last rotation date. Any key with more than one holder of the private half, or no rotation record, is a finding.
Common mistakes
- A policy that describes intent but names no owner
- One shared signing key reused across services and environments
- Copying production keys into staging for convenience
- No destruction step, so retired keys stay readable in backups
Quick check
How many parties may hold a private key under V11.1.1?
One. Shared secrets should be limited to two entities at most.
Sources
- OWASP ASVS
- NIST SP 800-57, Recommendation for Key Management
