For each key, record its purpose, algorithm and size, owner, where it is stored, who and what can use it, when it was created, when it should rotate, and what depends on it. OWASP says a compromise plan needs an inventory of all keys and their use, such as where every certificate is.
Why an inventory comes first
You cannot rotate a key you did not know existed. When a key leaks, the first questions are: what did it protect, where else is it used, and what breaks if we replace it? OWASP's Key Management guidance lists an inventory of all cryptographic keys and their use within its compromise and recovery plan, and says that plan shall be documented and easy to find.
The inventory is also the base for audits. When a buyer asks how you manage keys, a current list is better evidence than a policy document.
Fields to record
| Field | Why it matters |
|---|---|
| Key id or name | Stable reference used in code and logs |
| Purpose | One key, one purpose, so you know the blast radius |
| Type and size | Spots weak or outdated choices, such as RSA below 2048 bits |
| Owner | A named team who answers for it |
| Storage location | HSM, cloud key vault, secrets manager, or other |
| Who and what can use it | Accountability and least privilege |
| Created and last rotated | Drives cryptoperiod checks |
| Planned rotation date | Prevents surprise expiry |
| Dependents | Services, data sets and partners that rely on it |
| Retention of old versions | Old backups may need old keys |
| Recovery path | What to do on loss or compromise |
Terms worth knowing
A cryptoperiod, per OWASP, is the time span during which a specific key is authorized for use. Organizations should define cryptoperiods through risk assessment following NIST SP 800-57 Part 1 Rev. 5. A data encryption key, or DEK, encrypts data, and a key encryption key, or KEK, encrypts the DEK. OWASP says the KEK should be at least as strong as the DEK and stored separately.
How to build it in a week
- Start from sources you already have: cloud key services, secrets managers, certificate lists, and configuration repositories.
- Add keys no tool knows about by searching code and config for key material and for crypto library calls.
- Assign an owner to every entry. Entries with no owner become the first cleanup list.
- Record rotation dates and set reminders well ahead of expiry.
- Mark the keys that protect customer data and review those first.
- Review the list on a schedule, and whenever a service is retired.
Keep secrets out of the inventory
The inventory describes keys. It must never contain key values. OWASP says keys should never be stored in plaintext format, and should never be committed to source code repositories. Link to the location instead.
Common gaps
- Keys created by a developer for a test that quietly went to production.
- Certificates that live on a device or appliance and are missed by tooling.
- Keys held by a vendor on your behalf, with no entry on your side.
- Old versions deleted too early, leaving backups unreadable.
Try it yourself
Open the framework mapping demo and see how a control is linked to evidence. A current key inventory is the kind of evidence a key management control points to.
Click through it at your own pace, or open it full screen.
Safeguard can generate an SBOM and scan your dependencies, so outdated cryptography libraries with known advisories show up in one inventory, and policies can gate a build on them. A free scan is at gold.safeguard.sh/scan.
Quick check
Is a spreadsheet good enough?
To start, yes, if it has owners and dates and someone reviews it. Move to tooling when the count outgrows manual upkeep.
Should the inventory include API keys and tokens?
Yes for long lived ones. OWASP lists keys, secrets and API keys together when it says none should be committed to source repositories.
Sources
Last reviewed: 19 October 2026.
