In May 2023, a Chinese state actor compromised what Microsoft's incident analysis later called the "cryptographic crown jewels": a Microsoft Account consumer signing key. By July, the actor had used it to forge Azure Active Directory tokens and access the email of more than twenty organisations, including the US State Department and the Commerce Secretary. The Cyber Safety Review Board's March 2024 report on the incident called the intrusion "preventable" and characterised Microsoft's security culture as "inadequate". Microsoft, more than two years later, still cannot definitively explain how the key was stolen; the leading theory of accidental exposure through a debugging crash dump was downgraded to one hypothesis among several.
Encryption was on. AES-256 was in use. The signing key had been generated inside an appropriate hardware boundary. The algorithms were modern. None of it mattered. The control that failed was not the algorithm; it was the governance around the key itself: where it was allowed to travel, who could touch it, what logs were kept of its use, how its custody was structured, and what compensating evidence existed for the period when it was outside its hardware boundary. The Storm-0558 incident is the canonical 2024 framing of a shift that has been building in the regulatory literature for five years: regulators have stopped asking "is it encrypted" and started asking "who is in the room when a key is touched, and where is that on the record".
This article walks through what each major framework now requires for encryption governance specifically (the operational practice around key material, not the algorithm choice), why the key lifecycle is where the failures live, what the post-quantum and crypto-agility shift adds to the governance burden, and what an architecture that produces continuous evidence of key custody looks like. The companion article on customer-controlled encryption keys covered the architectural shift to BYOK and HYOK; this piece is the operational layer on top of that architecture.
The shift from algorithm to governance
For most of the cloud-platform era, the encryption conversation at audit time was about algorithm choice. AES-128 was acceptable, AES-256 was preferred, RC4 was forbidden, TLS 1.0 was on its way out. The vendor demonstrated that strong algorithms were in use; the auditor checked the certificate; the conversation moved on. Whoever held the keys, how they were rotated, who could authorise rotation, how usage was logged, was a chapter the audit rarely reached.
That chapter is now the audit. The change has multiple drivers. Schrems II made clear that encryption only counts as a supplementary measure where keys are held solely by the data exporter or an entity in an adequate jurisdiction; provider-managed keys fail the test because the provider can be compelled. EDPB Guidelines 01/2025 on Pseudonymisation codified the "additional information" concept (the lookup table or keys) and require it to sit outside the pseudonymisation domain, with technical and organisational controls preventing unauthorised crossing. NIS2's Implementing Regulation 2024/2690 turned Article 21(2)(h)'s one-line cryptography obligation into roughly 150 controls covering documented policy, full lifecycle management, and crypto-agility as an engineering requirement. The HIPAA NPRM of December 2024 removed the addressable carve-out from the encryption specification and named FIPS 140-2/3, AES-256, HSM Level 2 baseline (Level 3 recommended), 90-day key rotation for high-risk systems, and immediate rotation on breach as the new floor.
The 2024 NIST publication of FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA) added a second dimension: every regulated organisation now has a post-quantum migration policy to plan. The CNSA 2.0 timeline mandates new US national security system acquisitions to be quantum-resistant from 1 January 2027, with full national security system migration by 2030 and complete enforcement by end-2031. NIS2's January 2026 amendments wrote post-quantum migration into the directive by name. The European Union's coordinated roadmap targets critical-use-case PQC migration by 2030 and full migration by 2035. The engineering implication is unambiguous: cryptographic choices cannot be hard-wired into application code; central cryptographic policy, abstracted interfaces, and hybrid deployments during transition are now the default.
The governance load has gone up at the same time the architectural surface has expanded. The auditor question, framed by the regulator language above, is no longer about the algorithm; it is about whether the operating organisation can prove it managed the key well across every stage of its lifecycle.
What the major frameworks now require
The pattern is consistent across jurisdictions. The vocabulary differs. The direction does not.
GDPR and EDPB (European Union). Article 32(1)(a) names "pseudonymisation and encryption of personal data" as an appropriate measure. Article 32(1)(d) is the operational hook: "a process for regularly testing, assessing and evaluating the effectiveness of technical and organisational measures." EDPB Guidelines 01/2025 on Pseudonymisation, adopted in January 2025, introduces the binding "pseudonymisation domain" concept: the boundary inside which re-identification is possible. The additional information (lookup tables, keys) must sit outside that domain with technical and organisational controls preventing unauthorised crossing, and for international transfers it must be retained inside the European Economic Area or an adequate third country. The Schrems II supplementary measures recommendation (EDPB 01/2020) is the legal basis for the customer-controlled key architecture covered in the companion BYOK article.
NIS2 directive (European Union). Article 21(2)(h) requires "policies and procedures regarding the use of cryptography and, where appropriate, encryption". The Implementing Regulation 2024/2690 of 17 October 2024 expands that obligation into Annex 6 on cryptography: documented cryptographic policy with approved algorithms and key lengths; full key-lifecycle management covering generation, distribution, storage, archival, retrieval, replacement, retention, destruction, and recovery; periodic review; and cryptographic agility explicitly required as a mechanism enabling rapid algorithm replacement. The proposed Article 7(2)(k) under COM(2026) 13 final, published 20 January 2026, writes post-quantum migration into NIS2 by name and obliges Member States to adopt national PQC transition policies.
ISO 27001:2022 and ISO 27002:2022 (international). Annex A.8.24 "Use of cryptography" consolidates the 2013 controls (A.10.1.1 and A.10.1.2) into one. ISO 27002:2022 paragraph 8.24 demands a cryptographic policy covering the management approach, algorithm and protocol selection, and key management requirements with explicit lifecycle stages: generation, distribution, storage, archival, retrieval, replacement, retention, destruction, recovery. Roles and responsibilities for keys must be documented, including the custodian role. Supporting standards (ISO 11770 key management, ISO 27040 storage security, ISO 19790 cryptographic module security requirements, the international equivalent of FIPS 140-3) provide the technical depth. Surveillance auditors in the 2025 and 2026 cycles consistently flag "archival" and "recovery" as the weakest lifecycle stages: organisations document generation, storage, and rotation, but no documented procedure for what happens to a key when the service it protects is decommissioned, and no rehearsed recovery procedure when a custodian leaves.
NIST SP 800-57 (United States). Part 1 Revision 5 establishes the cryptoperiod framework. Section 5.3 defines the Originator-Usage Period and Recipient-Usage Period for each key type. Indicative limits: symmetric data encryption with an Originator-Usage Period of at most two years and a Recipient-Usage Period of at most the OUP plus three years; symmetric authentication or key wrapping at most two years; private signature keys one to three years; private key-transport or key-agreement keys at most two years; public Certificate Authority root signature keys up to roughly twenty years (with the trust-anchor distribution cost making longer impractical); compromised keys retired immediately regardless of cryptoperiod. Part 2 covers Best Practices for Key Management Organizations. Part 3 covers Application-Specific Guidance. FIPS 140-3 (effective September 2019, mandatory replacement of 140-2 from April 2026) sets the cryptographic module standard, with Level 2 the floor for regulated commercial use, Level 3 the practical benchmark for finance and HYOK, and Level 4 the defence and intelligence tier. CNSA 2.0 sets the post-quantum migration timeline for US national security systems through 2035.
PCI DSS 4.0.1 (international, payments). PCI is the most prescriptive framework on operational mechanics. Requirement 3.6 covers key management procedures; 3.6.1 governs generation; 3.6.2 secure distribution; 3.6.3 secure storage; 3.6.4 cryptoperiod and rotation; 3.6.5 retirement or replacement of suspected-weakened keys; 3.6.6 split knowledge and dual control for manual cleartext operations; 3.6.7 prevention of unauthorised substitution; 3.6.8 written acknowledgement by custodians of their responsibilities. Cryptoperiods must reference vendor guidance and NIST SP 800-57. Requirement 3.6.6 is the canonical "no one person holds the key" rule: split knowledge (each custodian holds a component that reveals nothing alone) plus dual control (no single individual can act on the material). Requirement 3.6.8 demands a written acknowledgement, an actual signature, from every custodian. The most common QSA finding under the 2025 cycle: a single database administrator holds the master-key passphrase; or the M-of-N ceremony exists in policy but every quarterly rotation is performed by the same lead engineer because the second custodian is always travelling.
SOC 2 (United States, AICPA). Common Criteria CC6.1 covers logical access including encryption supplementing other controls; CC6.7 covers transmission, movement, and removal of information; CC6.6 covers boundary protection. SOC 2 is principle-based, with the auditor deciding what counts as effective. In practice auditors ask for the key management policy, KMS audit trails showing rotation events, evidence of separation of duties (the engineer who can use a key cannot administer its lifecycle), HSM attestation reports or cloud KMS SOC 2 inheritance letters, quarterly review minutes for cryptographic standards, and personally identifiable data-at-rest configuration screenshots tied to the asset inventory. The canonical SOC 2 deficiency in 2026 audit cycles: encryption is on, but there is no log of who used which key for what. The control is implemented but unprovable.
HIPAA Security Rule (United States, healthcare). Section 164.312(a)(2)(iv) encryption and decryption; section 164.312(e)(2)(ii) encryption of transmission. The December 2024 NPRM removes the addressable carve-out across the board and proposes explicit invocation of FIPS 140-2 and 140-3 validated modules, AES-256, TLS 1.2 or higher, HSM Level 2 baseline with Level 3 recommended for high-risk systems, 90-day key rotation cycles for high-risk data encryption keys with immediate rotation on suspected compromise, key encryption key rotation every six to twelve months, and master key rotation every twelve to twenty-four months. Common finding under the current rule: tenant-isolated data encryption keys are in place, but the same key encryption key protects every tenant, so a single key compromise reaches every patient record.
FINMA Circular 2023/1 (Switzerland). Chapter IV.D Critical Data Risk Management introduces the "critical data" concept, data so significant to confidentiality, integrity, or availability that it requires enhanced safeguards. Institutions must classify, restrict access, monitor, and apply heightened cryptographic protection. Cryptographic-module certification (FIPS 140-3 or ISO 19790) and key custody separation between the data plane and the key plane are the expected design pattern. FINMA has signalled through 2025 and 2026 that supervised entities are expected to have a post-quantum readiness assessment as part of operational-risk reviews. Common finding: a critical-data inventory exists at policy level but cryptographic protection is applied uniformly across all data without the criticality-driven escalation FINMA expects; no post-quantum inventory.
ADHICS V2 (United Arab Emirates). The Abu Dhabi healthcare standard mandates end-to-end encryption for all patient-data transmissions, with AES-256 baseline for symmetric encryption, RSA for asymmetric, and documented hashing and tokenisation. Key management procedures, audit requirements, and rotation cadences must be documented. Key material lives in an HSM or KMS with strict governance; FIPS 140-2 Level 2 or higher is the baseline, with 140-3 increasingly expected. Annual compliance audits are mandatory, bi-annual security assessments, and continuous monitoring of high-risk systems. Common finding: a third-party electronic medical record vendor handles encryption but provides no key-usage logs to the healthcare entity, making it impossible to demonstrate custody to the Department of Health.
SAMA Cyber Security Framework (Saudi Arabia). Domain 3.3.9 Cryptography (commonly miscited as 3.3.6, which is actually Application Security) mandates AES-256 for sensitive data, HSM or KMS storage of keys, a documented cryptographic-solution policy approved by senior management, and key custody policies covering generation, distribution, storage, rotation, revocation, and destruction. The SAMA Cyber Resilience Framework for systemically important entities adds forensic-readiness expectations on key-usage logging: the audit trail must survive an active-adversary scenario. Common finding: encryption is present but key-usage logging routes to the same SIEM that the cryptographic-operations administrator can edit, violating SAMA's forensic-integrity expectation.
Ten frameworks, six jurisdictions. The encryption-governance obligation has converged on the same shape: a documented lifecycle, separation of duties, cryptographic-module certification, continuous evidence of key usage, and a plan for the post-quantum transition.
The key lifecycle and where it breaks
Every framework above ultimately maps to the same nine-stage lifecycle. The audit questions cluster around three stages where most organisations have weak operational evidence.
Generation. Keys must be generated inside a hardware random bit generator backed by a FIPS-validated module, with the cryptoperiod assigned at birth. The common failure: keys generated on a laptop and uploaded to the production HSM "just for now". The temporary state becomes permanent.
Distribution. Keys must never be transmitted in cleartext over an untrusted channel. Key wrapping is the standard mechanism; split-knowledge ceremony covers the manual cases. The common failure: key material pasted into a chat tool or stored in a password manager during an integration.
Storage. Keys live in an HSM (FIPS 140-3 Level 2 floor, Level 3 norm for finance and healthcare) and never alongside the ciphertext they protect; backups are encrypted under a separate key encryption key.
Usage. Every cryptographic operation should be logged with operator identity, timestamp, purpose, and key identifier. This is where the SOC 2 finding lives: encryption is on, but the log of who used which key for what does not exist or is not tamper-evident. The companion article on tamper-proof audit trails covers the integrity layer that makes key-usage evidence credible.
Rotation. Scheduled per the assigned cryptoperiod, with key versioning so old ciphertext can still be decrypted. The rotation event is itself logged and hash-chained. Common failure: the policy says annual rotation; the KMS shows the production master key was last rotated three years ago because the rotation runbook required a manual approval nobody remembered to schedule.
Retirement, archival, recovery, destruction. Documented state transitions (active → deactivated → compromised → destroyed); long-cryptoperiod escrow keys held under M-of-N control; rehearsed recovery procedures; crypto-shredding of dependent data encryption keys at end of life. These are the stages ISO 27001 surveillance auditors most consistently find weak.
The 2023 to 2025 incidents that bracket this article all map to the same lifecycle stage: usage and custody. The Microsoft Storm-0558 incident was a custody failure: a signing key escaped its hardware boundary into a debugging context. The Okta HAR file breach of October 2023 was a custody failure of derived bearer credentials: session tokens stored in plaintext inside a support system, accessed via a service-account credential cached on an employee's personal Google profile. AWS access-key leakage on public GitHub repositories through 2023, 2024, and 2025 follows the same pattern: even with HSM-backed root keys, bearer credentials derived from them are an extension of the trust boundary and need the same governance discipline. The cluster of code-signing supply-chain compromises (3CX, MSI BIOS keys, Realtek codesign) all started with a signing-key custody failure that propagated downstream into every artefact signed during the exposure window.
The questions that distinguish governance from algorithm choice
A short, uncomfortable checklist for any team evaluating its encryption posture in 2026.
- Can you produce, on demand, a log of every key-usage event for a specific key over a specific period? "We use AES-256" is not the answer the auditor is looking for. "Here is the operator, timestamp, purpose, and key identifier for every operation against key X over the last twelve months" is.
- Does every sensitive key operation require dual control or M-of-N approval? PCI DSS 3.6.6 is the most explicit, but ISO 27002 paragraph 8.24, FINMA Circular 2023/1, and SAMA Domain 3.3.9 all expect it. The engineering test is direct: can a single insider decrypt production data without a second human?
- Are pseudonymisation keys (lookup tables, salts) stored outside the pseudonymisation domain? EDPB Guidelines 01/2025 is now the binding interpretation. Pseudonymisation keys in the same database, same backup set, same access plane as the pseudonymised data are effectively no pseudonymisation at all.
- What is your post-quantum migration plan? NIST FIPS 203, 204, and 205 are final standards. CNSA 2.0 sets US national security deadlines through 2035. NIS2's 2026 amendments wrote PQC into the directive. The auditor in 2026 will ask; not having an answer is the answer.
- Where does the auditor read the key-usage log, and can they verify it has not been edited? The companion article on tamper-proof audit trails covers what tamper-evident actually means. SAMA's forensic-integrity expectation is the cleanest articulation: the audit trail must survive an active-adversary scenario.
A platform that answers each of these with an artefact rather than a paragraph is producing encryption governance as a continuous output. A platform that produces "an encryption policy PDF" is producing a 2015 artefact for a 2026 expectation.
The architectural answer
Encryption governance stays painful as long as the operational practices around key material are decoupled from the evidence the auditor reads. The architectural answer wires the two together: every key event becomes a first-class entry in the same audit stream that captures every other control action, hash-chained and tamper-evident, with the operator identity, the system of record, and the justification all linked at the moment the event occurs.
Novantra's customer-controlled key architecture provides the foundation: customers hold their master keys in their own provider (AWS KMS, Azure Key Vault, HashiCorp Vault Transit, PKCS#11 hardware security modules, external KMS), and Novantra cannot use a key without the customer's provider responding. The governance layer sits on top: every wrap, unwrap, rotation, retirement, and recovery operation is captured as a structured event with full context.
Novantra's operation ledger records every key-use event with the operator identity, timestamp, key identifier, purpose, success or failure outcome, and the originating workflow context. The ledger is hash-chained per organisation, signed at periodic intervals with an HSM-resident key, and optionally anchored externally. The SOC 2 "encryption was on, log was missing" finding does not happen because the log is the same write as the operation.
Novantra's separation of duties is structural rather than procedural. The role that can administer a key (provider configuration, rotation policy, retirement) is distinct from the role that can use a key (wrap or unwrap a specific record). The companion article on access reviews as evidence covers the underlying access-event substrate. PCI DSS 3.6.6 split-knowledge and dual-control patterns are configurable on top of the role boundary.
Novantra's cryptographic agility is designed in. Algorithm choices are central policy, not hard-wired application logic. Hybrid deployments (X25519 with ML-KEM during transition, RSA with ML-DSA for signatures) are configuration changes rather than code rewrites. The post-quantum migration roadmap a regulated buyer needs to produce in 2026 lands as a Novantra runbook, not a multi-quarter engineering project.
Novantra's pseudonymisation lifecycle keeps the additional information outside the pseudonymisation domain by construction. Lookup tables, tokenisation secrets, and salts are wrapped under a separate key from the pseudonymised data, and the EDPB Guidelines 01/2025 separation is enforced at the storage layer.
Novantra's key-transparency option, for the highest-assurance customers, exposes the key-state event stream as an externally verifiable signed log. Customers and auditors can independently re-derive the chain and confirm that the key history is consistent with the operations the platform reported.
For customers whose threat model or jurisdiction requires it, Novantra's Sovereign deployment runs the entire key-handling and governance stack inside the customer's own infrastructure.
None of this is a feature. Each is the architectural answer to a question every major framework is now asking in encryption-governance language: not whether the algorithm is strong, and not whether the keys are customer-controlled, but whether the operating organisation can produce continuous, tamper-evident evidence that the keys were managed properly across every stage of their lifecycle. The Storm-0558 incident is the standing illustration of what happens when that evidence does not exist. The frameworks have moved decisively past "is it encrypted". The architecture either matches that move or sets the operating organisation up to repeat the 2023 lesson.