Key Management in the Cloud: Who Holds the Keys, and What That Changes

When you encrypt data in the cloud, the question that matters is not whether it is encrypted. It is who holds the keys, who can use them, and what happens to your data if that changes. Key management decides whether encryption is a control you own or a feature you rent.

Why keys are the crown jewels

The US Cyber Safety Review Board’s report on the 2023 Microsoft Exchange Online intrusion (20 March 2024) makes the point plainly. It calls signing keys the cryptographic equivalent of crown jewels for any cloud service provider, because an adversary with a valid signing key can grant itself permission to access anything within that key’s domain. In that case, the stolen key, combined with another flaw in Microsoft’s authentication system, let the actor reach essentially any Exchange Online account. The report records that Microsoft did not know how or when the actor obtained the key. It notes that the key was a 2016 consumer key that should only have signed tokens for consumer services, and that its planned retirement in March 2021 had been delayed. The Board found the intrusion preventable.

This was a provider’s signing key, not a customer’s data key. It shows what concentrated key power looks like, and why lifecycle controls such as retirement dates, scope limits and validation logic matter.

What the key management standard asks

NIST SP 800-57 Part 1 Revision 5 (May 2020) is the reference most programs build on. Four points shape design.

Cryptoperiod. A cryptoperiod is the span in which a specific key is authorized for use. A suitably defined cryptoperiod limits the data available for cryptanalysis, limits the exposure if one key is compromised, and limits the time available to attack the access mechanisms that protect the key.
One purpose per key. In general a single key should be used for only one purpose, such as encryption or integrity.
Protection of plaintext keys. Usual measures include limiting the time a key is in plaintext, preventing humans from viewing plaintext keys, and keeping them inside physically protected containers such as cryptographic modules and hardware security modules.
Recovery and compromise. Whether to keep key recovery is decided case by case, balancing continuity of operations against exposure risk. When a key is compromised, all compromised keys must be revoked, affected keys replaced where needed, and an immediate damage assessment done where sensitive or critical processes are affected.

Who holds the keys: the options

Option	Who generates and holds the key	What you gain	What you accept
Provider-managed keys	Provider, by default	Simple, no operational load	Provider controls the key lifecycle; you rely on its controls and contract
Customer-managed keys in the provider’s service	You control the key policy; the key sits in the provider’s key service	Control over rotation, disablement and access policy	Provider infrastructure still processes the key; a misconfigured policy is your failure
Customer-controlled hardware	Your hardware security module, in your facility or a dedicated service	Strong separation; ability to revoke provider access	Cost, skills, and availability risk if the module fails
Keys held outside the provider	You, with data encrypted before it reaches the provider	Highest separation	Provider functions that need to read data may not work

Our reading: the table is a menu of trade-offs, not a ranking. Match the option to the sensitivity of the data, the legal duties around it and your ability to run keys safely.

Who can compel what: what the primary texts say

Short answer: in all four jurisdictions we checked, a provider or its customer can be compelled to produce data. Only UK law expressly covers keys. Customer-held keys change who receives the demand. They do not remove the power to make one. The table gives the text we read. It is a research summary, not legal advice.

Jurisdiction	Provision	What it says	Keys?
UAE	Criminal Procedure Decree-Law 38/2022, Art. 73(1) and Art. 76	The Prosecutor may search devices, networks, information systems and computer programs when the investigation requires. He may order anyone holding an item to be seized or reviewed to submit it, and refusal carries the penalty for refusing to testify	No key or password provision found
UAE	Cybercrimes Decree-Law 34/2021, Arts. 16 and 18	Offenses of using encryption or codes with intent to commit a crime or conceal its evidence, and of concealing or tampering with digital evidence to impede investigators	No duty to decrypt found
UAE	PDPL (Decree-Law 45/2021)	Art. 2(2)(c) excludes personal data held by security and judicial authorities. Art. 4(3) allows processing without consent when related to judicial or security procedures	No article on key disclosure
EU	GDPR Art. 48 and EDPB Guidelines 02/2024	A third-country court or authority order to transfer or disclose personal data is enforceable only if based on an international agreement such as a mutual legal assistance treaty. Responding to such a request is a transfer under the GDPR	Silent on keys
EU	EDPB Recommendations 01/2020, use cases 1 and 6	Encryption is an effective supplementary measure where the keys are retained solely under the control of the data exporter or a trusted entity in the EEA, with further conditions. Where the provider needs the data in the clear, the EDPB says it is incapable of envisioning an effective technical measure	Yes, as a transfer safeguard
UK	RIPA 2000 s.49 and s.56	A notice can go to a person believed to hold the key, requiring disclosure of protected information. ‘Key’ means any key, code, password, algorithm or other data allowing access or making data intelligible	Yes, expressly
UK	Investigatory Powers Act 2016 s.253(5)(c)	Technical capability obligations may cover removal by a relevant operator of electronic protection applied by or on behalf of that operator	Indirectly
US	18 U.S.C. 2713 (CLOUD Act)	A provider must disclose data within its possession, custody or control, whether stored inside or outside the United States	Silent. ‘Control’ is not defined

Our reading: the customer-held key is a real control against the provider being the point of compulsion. It is not a shield against the law. In the UK the notice follows the key. In the US, whether a key the customer holds is within a US provider’s ‘control’ is a legal argument the statute does not settle. The UAE texts give wide production powers and we found no key-surrender duty. Take specific legal advice before relying on key custody for compelled-disclosure risk.

UAE regulatory anchors

PDPL Article 20 (Federal Decree-Law 45 of 2021) lists encryption and pseudonymization among appropriate measures, and requires testing of their effectiveness.
CBUAE C 1/2026 Article 8.9 requires the Master System of Record to be kept in the UAE, including under outsourcing. Key custody and recovery design must keep that requirement intact. Article 13.11 requires viable exit plans for material third-party arrangements.

Lifecycle controls that fail quietly

Stage	Control question
Generation	Where was the key generated, and by what? Who saw it?
Use	Which identities and services can use it? Is use logged and alerted?
Rotation	Is there a defined cryptoperiod, and is rotation tested?
Retirement	Is there an enforced retirement date, and what happens when it slips?
Backup and recovery	Can you recover data if the key is lost, and who can authorize it?
Compromise	Is there a tested plan to revoke, replace and assess damage?

Decision

Decision: classify your data by the harm of provider-side access. Use provider-managed keys only where that harm is low. For the rest, hold the key policy yourself, and use customer-controlled hardware where regulation or risk demands it. Test the revoke-and-recover path before you need it.

What this evidence does not show

The CSRB case concerns a provider’s own signing key and does not describe customer key services. NIST SP 800-57 describes principles, not product designs. We did not verify any cloud provider’s key-management documentation, so the options table is generic and Cybrilliant analysis.

A short test

Pick one encrypted dataset. Find out who holds the key, who can use it, when it was last rotated, and whether anyone has tested recovery. Four answers or four gaps.

Sources

Cyber Safety Review Board, Review of the Summer 2023 Microsoft Exchange Online Intrusion, 20 March 2024. Accessed 9 October 2026. cisa.gov/sites/default/files/2025-03/CSRBReviewOfTheSummer2023MEOIntrusion508.pdf
NIST SP 800-57 Part 1 Rev. 5, Recommendation for Key Management: General, May 2020. Accessed 9 October 2026. nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r5.pdf
UAE Federal Decree-Law No. 45 of 2021 (Personal Data Protection), UAE Legislation portal. Accessed 9 October 2026. uaelegislation.gov.ae/en/legislations/1972
Central Bank of the UAE, Operational Risk Management Regulation C 1/2026, Rulebook. Accessed 9 October 2026. rulebook.centralbank.ae/en/rulebook/operational-risk-management-regulation
UAE Federal Decree-Law 38 of 2022 (Criminal Procedure), Arts 73 and 76, UAE Legislation portal. Accessed 9 October 2026. uaelegislation.gov.ae/en/legislations/1609/download
UAE Federal Decree-Law 34 of 2021 (Cybercrimes), Arts 16 and 18, UAE Legislation portal. Accessed 9 October 2026. uaelegislation.gov.ae/en/legislations/1526/download
EDPB Recommendations 01/2020 on supplementary measures, version 2.0. Accessed 9 October 2026. edpb.europa.eu/system/files/2021-06/edpb_recommendations_202001vo.2.0_supplementarymeasurestransferstools_en.pdf
EDPB Guidelines 02/2024 on Article 48 GDPR, version 2.1. Accessed 9 October 2026. edpb.europa.eu/system/files/2025-06/edpb_guidelines_202402_article48_v2_en.pdf
UK Regulation of Investigatory Powers Act 2000, Part III, sections 49 and 56. Accessed 9 October 2026. legislation.gov.uk/ukpga/2000/23/part/III legislation.gov.uk
UK Investigatory Powers Act 2016, section 253. Accessed 9 October 2026. legislation.gov.uk/ukpga/2016/25/section/253
US Code Title 18, section 2713 (CLOUD Act), govinfo. Accessed 9 October 2026. govinfo.gov/content/pkg/USCODE-2023-title18/html/USCODE-2023-title18-partI-chap121-sec2713.htm