Secteurs · Assurance · DORA

DORA pour les assureurs : cryptographie, risque post-quantique et données qui survivent au contrat

Publié le 12 octobre 2026 · 10 min de lecture · Par Ali Korsi Les assureurs conservent certaines des données les plus sensibles du secteur financier, plus longtemps que presque tout le monde : dossiers de santé, contrats vie qui courent sur des décennies, dossiers de sinistres conservés bien après leur clôture. Pour un assureur, la question post-quantique tient donc moins aux paiements qu’au temps.

Read in English

Pourquoi les assureurs ont un problème de temps

Des données qui survivent au contrat. Les contrats vie et retraite peuvent courir sur des décennies, et les dossiers de sinistres, médicaux et de souscription sont conservés des années après la fin du contrat. Tout ce qui transite aujourd’hui sous un échange de clés RSA ou sur courbes elliptiques peut être enregistré puis déchiffré plus tard : c’est le scénario « harvest now, decrypt later », et les durées de conservation d’un assureur en font un risque actuel.
Des données de catégorie particulière. Les données de santé relèvent des catégories particulières du RGPD, et le chiffrement figure parmi les mesures citées par l’article 32 pour sécuriser le traitement. Un déchiffrement futur du trafic d’aujourd’hui serait une violation de données censées être protégées.
Des signatures qui doivent rester valables. Contrats, avenants et règlements de sinistres sont signés électroniquement et archivés. Si un document doit rester vérifiable pendant toute la durée du contrat, son schéma de signature doit tenir aussi longtemps.
Un vaste écosystème de partenaires. Courtiers, agents, partenaires de bancassurance, comparateurs, gestionnaires délégués, réseaux de réparateurs et de santé échangent des données avec l’assureur, chacun avec ses propres connexions et certificats.

La feuille de route post-quantique de l’UE attend des inventaires d’ici fin 2026 et la migration des cas d’usage à haut risque d’ici fin 2030. Pour un assureur, les flux de données santé, vie et sinistres sont les cas à haut risque évidents.

Ce que DORA exige pour la cryptographie

DORA (règlement (UE) 2022/2554) s’applique depuis le 17 janvier 2025 aux entreprises d’assurance et de réassurance ainsi qu’à de nombreux intermédiaires ; les plus petites structures sont exclues ou soumises à des exigences allégées, vérifiez donc votre périmètre. Le chapitre sur la gestion du risque lié aux TIC est précisé par les RTS du règlement délégué 2024/1774. Les dispositions qui concernent la cryptographie, lues pour un assureur :

Disposition	Ce que cela implique pour un assureur	Preuves à préparer
DORA art. 5 Gouvernance	L’organe de direction porte le cadre de gestion du risque lié aux TIC. Le risque quantique sur les données de long terme des assurés est une décision de direction, qui peut être reflétée dans l’évaluation des risques opérationnels, par exemple l’ORSA.	Une note à l’organe de direction sur l’exposition cryptographique et quantique, avec responsables et décisions consignés.
DORA art. 8 Identification	Les actifs TIC et informationnels doivent être identifiés, classés et documentés, y compris les systèmes qui portent les données santé, vie et sinistres.	Un inventaire cryptographique relié à l’inventaire des actifs, à la classification et aux durées de conservation.
DORA art. 9 Protection et prévention	Protéger les données au repos, en cours d’utilisation et en transit ; authentification forte ; protection des clés, avec un chiffrement fondé sur la classification et le risque.	La correspondance entre classes de données (santé, financières, identité) et cryptographie qui les protège, écarts listés.
RTS art. 6 Chiffrement et contrôles cryptographiques	Une politique documentée de chiffrement et de contrôles cryptographiques, fondée sur la classification et le risque, prévoyant la mise à jour de la technologie cryptographique selon l’évolution de la cryptanalyse.	La politique, et la trace de la veille sur la cryptanalyse quantique et de la prise en compte des durées de conservation.
RTS art. 7 Gestion des clés cryptographiques	Une gestion des clés sur tout leur cycle de vie et un registre des certificats et des dispositifs qui les stockent, au moins pour les actifs qui soutiennent des fonctions critiques ou importantes.	Des procédures de gestion des clés et un registre des certificats généré, couvrant les connexions avec les courtiers et partenaires.
DORA art. 28 Risque lié aux prestataires TIC	Le registre d’informations sur les prestataires tiers de services TIC. Gestion des contrats, sinistres, GED et signature électronique sont souvent externalisées ou en SaaS.	Les feuilles de route post-quantiques des fournisseurs, suivies au regard du registre, et des clauses PQC dans les nouveaux contrats.
DORA art. 24 à 27 Tests	Les tests de résilience, et les tests de pénétration fondés sur la menace lorsqu’une entreprise est désignée, couvriront aussi les faiblesses cryptographiques.	Les constats sur la cryptographie faible ou obsolète clos, ou acceptés avec une justification documentée.

Pour l’angle bancaire sur les mêmes règles, voir DORA pour les banques.

Où se cache la cryptographie chez un assureur

Distribution : portails courtiers et agents, API de bancassurance et de comparateurs, et les endpoints TLS et certificats clients qui les sous-tendent.
Gestion des contrats et systèmes cœur : plateformes anciennes, parfois sur mainframe, avec chiffrement des bases et des sauvegardes, transferts de fichiers batch et TLS interne entre services.
Sinistres : échanges avec experts, réparateurs, réseaux de santé et gestionnaires délégués, souvent via SFTP, API ou messagerie chiffrée.
Documents et signatures : signature électronique des contrats et avenants, PDF scellés, et archives qui doivent les garder vérifiables pendant des années.
Données de santé et de souscription : questionnaires médicaux, télésouscription et bases qui les conservent, généralement sous les règles d’accès et de chiffrement les plus strictes.
Télématique et objets connectés : boîtiers auto et habitation, leurs identités et la signature de leurs mises à jour, avec un matériel qui vit bien plus longtemps que ses algorithmes.
Canaux clients et cloud : applications web et mobiles, authentification des clients, et clés conservées dans les services KMS des fournisseurs cloud.

Ce que les superviseurs demanderont probablement

Les assureurs sont supervisés par leur autorité nationale compétente — l’ACPR en France — avec une coordination de l’EIOPA au niveau européen. Selon notre lecture de DORA et des RTS, une revue des contrôles cryptographiques se ramène à quelques questions :

Montrez-nous votre politique de chiffrement et de contrôles cryptographiques, et comment elle découle de la classification et des durées de conservation.
Où la cryptographie est-elle utilisée pour les systèmes qui soutiennent des fonctions critiques ou importantes, et comment le savez-vous ?
Comment les données de santé et autres données de catégorie particulière sont-elles protégées en transit et au repos, et pendant combien de temps cette protection doit-elle tenir ?
Montrez-nous le registre des certificats, y compris les connexions avec courtiers, partenaires et gestionnaires délégués.
Comment suivez-vous l’évolution de la cryptanalyse, y compris l’informatique quantique, et qu’avez-vous décidé en conséquence ?
Lesquels de vos prestataires TIC critiques — gestion des contrats, sinistres, signature électronique, cloud — ont une feuille de route post-quantique ?

Aucune de ces questions n’exige une migration achevée. Toutes exigent un inventaire, une politique qui s’y réfère et un plan. Notre checklist post-quantique pour RSSI couvre le même terrain plus en détail.

Un plan à 90 jours pour un assureur

Semaines	Actions	Livrables
1 à 4	Choisir une fonction critique ou importante, par exemple la gestion des sinistres ou le portail courtiers. Inventorier sa cryptographie dans le code, les certificats et les endpoints, connexions partenaires comprises. Recueillir les déclarations des fournisseurs.	Un premier CBOM et une liste de certificats pour cette fonction ; un suivi des fournisseurs.
5 à 8	Relier les constats aux classes de données et aux durées de conservation — santé, vie et sinistres d’abord. Évaluer chaque actif selon le risque quantique et l’exposition HNDL. Séparer la cryptographie de production des tests et du code tiers.	Une liste classée par risque, les flux à longue conservation et de catégorie particulière en tête.
9 à 12	Mettre à jour la politique de contrôles cryptographiques pour qu’elle renvoie à l’inventaire, aux durées de conservation et à la veille post-quantique. Décider comment les documents signés de long terme resteront vérifiables. Rédiger une feuille de route par vagues, présenter le sujet à l’organe de direction, ajouter des exigences PQC aux nouveaux contrats.	Politique mise à jour, approche signatures et archives, feuille de route, note à la direction et clauses contractuelles.

Étendre ensuite fonction par fonction et régénérer l’inventaire à chaque version. Notre guide pour estimer le périmètre d’impact d’une migration explique comment passer de l’inventaire aux vagues et à l’effort.

La place de CRYPTAGION

CRYPTAGION produit la partie inventaire de ces preuves. Il découvre la cryptographie dans le code Python, JavaScript/TypeScript, Java, Go et C/C++, les certificats X.509 et les endpoints TLS en direct, avec le fichier et la ligne ou l’endpoint de chaque finding et une étiquette de périmètre qui distingue le code de production des tests et du code tiers. Une politique de sensibilité par chemin permet d’attribuer aux systèmes de données santé ou vie une durée de confidentialité plus longue, ce qui augmente leur score d’exposition HNDL. Il exporte un CBOM CycloneDX 1.6 validé contre le schéma et un rapport PDF pour la direction rattaché à DORA, NIS2, au CRA et à FIPS 203/204/205, avec une feuille de route par vagues. L’offre Platform ajoute l’analyse d’AWS KMS, Azure Key Vault et GCP KMS et un contrôle en CI. Il s’exécute sur site ou en environnement isolé (déploiement et flux de données).

Ce qu’il ne voit pas : les langages mainframe comme COBOL, la cryptographie configurée dans les HSM ou les plateformes SaaS, et les binaires ou images de conteneurs, qui sont sur notre feuille de route. Ces éléments exigent la transparence des fournisseurs et une revue manuelle ; posez la même question à chaque éditeur avec notre checklist d’évaluation d’un outil CBOM.

Sources

Cette page reflète une lecture de praticien de DORA, de ses RTS et des textes connexes ; elle ne constitue pas un avis juridique. Confirmez vos obligations et votre périmètre avec vos équipes conformité et juridiques. CRYPTAGION contribue aux activités de conformité ; son utilisation ne suffit pas à établir la conformité réglementaire.

Le voir sur une stack de type assurance

En 30 minutes, nous exécutons CRYPTAGION en direct sur un dépôt public proche de votre stack et montrons le CBOM, les scores de risque et la feuille de route. Aucun accès à votre code n’est nécessaire.

Demander une démo gratuite →

← Toutes les ressources · Accueil