Sectors · Insurance · DORA

DORA for insurers: cryptography, post-quantum risk and the data that must outlive the contract

Published 12 October 2026 · 9 min read · By Ali Korsi Insurers keep some of the most sensitive data in the financial sector, for longer than almost anyone else: health records, life policies that run for decades, claims files kept long after they close. That makes the post-quantum question for an insurer less about payments and more about time.

Lire en français

Why insurers have a time problem

Data that outlives the contract. Life and pension policies can run for decades, and claims, medical and underwriting files are kept for years after a policy ends. Anything sent today under RSA or elliptic-curve key exchange can be recorded and decrypted later: that is harvest-now-decrypt-later, and an insurer’s retention periods are exactly what makes it a present risk.
Special-category data. Health data is special-category personal data under the GDPR, and encryption is one of the measures Article 32 names for securing processing. A future decryption of today’s traffic would be a breach of data that was supposed to be protected.
Signatures that must stay valid. Policies, endorsements and claims settlements are signed electronically and archived. If a document must remain verifiable for the life of the contract, its signature scheme has to survive that long too — the case for ML-DSA or, for archives, SLH-DSA.
A wide partner ecosystem. Brokers, agents, bancassurance partners, comparison sites, third-party administrators, repair and medical networks all exchange data with the insurer, each over its own connections and certificates.

The EU post-quantum roadmap expects inventories by the end of 2026 and high-risk use cases migrated by the end of 2030. For an insurer, flows carrying health, life and claims data are the obvious high-risk cases.

What DORA requires for cryptography

DORA (Regulation 2022/2554) has applied since 17 January 2025 and covers insurance and reinsurance undertakings as well as many intermediaries; the smallest firms are excluded or face lighter requirements, so check your own scope. The ICT risk-management chapter is made concrete by the RTS in Delegated Regulation 2024/1774. The provisions that bear on cryptography, read for an insurer:

Provision	What it means for an insurer	Evidence to prepare
DORA Art. 5 Governance	The management body owns the ICT risk-management framework. Quantum risk to long-lived policyholder data is a board decision, and can be reflected in operational-risk assessments such as the ORSA.	A board paper on cryptographic and quantum exposure, with owners and decisions recorded.
DORA Art. 8 Identification	ICT and information assets must be identified, classified and documented, including the systems that hold health, life and claims data.	A cryptographic inventory linked to the asset inventory, data classification and retention periods.
DORA Art. 9 Protection and prevention	Protect data at rest, in use and in transit; strong authentication; protection of cryptographic keys, with encryption based on classification and risk.	A mapping of data classes (health, financial, identity) to the cryptography protecting them, with gaps listed.
RTS Art. 6 Encryption and cryptographic controls	A documented encryption and cryptographic-controls policy driven by classification and risk, providing for cryptographic technology to be updated as cryptanalysis develops.	The policy, plus a record of how quantum cryptanalysis is monitored and how retention periods feed decisions.
RTS Art. 7 Cryptographic key management	Key management across the lifecycle and a register of certificates and certificate-storing devices, at least for assets supporting critical or important functions.	Key-management procedures and a generated certificate register covering partner and broker connections.
DORA Art. 28 ICT third-party risk	The register of information on ICT third-party providers. Policy-administration platforms, claims systems, document and e-signature services are often outsourced or SaaS.	Supplier post-quantum roadmaps tracked against the register, and PQC clauses in new contracts.
DORA Art. 24–27 Testing	Resilience testing, and threat-led penetration testing where an undertaking is designated, will cover cryptographic weaknesses too.	Findings on weak or deprecated cryptography closed or accepted with a documented rationale.

For the general reading of Article 9, see DORA Article 9 and the cryptographic inventory; for the banking angle on the same rules, see DORA for banks.

Where cryptography hides in an insurer

Distribution: broker and agent portals, bancassurance and comparison-site APIs, and the TLS endpoints and client certificates behind them.
Policy administration and core systems: long-lived platforms, sometimes mainframe-based, with database and backup encryption, batch file transfers and internal service-to-service TLS.
Claims: exchanges with experts, repairers, medical networks and third-party administrators, often over SFTP, APIs or e-mail encryption.
Documents and signatures: e-signature of contracts and endorsements, sealed PDFs, and the archives that keep them verifiable for years.
Health and underwriting data: medical questionnaires, tele-underwriting and the stores that hold them, usually under the strictest access and encryption rules.
Telematics and connected products: motor and home devices, their identities and update signing, where hardware lives much longer than the algorithms it was built with.
Customer channels and cloud: web and mobile apps, customer authentication, and keys held in cloud KMS services.

What supervisors are likely to ask

Insurers are supervised by their national competent authority — the ACPR in France — with EIOPA coordinating at EU level. In our reading of DORA and the RTS, a review of cryptographic controls will come down to a handful of questions:

Show us your encryption and cryptographic-controls policy, and how it follows from data classification and retention.
Where is cryptography used for the systems that support critical or important functions, and how do you know?
How are health and other special-category data protected in transit and at rest, and for how long must that protection hold?
Show us the certificate register, including connections to brokers, partners and administrators.
How do you monitor developments in cryptanalysis, including quantum computing, and what have you decided as a result?
Which critical ICT providers — policy administration, claims, e-signature, cloud — have a post-quantum roadmap?

None of these requires a finished migration. All of them require an inventory, a policy that refers to it and a plan. Our CISO readiness checklist covers the same ground in more detail.

A 90-day plan for an insurer

Weeks	Do	Output
1–4	Pick one critical or important function, for example claims handling or the broker portal. Inventory its cryptography across code, certificates and endpoints, including partner connections. Collect supplier statements.	A first CBOM and certificate list for that function; a supplier tracker.
5–8	Link findings to data classes and retention periods — health, life and claims data first. Score each asset by quantum risk and HNDL exposure. Separate production cryptography from tests and vendored code.	A risk-ranked list, with long-retention, special-category flows at the top.
9–12	Update the cryptographic-controls policy to reference the inventory, retention and post-quantum monitoring. Decide how long-term signed documents will stay verifiable. Draft a wave-based roadmap, brief the management body, add PQC requirements to new contracts.	Updated policy, signature and archive approach, roadmap, board paper and contract clauses.

Then extend function by function and regenerate the inventory on every release. Estimating the blast radius of a migration explains how to turn the inventory into waves and effort.

Where CRYPTAGION fits

CRYPTAGION builds the inventory part of this evidence. It discovers cryptography in Python, JavaScript/TypeScript, Java, Go and C/C++ source code, X.509 certificates and live TLS endpoints, with the file and line or endpoint of every finding and a scope tag that separates production code from tests and vendored code. A per-path sensitivity policy lets health or life-data systems carry a longer confidentiality lifetime, so their HNDL exposure scores higher. It exports a schema-validated CycloneDX 1.6 CBOM and a board-ready PDF mapped to DORA, NIS2, the EU CRA and FIPS 203/204/205, with a wave-based roadmap. The Platform tier adds scans of AWS KMS, Azure Key Vault and GCP KMS and a CI gate. It runs on-premises or air-gapped (deployment and data flow).

What it does not see: mainframe languages such as COBOL, cryptography configured inside HSMs or SaaS platforms, and binaries or container images, which are on our roadmap. Those need supplier disclosure and manual review; ask every vendor the same question with our CBOM tool evaluation checklist.

Sources

This page reflects a practitioner reading of DORA, its RTS and related texts; it is not legal advice. Confirm obligations and scope with your compliance and legal teams. CRYPTAGION supports compliance activities; using it does not by itself establish regulatory compliance.

See it on an insurance-style stack

In a 30-minute demo we run CRYPTAGION live on a public repository that matches your stack and show the CBOM, the risk scores and the roadmap. No access to your code needed.

Request a free demo →

← All resources · Home