The DORA encryption policy under RTS Article 6

Article 6 of Commission Delegated Regulation (EU) 2024/1774, the regulatory technical standards (RTS) on ICT risk management under DORA, requires a financial entity to have a policy on encryption and cryptographic controls, and that policy must contain provisions for updating or changing cryptographic technology based on developments in cryptanalysis. The text names no algorithm and sets no post-quantum deadline. What follows separates the literal requirement from our view of how to write the document and evidence it. ICT means information and communication technology. This is information, not legal advice.

What Article 6 literally requires

The RTS is binding on the financial entities in its scope, and Article 6 is its encryption article. It asks for a documented policy on encryption and cryptographic controls, adopted as part of the ICT security policies, and built on the results of data classification and of the ICT risk assessment. The policy addresses the protection of data in the states the entity actually has: at rest, in transit, and, where relevant and technically feasible, in use. Where encrypting data in use is not feasible, the entity is expected to process the data in a protected environment or to apply other measures and record that choice. The article points to leading practices and recognised standards rather than to a fixed algorithm list. And it carries the clause that matters most for post-quantum work: the policy must include provisions for updating or changing cryptographic technology as cryptanalysis evolves. The authoritative text is on EUR-Lex, and our dated summary is on the DORA RTS page. Always check paragraph numbering against the consolidated text before citing it in an audit response.

Article 7 is the companion provision: cryptographic key management across the whole lifecycle (generation, renewal, storage, archiving, retrieval, destruction) and a register of certificates and certificate-storing devices, at least for ICT assets supporting critical or important functions. Read the two articles together. Most of the evidence an assessor asks for under Article 6 lives in the inventories and registers that Article 7 obliges you to maintain.

What Article 6 does not say

It does not name ML-KEM (module lattice key encapsulation mechanism, standardised by NIST as FIPS 203 on 2024-08-13), it does not mention hybrid key exchange, and it gives no migration date. Those signals come from other documents, and each carries its own status. NIST IR 8547 is an initial public draft (2024-11-12, still a draft) that proposes deprecating quantum-vulnerable algorithms at 112-bit security after 2030 and disallowing all quantum-vulnerable public-key algorithms after 2035. The EU Coordinated Implementation Roadmap v1.1 (published 2025-06-23) is coordinated guidance for Member States, not a regulation binding companies: it sets first steps including a cryptographic inventory and national roadmaps by end of 2026, high-risk use cases migrated by end of 2030 and medium-risk by end of 2035. NIS2 Article 21(2)(h) asks separately for policies and procedures on the use of cryptography and, where appropriate, encryption. Entities in scope of both should write one policy and map it twice, rather than maintaining two documents.

A section-by-section outline

The structure below is our interpretation, not a template published by a regulator. It is arranged so that each section answers one question an assessor is likely to ask, and so that the volatile part (algorithms) sits in an annex you can version without reopening the whole policy.

1. Purpose, scope and governance. Which entities, systems and third parties are covered, who approves the policy, who owns it, review cadence.
2. Definitions and roles. Key custodian, crypto architect, asset owner, certificate owner. Define each acronym once.
3. Link to data classification. For each classification level, the protection required in each data state. This is what makes the policy risk-based rather than generic.
4. Approved algorithms, key lengths and protocols (Annex A). A versioned table with three columns: preferred, acceptable, prohibited. Cite the standard behind each entry.
5. Data at rest. Disks, databases, object storage, backups, archives, endpoints. State the mechanism and who verifies coverage.
6. Data in transit. Minimum TLS version, approved cipher suites and key exchange groups, internal service to service traffic, file transfer, email, remote administration.
7. Data in use. Where it applies, and where it does not, the protected environment or other measures used instead, with the rationale recorded.
8. Keys and certificates. Reference Article 7: lifecycle rules, hardware security module and key management service usage, rotation periods, the certificate register and its expiry alerting.
9. Cryptographic inventory and suppliers. How the inventory is built and refreshed, and what you require from ICT third-party providers.
10. Changing cryptographic technology (Annex B). The agility clause, described in the next section.
11. Exceptions and legacy. A register of time-limited exceptions, each with a compensating control, an owner and an end date.
12. Evidence and reporting. Which artefact proves which clause, who produces it, and how often.

The change provision: crypto agility in writing

A clause that says the entity will monitor cryptographic developments is not evidence. A clause an assessor can test names the trigger, the owner, the inventory it acts on, and the time it takes to act. Five elements are enough.

• Trigger sources. Named documents and feeds you watch: NIST standards and drafts, BSI TR-02102-1 (a technical guideline, whose 2026-01 version recommends hybrid post-quantum key agreement and recommends classical key agreement alone only until end of 2031, end of 2030 for very high protection needs), ANSSI publications (its post-quantum recommendations are not yet regulatory obligations outside its regulated scope), supplier end-of-support notices, and published cryptanalytic results.
• A decision owner. One role that can change Annex A, with a committee that approves it and a record of the date, the rationale and the source document.
• An inventory with owners. You cannot change what you cannot list. A cryptographic bill of materials (CBOM) is one practical way to produce this, and that is our interpretation rather than a requirement of the text.
• Asset classes with target dates. Group assets by exposure and by how long their data must stay confidential, then give each group a target date rather than giving the whole estate one.
• A safe rollout rule. New algorithms are enabled alongside a classical fallback, tested in staging, and only then promoted.

Why key exchange first: recorded traffic is protected only by the key exchange that established the session, so traffic captured today can be decrypted later if that exchange is quantum-vulnerable. Signatures and certificates can migrate afterwards, because a signature verified today does not become forgeable retroactively. That is the sober reason hybrid key exchange, for example X25519MLKEM768 (IANA codepoint 0x11EC), is the first concrete step for a financial entity. Pre-standard Kyber groups such as X25519Kyber768Draft00 (0x6399) are obsolete and should be listed as prohibited in Annex A. OpenSSL 3.5 or later is required for the ML-KEM groups in OpenSSL.

Section 10. Changing cryptographic technology

10.1 Annex A (approved algorithms) is reviewed at least every 12 months and on any
     of these triggers: a new or withdrawn standard, an update to a national
     technical guideline we track, a published cryptanalytic result, a supplier
     end-of-support notice, or a change in the classification of data we protect.
10.2 The CISO owns Annex A. Changes are approved by the ICT risk committee and
     recorded with a date, a rationale and the source document.
10.3 Each asset class in Annex B has a named owner and a target date for migration
     to the algorithms marked preferred in Annex A.
10.4 Where an asset cannot meet its target date, the owner records a time-limited
     exception with a compensating control and an end date.
10.5 A new algorithm is deployed with a classical fallback, validated in staging,
     and promoted only after a documented interoperability test.

From requirement to evidence

The left column paraphrases the requirement. The middle column is our interpretation of evidence that satisfies it, not a list published by any authority.

Verify the transit claim before an assessor does

Policy statements about data in transit are the easiest to check and the easiest to get wrong, because a load balancer, a content delivery network or a legacy virtual host can quietly contradict the baseline. Read-only verification first, with OpenSSL 3.5 or later:

openssl s_client -connect www.example.com:443 -tls1_3 \
  -groups X25519MLKEM768 </dev/null 2>/dev/null | grep -i "Negotiated TLS1.3 group"

Run it against every public hostname in your register, not just the main site. If your estate is also in scope of PCI DSS, the same inventory feeds requirement 12.3.3, which has been mandatory since 2025-03-31 and asks for documented cipher suites and protocols reviewed at least every 12 months, as described in our note on the PCI DSS cryptographic inventory. One inventory, two mappings.

Four pitfalls

• Writing deadlines into the policy as if the RTS set them. Cite external timelines as review triggers and explain their status, since guidance and drafts are not obligations.
• A policy with no inventory behind it. The change provision is unverifiable without a list of assets, their cryptography and their owners.
• Treating an external scan as an attestation. A scan describes the externally visible configuration of a given endpoint at a given time. It is not a certification and not a compliance attestation.
• Freezing the algorithm list in the policy body. Keep it in an annex with its own version number, so a change in cryptanalysis does not require a full policy approval cycle.

Next step

Start with the evidence you can gather today: list your public endpoints, record which key exchange each one negotiates, and attach that output to the data in transit section of your policy. You can scan your domain with PQC Status for free to see the TLS versions, cipher suites, hybrid ML-KEM support and certificate chain an outside observer sees, then use the gaps to set target dates per asset class in Annex B. Repeat the scan after each change so the trigger log has dated before and after evidence.