Most security laws never say "encrypt", yet regulators, auditors and breach notification rules treat missing encryption or weak key management as the difference between a minor event and a reportable failure. Some rules mandate encryption outright (the FTC Safeguards Rule, NYDFS Part 500, PCI DSS), some name it as an example of appropriate security (GDPR Article 32), some now prescribe key management in detail (the DORA and NIS2 implementing acts), and a new layer of post-quantum deadlines sets dates for replacing RSA and elliptic curve cryptography. This map puts those obligations side by side: what each rule requires for data at rest and in transit, what it says about keys, and what encryption buys you when a breach happens. It is for CISOs, GRC leads, security architects and the engineers who own key management services and HSMs. Status as of 11 November 2026; proposals are marked as such.
Source note: this map summarises official texts, regulator guidance and the sources listed at the end, with status as of 11 November 2026. It is not legal advice. Confirm against the official text before relying on it.
Key takeaways
- Mandatory, expected or exemplary. The FTC Safeguards Rule, NYDFS Part 500 and PCI DSS require encryption with documented exceptions; GDPR names it as an example measure; HIPAA still treats it as addressable while a proposal to make it required is pending.
- Key management is now written into EU law. DORA's RTS (Delegated Regulation (EU) 2024/1774) Article 7 and the NIS2 Implementing Regulation (EU) 2024/2690 Annex point 9 list the full key life cycle, from generation to destruction, plus a register of certificates.
- Encryption only counts if the key survived. HIPAA's "secured PHI" safe harbour and GDPR Article 34(3)(a) both depend on the key or decryption process not being compromised along with the data.
- Post-quantum dates are now policy, not advice. US Executive Order 14412 (22 June 2026) sets 31 December 2030 for PQC key establishment in federal high value assets; the UK NCSC sets 2028, 2031 and 2035 milestones; the EU roadmap says high-risk use cases by the end of 2030.
- Most keys are held by machines. KMS roles, workload identities and CI/CD service accounts that can call decrypt are the real control surface, so key access policies are an identity problem as much as a cryptography one.
Regulations and frameworks at a glance
| Rule | Who it applies to | Encryption requirement | Key management requirement | Status (11 November 2026) |
|---|---|---|---|---|
| EU DORA RTS, Delegated Regulation (EU) 2024/1774, Articles 6 and 7 | EU financial entities in scope of the full ICT risk framework | Documented policy on encryption and cryptographic controls covering data at rest, in transit, in use where necessary, internal network connections and traffic with external parties; data in use that cannot be encrypted must be processed in a separated, protected environment | Full key life cycle; protection against loss, unauthorised access, disclosure and modification; replacement of lost or compromised keys; register of certificates and certificate-storing devices; renew certificates before expiry | Applies with DORA since 17 January 2025 |
| EU NIS2, Directive (EU) 2022/2555, Article 21(2)(h), with Implementing Regulation (EU) 2024/2690 Annex point 9 | Essential and important entities; the Implementing Regulation covers digital infrastructure and digital providers (cloud, data centres, managed and managed security service providers, DNS, trust services and others) | Policies and procedures on cryptography and, where appropriate, encryption; type, strength and quality of controls per asset class, at rest and in transit; approved protocols, algorithms and cipher strengths, optionally with crypto agility | Separate keys per system, certificate issuance, distribution, storage and access control, change, compromise handling, revocation, recovery, backup, destruction, logging, activation and deactivation dates; review against the state of the art | Directive applies via national law; Implementing Regulation in force since 7 November 2024 |
| GDPR and UK GDPR, Articles 32 and 34(3)(a) | Controllers and processors of personal data | "The pseudonymisation and encryption of personal data" named as an appropriate measure, weighed against risk and state of the art | Not specified; the Article 34 exemption only holds if data stays unintelligible to unauthorised people | In force; ICO encryption guidance under review after the Data (Use and Access) Act |
| US FTC Safeguards Rule, 16 CFR 314.4(c)(3) | Non-bank financial institutions under FTC jurisdiction | Encrypt all customer information held or transmitted, in transit over external networks and at rest | Not specified; any alternative to encryption must be reviewed and approved by the Qualified Individual | In force |
| New York 23 NYCRR 500.15 | DFS-licensed covered entities | Encrypt nonpublic information in transit over external networks and at rest, consistent with industry standards | Compensating controls only with CISO approval in writing, reviewed at least annually | In force (amended November 2023) |
| US HIPAA Security Rule, 45 CFR 164.312(a)(2)(iv) and (e)(2)(ii) | Covered entities and business associates | Encryption of ePHI at rest and in transmission is "addressable": implement it or document why an equivalent measure is reasonable | HHS breach guidance: keep decryption tools on a device or at a location separate from the data | In force; January 2025 proposal (90 FR 898) would make encryption required with limited exceptions, final rule reported as moved to July 2027 |
| PCI DSS v4.0.1, Requirements 3 and 4 | Entities that store, process or transmit cardholder data | Render stored PAN unreadable (strong cryptography, truncation, tokens or hashing); strong cryptography for PAN over open, public networks | Documented key management: generation, distribution, storage, cryptoperiods, retirement, split knowledge and dual control for manual clear-text operations; inventory of cipher suites and protocols reviewed annually | In force; future-dated requirements mandatory since 31 March 2025 |
| India DPDP Rules 2025, Rule 6 | Data fiduciaries processing digital personal data in India | Reasonable security safeguards including encryption, obfuscation, masking or tokenisation | Access control and logging; logs kept for one year | Rules notified 14 November 2025; security safeguards apply after the 18-month phase-in |
| US Executive Order 14412 and OMB M-26-15 | US federal agencies; contractors through a proposed FAR rule | PQC key establishment for high value assets and high impact systems by 31 December 2030; TLS 1.3 or successor support no later than 2 January 2030 | PQC signatures by 31 December 2031; cryptographic bill of materials guidance due from CISA and NIST | Signed 22 June 2026; memorandum issued 24 June 2026 |
| NSA CNSA 2.0 (CNSSP 15 update) | US National Security Systems and their vendors | AES-256, ML-KEM-1024, ML-DSA-87, SHA-384 or SHA-512; LMS or XMSS for firmware and software signing | New NSS acquisitions CNSA 2.0 compliant from 1 January 2027; non-compliant equipment phased out by 31 December 2030; CNSA 2.0 mandated by 31 December 2031 | In force for NSS |
Sector rules add more (central bank technology risk guidelines, telecoms and health regulators), and US state breach laws usually apply only to unencrypted personal information, which is why encryption appears in almost every state safe harbour discussion. For the law around exporting cryptography itself, see the Encryption Export Controls Guide.
Data at rest and in transit: how the obligations compare
The rules converge on two baselines and differ on the exceptions.
| Question | Strictest answer | Where flexibility exists |
|---|---|---|
| Must data at rest be encrypted? | FTC Safeguards and NYDFS: all customer information or nonpublic information, unless infeasible; PCI DSS: stored PAN always unreadable | GDPR and HIPAA (today): risk-based, so a documented decision not to encrypt can be lawful |
| Must data in transit be encrypted? | Over external networks in FTC, NYDFS and PCI DSS (open, public networks) | Internal traffic is explicit in DORA Article 6 (internal network connections) and NIS2 Annex point 9 by asset class; elsewhere it follows the risk assessment |
| Data in use | DORA: encrypt where necessary, otherwise a separated and protected environment | Few other rules address it; confidential computing remains a design choice |
| Who approves an exception? | Qualified Individual (FTC), CISO in writing with annual review (NYDFS) | HIPAA requires a documented rationale for an addressable specification; DORA requires recorded mitigation and monitoring measures with a reasoned explanation |
| Which algorithms? | CNSA 2.0 for NSS; FIPS 140-3 validated modules for US federal systems | EU acts require "leading practices and standards" and review against the state of the art, without naming algorithms |
The practical baseline for a multi-jurisdiction organisation: encrypt all regulated data at rest and in transit over every network, document exceptions with an owner and an annual review, and use validated modules where any federal or card data is involved. See the Encryption Guide and the FIPS 140-3 and Cryptographic Module Validation Guide.
Key management obligations in detail
DORA and NIS2 are the first broad cyber laws to spell out the key life cycle. PCI DSS has done so for card data for years. Together they define what an auditor will ask for.
| Life cycle stage | DORA RTS Art. 7 | NIS2 IR Annex 9.2(c) | PCI DSS Req. 3 | Evidence to keep |
|---|---|---|---|---|
| Generation | Yes | Separate keys for different systems and applications | Strong key generation | KMS or HSM key creation logs, key specs |
| Distribution and activation | Transmitting | Distribute to intended recipients, activate on receipt | Secure distribution | Wrapping keys, import records |
| Storage and access | Storing; protection against unauthorised access | Storage and access control for authorised users | Fewest possible locations; access restricted to fewest custodians | Key policies, IAM bindings, HSM roles |
| Rotation | Renewing | Changing or updating keys, when and how | Defined cryptoperiods | Rotation schedule and last rotation date per key |
| Compromise and revocation | Replace lost, compromised or damaged keys; revoking | Dealing with compromised keys; revoking | Retire or replace on suspected compromise | Compromise runbook, revocation records |
| Backup, recovery, archive | Backing up, archiving, retrieving | Recovering lost or corrupted keys; backup or archive | Secure storage of backups | Backup location, restore test results |
| Destruction | Destroying | Destroying keys | Retire and destroy | Scheduled deletion events |
| Certificates | Register of certificates and certificate-storing devices; renew before expiry | Issuing and obtaining public key certificates | Inventory of trusted keys and certificates for PAN in transit | Certificate inventory with expiry and owner |
| Logging and audit | Implied by ICT logging requirements | Logging and auditing key management activities | Logged access to cryptographic material | KMS audit logs retained per log policy |
See the Cryptographic Key Management Guide, the PCI DSS Requirement 3 Key Management Guide and the Cryptographic Key Management Policy Template.
Encryption and breach notification
Encryption changes breach outcomes only under specific conditions, and every regime ties the benefit to the key.
- HIPAA: PHI encrypted consistent with NIST SP 800-111 (at rest) or SP 800-52, 800-77 or 800-113 (in transit) is "secured", so a loss does not trigger breach notification, provided the key or process was not breached. HHS advises keeping decryption tools separate from the data. See the HIPAA Breach Notification Rule Guide.
- GDPR Article 34(3)(a): individuals need not be told if measures such as encryption render the data unintelligible to anyone not authorised. Notifying the supervisory authority under Article 33 is a separate assessment.
- US state laws: most define a breach in terms of unencrypted personal information, and many bring encrypted data back into scope when the key was also acquired. Check each state's definition. See the Data Breach Notification Checklist.
Encryption at rest does not help when the attacker reads data through a running application, a valid service account or a decrypt-capable role. In the LastPass breach, stolen DevOps secrets gave access to encrypted backups and the keys needed for them, and the Microsoft Storm-0558 key breach showed what a single exposed signing key can do. Regulators assess whether the key was protected, not whether a cipher was switched on.
Post-quantum deadlines
| Date | Source | Milestone |
|---|---|---|
| 22 June 2026 | US EO 14412 | Agencies name a PQC migration lead within 30 days; FAR Council to propose a rule requiring covered contractors to use FIPS-compliant cryptography including PQC by 31 December 2030 |
| 24 June 2026 | OMB M-26-15 | Agency migration plans due within 120 days; discovery and inventory phase 2026 to 2027 |
| 27 October 2026 | NIST IR 8547 (final) | Transition guidance from quantum-vulnerable to quantum-resistant standards published |
| End of 2026 | EU coordinated PQC roadmap (23 June 2025) | All Member States start transitioning |
| 1 January 2027 | CNSA 2.0 | New NSS acquisitions CNSA 2.0 compliant |
| 2028 | UK NCSC | Migration goals set, discovery and assessment complete, initial plan drafted |
| 2 January 2030 | OMB M-26-15 | TLS 1.3 or successor supported |
| 31 December 2030 | EO 14412; EU roadmap; CNSA 2.0 | PQC key establishment for federal HVAs; EU high-risk use cases migrated; NSS equipment unable to support CNSA 2.0 phased out |
| 2031 | EO 14412; UK NCSC; CNSA 2.0 | PQC signatures for federal HVAs (31 December 2031); UK highest-priority migrations done; CNSA 2.0 mandated |
| 2035 | UK NCSC; OMB M-26-15 phase 5 | Full migration |
None of these bind most private companies directly yet, but they reach them through federal contracts, NSS supply chains and the "state of the art" test in DORA and NIS2, which explicitly require updating cryptography as cryptanalysis develops. See the Post-Quantum Cryptography Deadlines Tracker and the CNSA 2.0 Transition guide.
What it means for AI agents and non-human identities
Every encrypt and decrypt call in a modern estate is made by a workload: an application role, a database service account, a backup job, a CI/CD pipeline or an AI agent with a data tool. The law's "access to keys restricted to authorised users" (NIS2 Annex 9.2(c)) and "protection against unauthorised access" (DORA Article 7) therefore apply mostly to machine identities.
| Scenario | Regulatory exposure | Control |
|---|---|---|
| Over-broad KMS decrypt permission on a shared role | Encrypted data is readable by anyone who assumes the role, so the breach safe harbour may not apply | One key per data set and application; decrypt granted to named workload identities only |
| Long-lived access key for a backup service stored in a repository | Key and ciphertext stolen together (T1552 Unsecured Credentials) | Workload identity federation, secrets scanning, short-lived credentials |
| AI agent with a retrieval tool over encrypted stores | Agent sees plaintext; logs and prompts may hold regulated data | Per-agent identity, scoped decrypt grants, logging of key use per agent |
| Certificate for a service-to-service mTLS link expires | Outage, and a DORA Article 7 gap (certificates not renewed before expiry) | Automated issuance and renewal with an owner per certificate |
See the Machine Identity, PKI and Certificate Lifecycle Guide and the Envelope Encryption and KMS Integration Patterns Guide.
Compliance steps
- Map rules to data classes. For each data class (cardholder, health, customer financial, personal, confidential business) record which rules apply and whether encryption is mandatory, expected or risk-based.
- Write one cryptography policy that satisfies the strictest rule. Approved algorithms and key lengths, protocols (TLS 1.2 minimum, TLS 1.3 preferred), validated modules where needed, and an exception process with an approver and an annual review. See the Encryption Policy Template.
- Build the cryptographic inventory. Keys, certificates, HSMs, KMS instances, cipher suites and protocols in use, with owners. This is the DORA certificate register, the PCI DSS cipher suite inventory and phase 1 of every PQC plan at once.
- Restrict key use to named identities. Review KMS key policies and HSM roles; separate key administrators from key users; remove wildcard decrypt grants.
- Test the exceptions. Pilot encryption on systems with documented exceptions; most exceptions date from legacy constraints that no longer exist.
- Rehearse a key compromise. Rotate a production data key and revoke a certificate in a controlled exercise; record time to complete. Keep the previous key version available for decryption until re-encryption is verified, so rollback is possible. See the Encryption Key Compromise Playbook.
- Plan the PQC transition. Prioritise data with long confidentiality needs and long-lived signing keys; ask suppliers for PQC roadmaps. See the PQC Migration Plan Template.
Metrics that show it is working
- Encryption coverage: percentage of regulated data stores encrypted at rest with customer-managed or provider keys, by data class (target 100% for mandatory classes).
- Transport coverage: percentage of internal and external endpoints negotiating TLS 1.2 or higher, and the share on TLS 1.3.
- Open exceptions: number of approved encryption exceptions past their annual review date (target zero).
- Key hygiene: percentage of keys within their defined cryptoperiod and with a named owner.
- Certificate expiry incidents: outages or failed connections caused by expired certificates per quarter.
- Decrypt privilege breadth: number of identities with decrypt rights per sensitive key, trended down.
Common failure patterns
- Encryption as a tick box: storage-level encryption with provider keys satisfies an auditor's "encrypted at rest" question but does nothing against an attacker using a valid application or cloud role.
- Keys stored with the data: backup encryption keys in the same account or vault as the backups void the HIPAA and GDPR benefits.
- Exceptions that never expire: a 2019 "infeasible" decision still on file in 2026, with no annual review as NYDFS requires.
- No certificate register: DORA's register requirement is missed because certificates are issued by many teams and clouds.
- Waiting for PQC mandates: treating post-quantum as a 2035 problem, when inventory is due now under every roadmap and harvested data encrypted today may be exposed later.
Framework mapping
| Theme | NIST CSF 2.0 | NIST SP 800-53 Rev. 5 | ISO/IEC 27001:2022 Annex A |
|---|---|---|---|
| Legal and regulatory requirements understood | GV.OC-03 | PM-9 | 5.31 |
| Data at rest protected | PR.DS-01 | SC-28 | 8.24 |
| Data in transit protected | PR.DS-02 | SC-8 | 8.24 |
| Cryptographic protection and key management | PR.DS-01, PR.DS-02 | SC-12, SC-13 | 8.24 |
Practitioner checklist
- Record, per data class, which rules mandate encryption and which allow a risk-based decision.
- Maintain one cryptography policy with approved algorithms, protocols, modules and an exception process.
- Keep a register of keys, certificates and HSMs with owners and expiry dates.
- Grant decrypt rights to named workload identities only, and review them quarterly.
- Store backup keys outside the account or vault that holds the backups.
- Review every encryption exception at least annually with written approval.
- Rehearse key rotation and compromise response once a year.
- Start the cryptographic inventory for PQC now and ask critical suppliers for their roadmaps.
Standards and references
- EUR-Lex: Commission Delegated Regulation (EU) 2024/1774 (DORA ICT risk management RTS)
- EUR-Lex: Commission Implementing Regulation (EU) 2024/2690 (NIS2 technical and methodological requirements)
- GDPR: Article 32 Security of processing
- eCFR: 16 CFR 314.4 Elements of the FTC Safeguards Rule
- HHS: Guidance to Render Unsecured PHI Unusable, Unreadable, or Indecipherable
- The White House: Securing the Nation Against Advanced Cryptographic Attacks (EO 14412)
- NCSC: Timelines for migration to post-quantum cryptography
- NIST: IR 8547 Transition to Post-Quantum Cryptography Standards
This guide summarises encryption and key management requirements as of 11 November 2026 and is not legal advice. Related NHI Mgmt Group resources: Encryption Guide · Cryptographic Key Management Guide · Post-Quantum Cryptography Migration Guide · Global Cybersecurity Regulatory Map