Cloud key management service (KMS) maturity model: five levels from ad hoc to optimised

Most organisations use a cloud key management service every day, yet few can say who owns each key, who can decrypt with it or how they would recover if a key policy locked everyone out. This model describes five levels of maturity, from Ad hoc to Optimised, for running a cloud key management service (KMS): the managed service that creates, stores and uses encryption and signing keys on behalf of workloads. It scores seven dimensions with indicators, self-assessment questions, evidence to request and the steps to move up a level. It is vendor-neutral and built on NIST SP 800-57, NIST SP 800-130, the OWASP Key Management Cheat Sheet and the CSA Cloud Controls Matrix. It is written for cloud platform owners, security architects, data protection leads and auditors. Key lifecycle theory is in the Cryptographic Key Management Guide, the rollout sequence is in the Cloud key management service (KMS) rollout playbook and the recurring checks are in the Cloud key management service (KMS) health check; this page tells you where you stand and what to fix next. It uses the same Ad hoc to Optimised scale as the NHI Mgmt Group NHI Governance Maturity Model.

Key takeaways

• Using a KMS is not the same as managing keys. Provider-managed default encryption puts almost every estate at Level 1 on paper and tells you nothing about ownership, access or recovery.
• Level 3 is the realistic first target: a documented key management policy, customer-managed keys for classified data, separated administrator and user roles, keys created only through code, and data-plane logging in the SIEM.
• Every KMS caller is a non-human identity. Maturity in key access is really maturity in workload identity: short-lived federated credentials, scoped grants and owners for each caller.
• Deletion and lockout are the outages that matter. A deleted key makes its data unrecoverable, so mature programmes treat scheduled deletion and key policy changes as privileged, alerted and approved events.
• Level 5 is about agility, not more keys. The top level can rotate, re-wrap, revoke and migrate keys across algorithms and providers on demand, which is what post-quantum transition will require.

The five levels

Score each dimension separately. The overall level is the lowest dimension score that applies to regulated or high-value data, because one weak dimension, usually access or recovery, decides the outcome of an incident.

The seven dimensions

1. Policy and design

NIST SP 800-57 Part 2 Rev. 1 describes the documents a key management organisation needs: a key management policy and a key management practice statement. NIST SP 800-130 adds a design framework with documentation requirements for a cryptographic key management system. For a cloud KMS this becomes a design record covering key ownership model (provider-managed, customer-managed, imported material, externally held), protection level, key granularity, where keys live, regionality and cryptoperiods.

• Level 1: no written policy; decisions sit with each team.
• Level 3: approved policy and practice statement; design record reviewed annually; data classification states which classes need customer-managed or hardware-backed keys.
• Level 5: policy expressed as code and tested in pipelines; cryptoperiods set by risk assessment and reviewed when threats or algorithms change.

2. Inventory and ownership

The OWASP Key Management Cheat Sheet asks for a map of every component that processes or stores key material and a compromise recovery plan that includes a complete inventory of keys and their uses. In a cloud estate that means every key, alias, grant and encrypted resource, across every account, subscription or project.

• Level 2: a periodic export; many keys without owner tags.
• Level 3: mandatory tags (owner team, data classification, environment, review date) enforced at creation; orphaned keys reviewed quarterly.
• Level 4: each key linked to the resources it protects, so the impact of disabling it is known before anyone touches it.
• Level 5: continuous inventory feeding a cryptographic bill of materials. See the Cryptographic Inventory and CBOM Guide.

3. Key access and separation of duties

NIST SP 800-53 AC-5 Separation of Duties applies directly: the identities that create, change policy on, rotate and schedule deletion of keys should not be the identities that encrypt and decrypt with them. Key policies and grants should name principals explicitly, never wildcards for cryptographic use.

• Level 1: broad administrator roles can both manage and use every key.
• Level 3: separate key administrator, key user, auditor and break-glass roles; human administration only through privileged elevation with MFA.
• Level 4: no standing human access to production key administration; quarterly review of every principal in every key policy.
• Level 5: access derived from data classification and workload identity attributes, with drift detected and reverted automatically.

4. Lifecycle: rotation, usage limits and destruction

NIST SP 800-57 Part 1 Rev. 5 frames cryptoperiods by key type and use. The OWASP cheat sheet summarises examples from it, such as up to two years originator usage for low-volume symmetric data encryption keys and one to three years for private signing keys, and notes usage limits such as capping AES-GCM keys with random 96-bit IVs at 2^32 encryptions. It also warns that re-wrapping data keys under a new key encryption key does not reset the data keys' own cryptoperiods.

• Level 2: automatic rotation turned on for some symmetric keys.
• Level 3: rotation set for every key type from the policy, including manual rotation plans for imported material and asymmetric keys; longest practical waiting period on scheduled deletion; disable before delete.
• Level 4: high-volume keys tracked against usage limits; destruction recorded with approval references.
• Level 5: rotation, re-wrap and re-encryption campaigns run on demand with measured completion.

5. Protection level and assurance

Cloud KMS platforms offer software-protected keys, hardware-backed keys and dedicated hardware security module partitions. The NIST Cryptographic Module Validation Program lists validated modules; FIPS 140-2 certificates move to the Historical list on 21 September 2026, after which they may be used only for existing systems, so new designs should check for FIPS 140-3 validation.

• Level 3: protection level chosen per data class and recorded; validation certificate of the module behind each level checked.
• Level 1 and 2: protection level is whatever the default was when the key was created.

At Level 4, signing and CA keys sit on dedicated hardware where policy requires it and imported or externally held keys have tested custody procedures; see the BYOK, HYOK and External Key Management Guide and the HSM Deployment and Operations Guide. At Level 5 the organisation has a plan to move quantum-vulnerable asymmetric keys, informed by NIST IR 8547, Transition to Post-Quantum Cryptography Standards, published in final form on 27 October 2026.

6. Monitoring and detection

Mature programmes log both management events (create, policy change, disable, schedule deletion, import) and data-plane events (encrypt, decrypt, generate data key, sign). Some platforms log data-plane events separately or need them turned on.

• Level 2: management events retained in the provider log only.
• Level 3: both event types in the SIEM with alerts on deletion scheduling, disablement, policy changes that add external or wildcard principals, and key import.
• Level 4: baselines of normal callers and volumes per key; alerts on a new caller, unusual region or decrypt spikes.
• Level 5: automated containment, for example revoking a grant or disabling a caller identity, with human approval for production keys.

7. Resilience and recovery

NIST SP 800-53 SC-12(1) Availability asks that information remains available if users lose their keys. The OWASP cheat sheet asks for a documented compromise recovery plan covering contacts, re-key method, revocation checking and identifying affected data.

• Level 1: nobody has tested recovery from a deleted key or locked policy.
• Level 3: break-glass role documented; backup keys never share a deletion approval path with production keys.
• Level 4: annual exercises for accidental deletion, self-lockout, region loss and suspected key misuse, with restore of backups under the current keys.
• Level 5: recovery time for each scenario measured and improving.

Evidence an assessor should request

Self-assessment questions

1. Can you produce, within an hour, a list of every customer-managed key with its owner, data classification and review date?
2. For your most sensitive data store, which identities can decrypt it today, and when was that list last reviewed?
3. Can anyone who can decrypt data also change the key policy or schedule the key for deletion?
4. Can a new production key be created outside infrastructure as code?
5. Would you be alerted within minutes if a production key were scheduled for deletion or disabled?
6. Are decrypt and generate-data-key events in your SIEM, or only management events?
7. Have you restored a backup using only the keys you intend to keep, and recovered from a locked key policy on a test key?
8. Do you know which keys are asymmetric and quantum-vulnerable, and which module validation each protection level relies on?
9. Do any workloads reach the KMS with long-lived access keys rather than federated workload identities?
10. If a key were suspected compromised, do you know which data and signatures it touched?

Mostly "no" answers to questions 1 to 5 indicate Level 1 or 2. Confident "yes" answers with evidence to all ten indicate Level 4 or 5.

Where identity fits

A KMS is an authorisation service for keys, so its weakest point is the identities allowed to call it. Workloads should authenticate with platform-issued, short-lived credentials through workload identity federation, never with static access keys stored beside the data they protect, which is exactly what MITRE ATT&CK T1552.004 Private Keys and wider credential theft target. Infrastructure pipelines that create keys should hold create and tag permissions only, not decrypt. Map every caller to an owner in the same way as any other non-human identity, and include KMS grants in NHI access reviews. See the Cross-cloud workload identity federation guide and the API Key Management Guide for the credentials that often end up wrapping or being wrapped by KMS keys.

Moving up: roadmap

Durations are NHI Mgmt Group planning estimates for a mid-sized multi-account estate, not standards. A small organisation on one cloud can usually reach Level 3 faster by standardising on one key per application and environment with hardware-backed protection and automatic rotation. A large or multi-cloud estate should decide early whether an external key manager will provide one policy and audit plane, because that choice changes the Level 4 and 5 work.

Metrics that show maturity

• Owner coverage: percentage of customer-managed keys with a valid owner and review date (Level 3 target: 100% for production).
• Separation violations: number of principals holding both key administration and decrypt rights on the same key (target: zero).
• Code-created keys: percentage of production keys created through infrastructure as code.
• Caller credential hygiene: percentage of KMS callers using federated short-lived credentials rather than static keys.
• Recovery readiness: scenarios exercised in the last 12 months out of the four in dimension 7, with recovery time for each.
• Alert latency: time from a deletion schedule or disable event to a human acknowledgement.

Framework mapping

The CSA Cloud Controls Matrix v4.1 groups key management controls in its Cryptography, Encryption and Key Management (CEK) domain, one of 17 domains. ISO/IEC 27001:2022 Annex A addresses cryptography in its technological controls; map to the exact control in your Statement of Applicability. The two ATT&CK techniques in the table describe what an attacker with KMS administration can do: destroy keys so data cannot be read, or encrypt data under keys the victim does not control.

Common failure patterns

• Counting default encryption as maturity: provider-managed keys satisfy "encrypted at rest" checkboxes but give no control over access, rotation or crypto-shredding.
• Wildcard key policies: a policy that allows any principal in an account to decrypt turns every compromised workload credential into data access.
• One role for everything: the pipeline that creates keys can also decrypt, so a pipeline compromise exposes every protected dataset.
• Untested lockout: a policy change removes the last administrator, and nobody has rehearsed the break-glass path.
• Backups under the same deletion path: an attacker or mistake that deletes production keys also removes the keys needed to restore backups.
• Rotation theatre: automatic rotation is on, but imported and asymmetric keys, which it does not cover, are never rotated.

Practitioner checklist

• Score all seven dimensions and record the evidence behind each score.
• Approve a key management policy and practice statement modelled on NIST SP 800-57 Part 2.
• Enforce owner, classification and review-date tags on every customer-managed key.
• Separate key administrator, key user, auditor and break-glass roles, and remove wildcard principals.
• Create production keys only through reviewed infrastructure as code templates.
• Turn on data-plane logging and alert on deletion scheduling, disablement, policy change and import.
• Set the longest practical deletion waiting period and require approval for production keys.
• Exercise deletion, lockout, region loss and suspected misuse at least once a year.
• Move every KMS caller to federated short-lived workload credentials.
• Start a post-quantum inventory of asymmetric keys and check module validation status.

Standards and references

• NIST: SP 800-57 Part 1 Rev. 5, Recommendation for Key Management: General
• NIST: SP 800-57 Part 2 Rev. 1, Best Practices for Key Management Organizations
• NIST: SP 800-130, A Framework for Designing Cryptographic Key Management Systems
• NIST: SP 800-53 Rev. 5
• NIST: Cryptographic Module Validation Program
• NIST: IR 8547, Transition to Post-Quantum Cryptography Standards
• OWASP: Key Management Cheat Sheet
• Cloud Security Alliance: Cloud Controls Matrix

Related NHI Mgmt Group resources: Cryptographic Key Management Guide · Cloud key management service (KMS) rollout playbook · Cloud key management service (KMS) health check · Envelope Encryption and KMS Integration Patterns Guide · Data Security Maturity Model