A cloud key management service (KMS) rarely fails loudly: keys lose their owners, rotation is switched on for some keys and not others, key policies collect cross-account principals, and unused keys sit enabled for years. This page is a recurring health check for the KMS estate you already run, across every cloud account, subscription or project that holds customer-managed keys. It gives you 12 metrics with formulas, data source types and red, amber and green thresholds, a sign-off cadence, a findings log and a remediation map. It is written for cloud security engineers, platform teams, cryptography owners and internal audit.
What this health check covers
The health check measures the key management service as a platform: whether every key is known and owned, whether key lifecycles follow policy, whether key administration and key use are kept apart, and whether key activity is visible. It does not explain how to design key hierarchies or integrate applications; for that, see the Cryptographic Key Management Guide and the Envelope Encryption and KMS Integration Patterns Guide. For rolling out a KMS in the first place, use the Cloud key management service (KMS) rollout playbook.
The figures support NIST SP 800-53 Rev. 5 SC-12 Cryptographic Key Establishment and Management, SC-28 Protection of Information at Rest, AC-6 Least Privilege and AU-6 Audit Record Review, Analysis, and Reporting, and NIST CSF 2.0 PR.DS-01 (data at rest protected). Key states and cryptoperiods follow the concepts in NIST SP 800-57 Part 1 Rev. 5, Recommendation for Key Management. The check covers keys held in the provider's KMS, including keys backed by a hardware security module or by imported or external key material; dedicated on-premises HSM operations are covered in the HSM Deployment and Operations Guide.
Key takeaways
- Every key needs an owner and a purpose. An unowned key cannot be rotated, retired or defended in an incident.
- Measure separation, not just permissions. An identity that can both change a key policy and decrypt with the key defeats the point of the service.
- Unused enabled keys are risk without value. Disable them first, watch for breakage, then schedule deletion with a waiting period.
- Cross-account access drifts fastest. Key policies and grants for other accounts or external principals need their own metric.
- Key activity logs are the only evidence of misuse. If decrypt events are not reaching the SIEM, a compromise of a workload identity is invisible.
How to use this template
Copy the tables into your tracker and replace text in square brackets, such as [Organisation], [Cryptography owner] and [Cloud platform lead], with your own terms. Define the scope at the first run: which providers, accounts, subscriptions, projects and regions, and whether provider-managed default keys are in or out (most organisations exclude them, because the customer cannot change their policy or rotation). Keep the scope stable between runs. Pull figures from organisation-wide inventory or configuration exports rather than account by account, and store each export with its date and the identity that ran it. All thresholds are NHI Mgmt Group recommended thresholds; adjust to your risk appetite and record the values you use.
Cadence and sign-off
| Review | Frequency | Owner | Approver | Evidence kept |
|---|---|---|---|---|
| Core metrics run (KMS-01 to KMS-11) | Quarterly | [Cloud platform lead] | [Cryptography owner] | Key inventory export, key policy and grant exports, metric workbook |
| Key owner attestation | Quarterly | Application or data owners | [Cryptography owner] | Signed list of keys each owner confirms as needed |
| Cross-account and external access review | Quarterly | [Cloud security engineer] | [Cryptography owner] | List of external principals per key with business justification |
| Independent re-performance | Quarterly | [Internal audit] or [Security operations] | [Head of cloud security] | Re-run of at least two metrics from raw exports |
| Full annual run, adds KMS-12 and key recovery evidence | Annual | [Cryptography owner] | [CISO] | Key compromise exercise record, imported key material backups and expiry dates |
| Event-driven run | After a new account or region, a provider change, or a suspected key or workload compromise | [Cloud platform lead] | [Cryptography owner] | Before and after figures |
Metrics
NHI Mgmt Group recommended thresholds; adjust to your risk appetite. "Customer-managed key" means a key whose policy and lifecycle the organisation controls. "Production key" means a key protecting production data or signing production artefacts.
| ID | Metric | Formula (numerator / denominator) | Data source type | Green | Amber | Red |
|---|---|---|---|---|---|---|
| KMS-01 | Key ownership coverage | Enabled customer-managed keys with an owner and purpose tag or label / enabled customer-managed keys | Organisation-wide key inventory export | 98% or above | 90% to below 98% | Below 90% |
| KMS-02 | Automatic rotation coverage | Symmetric customer-managed keys with automatic rotation on / symmetric customer-managed keys that support it | Key configuration export | 95% or above | 80% to below 95% | Below 80% |
| KMS-03 | Keys past cryptoperiod | Keys whose current key version or material is older than the policy cryptoperiod / keys with a cryptoperiod defined | Key version creation dates against the key management policy | 0% | Above 0% to 5%, none production | Above 5%, or any production key |
| KMS-04 | Admin and use separation | Identities holding both key administration rights and decrypt or sign rights on the same production key / identities with any rights on production keys | Key policy and IAM role binding exports | 0% | Above 0% to 2%, each with an approved exception | Above 2%, or any without an exception |
| KMS-05 | Wildcard or broad principals | Production keys whose policy or role bindings grant use to all principals, all accounts, or an entire organisation without a condition / production keys | Key policy export, policy analyser findings | 0 | 1 to 2 with an approved exception | 3 or more, or any without an exception |
| KMS-06 | Cross-account access justified | Keys with cross-account or external principals that have a recorded justification and owner / keys with cross-account or external principals | Key policy and grant exports, exception register | 100% | 90% to below 100% | Below 90% |
| KMS-07 | Stale grants and bindings | Grants or role bindings on keys whose grantee has not used the key in 90 days or no longer exists / all grants and bindings on keys | Grant and binding exports joined to key activity logs | Below 5% | 5% to 15% | Above 15% |
| KMS-08 | Unused enabled keys | Enabled customer-managed keys with no cryptographic operation in 90 days / enabled customer-managed keys | Key activity logs or usage metrics against key inventory | Below 5% | 5% to 15% | Above 15% |
| KMS-09 | Deletion safeguards | Keys scheduled for deletion with the policy minimum waiting period and an owner approval / keys scheduled for deletion in the period | Key state export, change records | 100% | Non-production keys without approval, waiting period met | Any below the minimum waiting period, or a production key with no approval |
| KMS-10 | Key activity logging coverage | Accounts, subscriptions or projects whose key management events reach the SIEM / accounts, subscriptions or projects holding customer-managed keys | Cloud audit log configuration, SIEM ingestion metrics | 100%, no gap over 1 hour | 100%, longest gap over 1 hour up to 24 hours | Below 100%, or a gap over 24 hours |
| KMS-11 | Key policy change review | Key policy or binding changes on production keys reviewed by someone other than the requester / such changes in the period | Key management audit events, change records | 100% | 90% to below 100% | Below 90% |
| KMS-12 | Imported and external key readiness | Keys with imported or external material that have a tested backup of the material and an expiry date at least 90 days away / keys with imported or external material | Key configuration export, key custody records | 100% | 90% to below 100% | Below 90%, or any production key expiring within 30 days |
KMS-01 to KMS-03 show whether keys are known and on lifecycle, KMS-04 to KMS-07 whether access is controlled, KMS-08 and KMS-09 whether retirement is safe, and KMS-10 to KMS-12 whether misuse would be seen and whether you could recover. Calculation notes:
- Rotation (KMS-02): asymmetric keys and keys with imported material usually cannot rotate automatically in cloud KMS services; exclude them from the denominator and cover them in KMS-03 and KMS-12 instead.
- Cryptoperiod (KMS-03): take the cryptoperiod from your own key management policy for each key type, informed by NIST SP 800-57 Part 1. Do not assume a single value for every key.
- Separation (KMS-04): include inherited rights from folder, organisation or account-level roles, not only rights on the key itself. Inherited administrator roles are the usual source of overlap.
- Usage (KMS-07, KMS-08): 90 days is the suggested window. Keys used only for annual jobs or disaster recovery belong on an allowlist with an owner, not in the numerator.
- Workload identities: most decrypt rights are held by service accounts, roles and managed identities rather than people. Join KMS-04 and KMS-07 results with the NHI inventory so each workload grantee has an owner; see the API Key Management Guide for the wider credential lifecycle.
How to collect the data
| Data source type | Used for | What to export |
|---|---|---|
| Organisation-wide cloud asset or key inventory | KMS-01, KMS-02, KMS-08, KMS-12 | Key ID, account or project, region, state, key type, origin of material, rotation setting, tags or labels, creation date |
| Key version or material history | KMS-03 | Current version creation date per key, rotation history |
| Key policies and IAM role binding exports, including inherited bindings | KMS-04, KMS-05, KMS-06 | Principal, permission set, condition, scope at which it is granted |
| Key grant exports | KMS-06, KMS-07 | Grantee, operations, constraints, creation date |
| Cloud audit logs for key management and cryptographic operations | KMS-07, KMS-08, KMS-10, KMS-11 | Decrypt, encrypt, sign, policy change, disable and schedule-deletion events with caller identity |
| Policy or access analyser findings | KMS-05, KMS-06 | Keys reachable from outside the organisation or by broad principals |
| SIEM ingestion metrics | KMS-10 | Events received per account or project per hour, and gaps |
| Change records and exception register | KMS-04 to KMS-06, KMS-09, KMS-11 | Approvals, justifications, expiry of exceptions |
| Key custody records | KMS-12 | Where imported material is backed up, who holds it, last test date |
Many organisations do not log every cryptographic operation because of volume. If decrypt events are sampled or filtered, record that in the evidence and treat KMS-07 and KMS-08 as estimates; do not report them as exact.
Red flags that need action now
- A production key whose policy allows use by all principals or all accounts without a condition.
- An identity outside the platform team that can both change a production key policy and decrypt with the key.
- A key scheduled for deletion without owner approval, or with the waiting period set below policy.
- Imported or external key material for a production key with no tested backup, or expiring within 30 days.
- An account or project holding customer-managed keys whose key events do not reach the SIEM.
- A sudden rise in decrypt calls from one identity, or decrypt calls from an unexpected network location or account.
- A key policy change on a production key with no change record.
- A disabled key that production systems still call, causing failed decrypts.
An unexplained decrypt spike or an unapproved policy change should be handled as a possible compromise; follow the Encryption Key Compromise Playbook before treating it as hygiene.
Findings log
One row per red or amber result; carry open rows forward. Findings accepted as risks go to the Risk Register Template.
| ID | Finding | Metric | Severity | Owner | Due date | Status |
|---|---|---|---|---|---|---|
| HC-KMS-01 | [Four production keys grant decrypt to a partner account with no recorded justification] | KMS-06 | [High] | [Cloud security engineer] | [date] | [Open] |
| HC-KMS-02 | [Organisation-level admin role gives two engineers key admin and decrypt on all production keys] | KMS-04 | [High] | [Cloud platform lead] | [date] | [Open] |
| HC-KMS-03 | [18% of enabled keys unused for 90 days, mostly in retired test projects] | KMS-08 | [Medium] | [Cryptography owner] | [date] | [Open] |
| HC-KMS-04 | [finding] | [metric ID] | [severity] | [owner] | [date] | [status] |
Suggested severity: High for red results on production keys or on logging, Medium for other red results, Low for amber.
Remediation map
| Finding type | Likely cause | Where to fix it |
|---|---|---|
| Unowned keys, rotation gaps, keys past cryptoperiod (KMS-01 to KMS-03) | Keys created by pipelines with no tagging rule, no written cryptoperiods | Cryptographic Key Management Guide |
| Admin and use overlap, broad principals (KMS-04, KMS-05) | Inherited admin roles, copied policy templates | Envelope Encryption and KMS Integration Patterns Guide and Cloud key management service (KMS) rollout playbook |
| Cross-account and external access (KMS-06, KMS-07) | Partner integrations and migrations never cleaned up | BYOK, HYOK and External Key Management Guide |
| Unused keys and unsafe deletion (KMS-08, KMS-09) | No retirement process | Cryptographic Key Management Guide |
| Logging gaps and unreviewed policy changes (KMS-10, KMS-11) | New accounts outside the logging baseline | Cloud key management service (KMS) rollout playbook |
| Imported and external key readiness (KMS-12) | Material imported once and never re-tested | BYOK, HYOK and External Key Management Guide and Encryption Key Compromise Playbook |
Related guides
- Cryptographic Key Management Guide: the discipline this check measures.
- Data Security Maturity Model: where key management sits in the wider data protection programme.
- Encryption and Key Management Requirements Map: which regulations and standards ask for these controls.
- Encryption Key Compromise Playbook: response when a red flag turns out to be real.
- HSM and Key Management Buyer's Guide: if repeated results point to a gap in the service itself.
References
- 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 (SC-12, SC-28, AC-6, AU-6)
- NIST: Cybersecurity Framework 2.0 (PR.DS-01)
- CIS: Critical Security Controls v8.1
Related NHI Mgmt Group resources: Cryptographic Key Management Guide · API Key Management Guide · Envelope Encryption and KMS Integration Patterns Guide · Encryption Key Compromise Playbook