DORA Article 9 and the Long-Data Problem for Financial Entities

DORA Article 9 requires financial entities to use ICT solutions that “ensure the security of the means of transfer of data” and to minimise the risk of corruption, unauthorised access and technical flaws.

For a SaaS vendor serving financial entities, this arrives indirectly but with force: your customer is obliged to demonstrate it, so the obligation lands on you through the ICT third-party provisions in Article 28 and through contract.

What has changed in 2026 is not the text. It is which questions the text is being read to require.

Why financial data raises a question retail data does not

Most discussion of encryption risk is about attacks that happen now. Post-quantum is about attacks on data captured now and decrypted later, once a cryptographically relevant quantum computer exists. The recorded traffic does not become safer with time. It becomes readable.

The exposure is therefore proportional to how long the data stays sensitive, and financial data is at the far end of that scale.

Data	Sensitivity window
Session token	Hours
Marketing analytics	Months
Payment transaction records	Years, driven by retention obligation
Customer identity and KYC files	Decades
Credit decisions, underwriting positions	Decades
Confidential corporate positions	Effectively indefinite

A financial entity retaining KYC documentation for regulatory reasons is holding data whose confidentiality must survive longer than the remaining lifetime of classical elliptic-curve cryptography, on current expectations. That is a defensible reading of “security of the means of transfer” under a standard that references risk proportionality.

This is why the question shows up from banks, insurers and payment institutions well before it shows up from a retail SaaS buyer. It is not fashion. It follows from the retention period.

What Article 9 does and does not say

Article 9 does not name algorithms, exactly as NIS2 Article 21(2)(h) does not. It requires appropriate protection and, in combination with Article 7 on ICT systems, tools and protocols, expects those to be reliable, technologically resilient and capable of dealing adequately with evolving threat conditions.

“Capable of dealing with evolving threat conditions” is the clause that does the work. It is a crypto-agility requirement in substance: can you change algorithm without re-architecting, and how quickly.

That reframes what to present. The strongest evidence is not that you have deployed a particular primitive. It is that you can change primitives on a timescale measured in weeks.

What to actually have in place

Hybrid key agreement on public endpoints. X25519MLKEM768, one configuration line, automatic fallback for clients without support. This is the deployable component and it exists today.

ssl_conf_command Groups X25519MLKEM768:X25519:prime256v1;

Certificate automation. ACME issuance with renewal decoupled from lifetime. This is your actual crypto-agility evidence: a team that turns over its entire certificate population every few weeks can execute an algorithm migration. A team renewing by hand cannot, and the tightening CA/Browser Forum ceilings make this measurable rather than theoretical.

Mail transport encryption. MTA-STS in enforce mode with TLS-RPT. Financial entities send a great deal of sensitive material by email, and the transport gap there is larger and less examined than the HTTPS one.

A written position on what is not covered. Certificate signatures are still classical. Say so, and say why it is acceptable: signature forgery must occur during a live connection, so there is no harvest-now equivalent, and public CAs do not yet issue post-quantum chains. This is a stronger answer than silence, and far stronger than a claim of being “quantum-safe”.

Endpoint inventory. Which endpoints terminate TLS and who operates them. A CDN in front of the origin means two hops, and enabling the hybrid group at the edge while the origin connection stays classical is the common half-done state.

The register-of-information angle

Financial entities maintain a register of information on contractual arrangements with ICT third-party providers, and are expected to assess the criticality of each.

The practical consequence for a vendor is that your cryptography posture gets recorded, not merely discussed in a call. Anything you assert becomes something referenced in your customer’s regulatory documentation.

Two implications. Assertions must be accurate, because a correction later is a conversation with a regulator rather than with a buyer. And externally verifiable claims are disproportionately valuable, because the customer’s assessor can confirm them without a follow-up request:

openssl s_client -connect vendor.example.com:443 -groups X25519MLKEM768
dig +short TXT _mta-sts.vendor.example.com

Where it maps across frameworks

Framework	Control
DORA	Article 9 protection, Article 7 ICT systems and tools, Article 28 third-party risk
NIS2	Article 21(2)(h) cryptography, 21(2)(e) network security
ISO/IEC 27001:2022	A.8.24 use of cryptography, A.8.20 networks security

One measurement, three mappings. For vendors serving both financial and general enterprise customers, that overlap is the argument for producing the transport-layer evidence once and mapping it, rather than answering each framework separately. How DORA and NIS2 overlap in practice.

The short version

Article 9 is about the means of transfer, and the relevant variable is how long your customer’s data stays sensitive.

For financial data that window is decades, which makes harvest-now-decrypt-later a present concern rather than a future one. Hybrid key agreement is one line. Certificate automation is the evidence that you could change again if you had to.