Who should own cryptographic control in cloud sovereignty programmes?

Why This Matters for Security Teams

Cloud sovereignty programmes are not just about data location. They depend on who can create, use, rotate, and revoke keys, and whether those actions are separable across jurisdictions and internal teams. When cryptographic control is treated as a platform utility, the organisation may meet technical residency goals while still failing administrative independence, evidentiary traceability, and regulator-facing accountability. That is why identity ownership matters as much as key storage.

NHIMG’s research on non-human identity maturity shows the gap clearly: 88.5% of organisations say their NHI IAM practices lag behind or only match human IAM, while only 19.6% express strong confidence in managing workload identities. The pattern also appears in the field during incidents such as the Snowflake breach, where access control and identity governance became the real fault line. NIST’s NIST Cybersecurity Framework 2.0 reinforces the point by tying governance to accountable control ownership, not just infrastructure deployment.

In practice, many security teams discover the ownership problem only after a key ceremony, audit request, or jurisdictional challenge has already exposed gaps in responsibility.

How It Works in Practice

Ownership should sit with the identity and security function that already governs trust policy, lifecycle controls, and exception handling. Infrastructure teams can operate the systems that store or use keys, but they should not be the sole authority deciding who may sign, decrypt, export, or delegate cryptographic material. In a sovereign model, that separation is essential because the control plane itself must be auditable across people, process, and geography.

The practical model usually includes three layers:

• Policy ownership by security and identity teams, including key-use rules, rotation thresholds, and approval workflows.
• Administrative separation so no single infrastructure operator can unilaterally change both the system and the trust boundary.
• Lifecycle accountability for issuance, rotation, recovery, escrow, and destruction, with evidence preserved for audits.

This approach aligns with NHIMG’s guidance on NHI governance and with the operational lessons behind the Azure Key Vault privilege escalation exposure and the 230M AWS environment compromise, where control concentration and weak separation amplified risk. It also fits the NIST CSF emphasis on governed access and repeatable control evidence, rather than informal admin trust. Where possible, current guidance suggests pairing ownership with formal policy-as-code review, dual control for sensitive actions, and periodic attestation of key custodianship.

These controls tend to break down in highly automated platform teams where the same engineering group both runs the environment and approves cryptographic exceptions, because separation of duties becomes operationally ambiguous.

Common Variations and Edge Cases

Tighter cryptographic control often increases operational overhead, requiring organisations to balance sovereignty assurances against deployment speed and incident response flexibility. That tradeoff becomes especially visible in multi-cloud, regulated, or M&A-heavy environments where one policy model must cover very different estates.

There is no universal standard for this yet, but current guidance suggests a few common patterns. In public cloud, security may own key policy while platform engineering manages integration. In highly regulated sectors, a separate cryptographic authority or trust office may approve root-level actions. In smaller organisations, the same person may operate both functions, but compensating controls should still enforce approval separation and logging. The key question is not who clicks the button, but who has authority to define the rules behind the button.

NHIMG’s Ultimate Guide to NHIs — Standards is a useful reference point when sovereignty overlaps with workload identity, because cryptographic control often becomes the enforcement layer for machine trust. For teams formalising this in a broader risk programme, the governance model should also reflect the fact that 52% of respondents in NHIMG’s 2026 survey expect AI security decision-making power to shift toward platform teams, which makes explicit ownership boundaries even more important.

In practice, the model fails most often when key authority is left implicit inside infrastructure operations, because audit questions then reveal that no one can prove who actually owned trust policy at the moment of change.

Related resources from NHI Mgmt Group

• Who should own machine identity and cryptographic readiness programmes?
• How can organisations prepare identity programmes for quantum-driven cryptographic change?
• How should security teams prioritise NHI remediation in cloud environments?
• How should security teams govern non-human identities in cloud environments?