Cryptographie 2026 : transport, stockage, identités et transition post-quantique, le cadre de décision pour dirigeants et RSSI

La cryptographie est devenue une décision de direction parce que la transition post-quantique, les attaques contre l’identité et les exigences européennes touchent ensemble la durée de vie des données, la continuité des services et la capacité à changer de fournisseur.

• Prioriser les données par sensibilité et durée de confidentialité attendue.
• Cartographier les protocoles, certificats, bibliothèques, clés et dépendances fournisseurs.
• Moderniser par essais compatibles et réversibles avant de basculer les systèmes critiques.
• Gouverner les accès aux clés, les méthodes de récupération et les preuves d’intégrité.

À retenir en une phrase. La crypto-agilité est la capacité à remplacer un algorithme, une clé ou un fournisseur sans refondre le système d’information ni interrompre les usages essentiels.

---

1. La transition post-quantique : décider malgré l’incertitude

1.1. Ce qui change aujourd’hui

Un ordinateur quantique cryptographiquement pertinent n’existe pas à ce jour, mais Shor menace à terme RSA et les courbes elliptiques, ce qui rend déjà rationnelle la préparation des données exposées au scénario « Store Now, Decrypt Later ».

• Menace future : un ordinateur quantique assez puissant pourrait retrouver les secrets protégés par les principaux mécanismes asymétriques actuels.
• Exposition présente : un adversaire peut conserver du trafic TLS ou VPN chiffré et attendre de disposer d’une capacité de déchiffrement.
• Règle de priorité : traiter d’abord les données dont la durée de confidentialité, ajoutée au délai de migration, chevauche un horizon de risque quantique plausible.
• Limite : cet horizon reste incertain ; un seuil universel de cinq ou dix ans donnerait une précision que l’état de la technologie ne permet pas.

La confidentialité des échanges mérite généralement le premier effort, car une interception peut être stockée dès maintenant, tandis qu’une falsification de signature exige en principe une capacité opérationnelle au moment de l’attaque.

• Échange de clés : tester en priorité les mécanismes hybrides pour TLS, VPN et accès d’administration.
• Signatures : inventorier aussi les certificats, PKI, signatures de code et firmwares, dont les cycles de remplacement peuvent être longs.
• Dépendances : demander aux éditeurs leurs formats, calendriers de support et procédures de rotation.

1.2. Des standards disponibles

Depuis août 2024, les trois premiers standards post-quantiques finalisés du NIST donnent une base de mise en œuvre, sans faire disparaître le besoin d’évaluer les protocoles, les bibliothèques et les paramètres qui les emploient.

• ML-KEM établit des secrets partagés pour protéger la confidentialité.
• ML-DSA et SLH-DSA produisent des signatures numériques avec des compromis différents de taille et de performance.
• LMS/XMSS, déjà normalisés dans SP 800-208, conviennent à certains usages de signature à état, notamment les firmwares.

Standard	Nom d’origine	Nom normalisé	Fonction	Usage principal
FIPS 203	CRYSTALS-Kyber	ML-KEM	Encapsulation de clé	Établissement de secrets, protection contre le SNDL
FIPS 204	CRYSTALS-Dilithium	ML-DSA	Signature numérique	Certificats, PKI, signature de code
FIPS 205	SPHINCS+	SLH-DSA	Signature numérique sans état	Diversification et usages à longue durée
SP 800-208	LMS / XMSS	LMS / XMSS	Signature à état	Firmwares et environnements maîtrisant strictement l’état

1.3. L’hybridation comme transition

L’ANSSI recommande pendant la transition de combiner une primitive classique éprouvée et une primitive post-quantique, afin que la construction conserve une protection si l’une des deux familles résiste, sous réserve d’un combinateur et d’une implémentation corrects.

• Assurance : la brique classique compense le recul limité sur les nouveaux algorithmes.
• Confidentialité à long terme : la brique post-quantique traite le risque que la cryptographie classique soit cassée plus tard.
• Coût : clés, chiffres et signatures plus volumineux augmentent la taille des messages et peuvent révéler des incompatibilités réseau.
• Réversibilité : les suites doivent rester négociables, observables et remplaçables selon les doctrines applicables et le support des fournisseurs.

---

2. Les données en transit : tester la chaîne entière

La migration de TLS, IPsec et SSH dépend autant des pare-feux, proxys, concentrateurs et bibliothèques que des algorithmes, car l’augmentation des messages peut faire échouer une connexion pourtant cryptographiquement correcte.

• Inventaire : recenser versions de protocoles, terminaisons TLS, équipements d’inspection et clients anciens.
• Essais : mesurer fragmentation, nombre d’allers-retours, latence, taux d’échec et comportement de repli.
• Déploiement : activer progressivement, surveiller les négociations et conserver une procédure de retour maîtrisée.

2.1. TLS 1.3 et QUIC

TLS 1.3 constitue le terrain principal des essais hybrides — Cloudflare observait début 2024 cette version sur plus de 93 % des connexions de son propre réseau — et des groupes tels que X25519MLKEM768 ajoutent assez de données au ClientHello pour exposer certains intermédiaires fragiles.

• Portée du chiffre : 93 % décrit les connexions vues par Cloudflare en 2024, pas l’ensemble universel des connexions sécurisées.
• Compatibilité : tester les chemins comportant inspection TLS, pare-feux, équilibreurs, NAT et liens à MTU réduite.
• Ossification : GREASE aide les implémentations à révéler leur intolérance aux valeurs nouvelles, sans remplacer les essais de bout en bout.
• Authentification : suivre séparément la normalisation et le support des certificats et signatures post-quantiques.

2.2. IPsec et IKEv2

Avec IPsec, l’enjeu post-quantique se concentre sur l’établissement des clés dans IKEv2 plutôt que sur le plan de données correctement configuré avec un chiffrement symétrique robuste, et plusieurs RFC fournissent les briques nécessaires à des échanges plus volumineux ou multiples.

• RFC 7383 : fragmentation des messages IKE au niveau du protocole.
• RFC 9242 : échange IKE_INTERMEDIATE pour transporter des charges supplémentaires avant l’authentification.
• RFC 9370 : négociation de plusieurs échanges de clés pour construire une solution hybride.
• RFC 8784 : clé pré-partagée post-quantique, utile comme défense supplémentaire dans certains systèmes fermés.

La mise à niveau doit viser des combinaisons réellement prises en charge par chaque client, passerelle et politique de sécurité, car la présence d’une RFC dans un firmware ne garantit ni l’interopérabilité ni le bon choix de paramètres.

• Vérifier les matrices de compatibilité et les tailles maximales de message.
• Tester renouvellement de clés, reprise après coupure et haute disponibilité.
• Refus silencieux et replis vers une suite plus faible doivent apparaître dans la supervision.

2.3. SSH

OpenSSH propose un échange de clés hybride par défaut depuis la version 9.0 et utilise mlkem768x25519-sha256 par défaut depuis OpenSSH 10.0, publié en avril 2025, ce qui permet une migration concrète dès que les deux extrémités le prennent en charge.

• Compatibilité : mettre à jour serveurs, postes administrateurs, bastions et automates avant d’exiger la nouvelle suite.
• Vérification : contrôler l’algorithme effectivement négocié plutôt que déduire la protection du seul numéro de version.
• Périmètre : l’échange de clés post-quantique protège la confidentialité de session ; il ne rend pas automatiquement post-quantiques les signatures de clés hôte ou utilisateur.

2.4. Messagerie de groupe et MLS

Le standard Messaging Layer Security (MLS, RFC 9420) organise l’établissement de clés pour les groupes asynchrones autour d’un arbre, ce qui réduit le coût des mises à jour de groupe et crée un cadre extensible sans rendre automatiquement chaque déploiement post-quantique.

• Échelle : une mise à jour suit un chemin logarithmique dans l’arbre plutôt qu’une renégociation indépendante avec chaque membre.
• Sécurité : les garanties dépendent de l’implémentation, de la gestion des identités et des suites cryptographiques choisies.
• Choix fournisseur : vérifier la version du protocole, les audits, l’interopérabilité et la feuille de route post-quantique au lieu de se fier au seul sigle MLS.

---

3. Les données au repos : algorithmes, clés et rétention

Pour les données stockées, AES reste une base solide et le NIST estime qu’AES-128 devrait demeurer sûr pendant des décennies malgré Grover, tandis qu’AES-256 apporte une marge accrue sans résoudre les risques de mauvaise gestion des clés, des nonces ou des accès.

• Algorithme : employer un mode authentifié correctement paramétré, par exemple AES-GCM selon le contexte.
• Marge : privilégier AES-256 dans une nouvelle architecture sensible lorsque son coût et sa compatibilité sont acceptables.
• Exploitation : séparer les rôles, limiter les accès, journaliser les usages et tester les rotations.

3.1. Le chiffrement en enveloppe

Le chiffrement en enveloppe sépare le traitement des données de la protection des clés maîtresses : une DEK chiffre le contenu, puis une KEK gérée centralement enveloppe cette DEK afin de limiter l’exposition de la clé la plus sensible.

• Chiffrement : l’application génère ou reçoit une DEK, chiffre les données localement et stocke le contenu avec la DEK enveloppée.
• Déchiffrement de clé : le KMS, éventuellement adossé à un HSM, utilise la KEK pour désenvelopper la DEK après autorisation.
• Déchiffrement en volume : le service autorisé utilise ensuite la DEK en clair dans sa propre mémoire ; le volume de données ne transite normalement pas par le HSM.
• Contrôles : la certification du HSM, son niveau FIPS, la rotation et la séparation des rôles se choisissent selon le risque et les exigences applicables, sans imposer universellement le niveau 3.

3.2. Souveraineté et maîtrise des clés

La maîtrise des clés réduit certains risques juridiques et opérationnels, mais aucun acronyme ne garantit à lui seul la souveraineté si le fournisseur peut encore accéder au texte clair, au composant d’exécution ou à une clé déchiffrée pendant le traitement.

• Clés gérées par le fournisseur : simplicité maximale, avec contrôle minimal du client sur l’autorisation et la révocation.
• BYOK / CMEK : meilleure gouvernance du cycle de vie, mais le fournisseur peut souvent employer la clé pour fournir le service autorisé.
• External KMS / HYOK : décision d’usage de la KEK conservée hors du fournisseur, avec des dépendances supplémentaires de disponibilité, de latence et d’intégration.
• Chiffrement côté client : protection la plus forte contre l’accès du fournisseur lorsque les clés et le texte clair restent effectivement hors de son périmètre, au prix de fonctions cloud parfois réduites.

L’arbitrage doit donc relier juridiction, localisation, architecture du traitement et capacité technique d’accès, en considérant SecNumCloud comme une qualification d’ensemble assortie d’exigences propres plutôt que comme le synonyme d’un modèle de clés.

• Classer les données et identifier les acteurs susceptibles d’accéder au clair.
• Vérifier contrats, sous-traitants, journaux d’accès, mécanismes de révocation et scénarios d’indisponibilité du KMS.
• Faire valider l’architecture et la base juridique correspondant au secteur et aux transferts concernés.

3.3. Intégrité et immutabilité des sauvegardes

Une sauvegarde récupérable combine détection cryptographique des altérations, rétention empêchant les suppressions et organisation capable de survivre à la compromission du domaine principal, car aucune de ces couches ne remplace les deux autres.

• Intégrité : hash protégé pour détecter une modification ; MAC ou signature pour authentifier la preuve selon le modèle de menace.
• Immutabilité : verrou de rétention ou stockage WORM empêchant l’écrasement et la suppression pendant une durée définie.
• Résistance au retour arrière : versionnage, index ou journaux protégés et contrôle des points de restauration.
• Récupération : copie isolée, identités d’administration séparées et exercices de restauration mesurés.

---

4. Les identités : traiter les mots de passe, le hameçonnage et la récupération

Le chantier identités offre souvent un effet rapide parce qu’il réunit trois décisions contrôlables — stockage correct des secrets, authentification liée à l’origine et suppression des replis faibles — tout en exigeant un scénario de récupération praticable.

• Protéger les mots de passe existants avec une fonction de dérivation lente et adaptée.
• Déployer WebAuthn sur les comptes à privilèges puis sur les populations exposées.
• Durcir l’enrôlement, la récupération et la révocation autant que l’authentification normale.

4.1. Stocker les mots de passe correctement

Un mot de passe doit être traité par une fonction de dérivation lente avec un sel unique, dont les paramètres sont mesurés sur l’infrastructure puis réévalués, afin qu’une fuite de base rende chaque tentative de devinette plus coûteuse.

• Argon2id constitue le choix général recommandé par OWASP.
• scrypt fournit une alternative résistante par consommation mémoire.
• bcrypt reste destiné aux systèmes hérités et impose de traiter sa limite d’entrée de 72 octets.
• PBKDF2-HMAC-SHA-256 reste pertinent quand la conformité FIPS est requise, avec un nombre d’itérations ajusté aux recommandations maintenues.

Algorithme	Usage	Repère OWASP consulté le 6 septembre 2026
Argon2id	Choix général	m = 19 MiB, t = 2, p = 1 au minimum, puis réglage par mesure
scrypt	Alternative	N = 2¹⁷, r = 8, p = 1, ou compromis équivalent documenté
bcrypt	Hérité	Facteur de travail ≥ 10 ; limite courante de 72 octets
PBKDF2-HMAC-SHA-256	Besoin FIPS	≥ 600 000 itérations selon la recommandation OWASP consultée

Un poivre ajoute une défense si son secret reste séparé de la base, par exemple dans un KMS ou un HSM, mais il exige une procédure de rotation et de récupération compatible avec le fait qu’une perte de ce secret bloque la vérification.

• Le sel est unique par mot de passe et peut être stocké avec le hash.
• Le poivre est commun à un périmètre, secret et absent de la base applicative.
• Les paramètres et la version de l’algorithme doivent accompagner chaque empreinte pour permettre une migration progressive.

4.2. Là où le MFA classique échoue

Les codes SMS, TOTP et validations push restent utiles contre le simple vol de mot de passe, mais un proxy AiTM peut relayer la connexion en temps réel et récupérer le jeton de session après une authentification pourtant réussie.

• L’utilisateur se connecte à un domaine contrôlé par l’attaquant.
• Le proxy relaie les pages et les défis du service légitime.
• Le code ou la validation MFA est transmis pendant sa période de validité.
• Le jeton de session obtenu peut ensuite être réutilisé selon les protections du service.

La réponse doit associer une authentification résistante au hameçonnage à la protection de session, car former l’utilisateur à reconnaître chaque imitation ne neutralise ni le relais en temps réel ni le vol d’un terminal déjà authentifié.

• Favoriser WebAuthn/FIDO2 pour empêcher une signature destinée au mauvais domaine.
• Réduire les méthodes de repli et surveiller les enrôlements ou récupérations inhabituels.
• Limiter la durée et la portée des sessions, puis détecter leurs réutilisations anormales.

4.3. FIDO2 et passkeys : une garantie précise

WebAuthn lie chaque identifiant public au service concerné et demande à l’authentificateur de signer un défi dans le contexte de cette origine, ce qui résiste au hameçonnage d’identifiants sans promettre une invulnérabilité du compte.

• Origine : une page sur un faux domaine ne peut pas demander une assertion valable pour le vrai service.
• Clé : la clé privée est gérée par l’authentificateur ; les passkeys multi-appareils peuvent être sauvegardées ou synchronisées, tandis que des clés matérielles peuvent rester liées à un appareil.
• Résidu de risque : récupération faible, replis, terminal compromis et vol de session restent hors de la garantie d’origine.

Les chiffres publiés par la FIDO Alliance le 7 mai 2026 indiquent une adoption large mais doivent garder leur périmètre : cinq milliards de passkeys constituent une estimation mondiale, et les 68 % de déploiement ou de déploiement en cours proviennent de 1 400 décideurs d’organisations d’au moins 500 salariés dans dix pays.

• L’estimation mondiale décrit des identifiants, pas cinq milliards d’utilisateurs distincts.
• L’enquête entreprise ne représente pas spécifiquement les PME françaises.
• Le choix de déploiement doit reposer sur la population, les terminaux et les contraintes de récupération de l’organisation.

---

5. Le cadre européen : séparer le texte, son interprétation et son état

Deux dossiers européens influencent la confiance numérique, mais ils appellent une lecture datée et précise de leur portée plutôt qu’une conclusion générale sur les autorités de certification ou le chiffrement de bout en bout.

• eIDAS 2.0 encadre notamment les certificats qualifiés d’authentification de site et leur présentation.
• Lutte contre les abus sexuels sur mineurs en ligne : une mesure temporaire et un projet de cadre permanent suivent des trajectoires distinctes.

5.1. eIDAS 2.0, QWAC et navigateurs

Selon la FAQ de la Commission européenne consultée le 6 septembre 2026, les navigateurs doivent reconnaître un QWAC et afficher de façon conviviale les données d’identité attestées, tandis que l’usage d’un QWAC par un site reste volontaire et que les navigateurs n’ont pas l’obligation d’intégrer les listes nationales de confiance.

• Obligation : reconnaissance du QWAC et présentation des données d’identité dans l’environnement du navigateur.
• Liberté technique : choix des moyens d’affichage par l’éditeur et absence d’obligation d’intégrer directement les listes de confiance.
• Débat de sécurité : les critiques sur l’incident, la révocation et la gouvernance doivent être attribuées à leurs auteurs, sans les transformer en description du texte final.

Pour les applications critiques, la mesure utile consiste à connaître ses autorités et certificats, surveiller Certificate Transparency, maintenir navigateurs et bibliothèques, puis préparer une révocation rapide ; le pinning ne convient qu’aux applications qui maîtrisent vraiment le cycle de mise à jour et de secours.

• Inventorier certificats, autorités, échéances et propriétaires opérationnels.
• Déclencher des alertes sur les émissions inattendues et tester le renouvellement.
• Réserver l’épinglage aux clients maîtrisés, avec plusieurs clés de secours et une procédure de rotation éprouvée.

5.2. Mesure temporaire et futur cadre européen

Au 6 septembre 2026, l’Union a rétabli jusqu’au 3 avril 2028 une dérogation temporaire permettant certaines détections volontaires de contenus pédocriminels, tandis que les règles permanentes restent en négociation et ne peuvent être déduites de cet accord transitoire.

• Le Conseil a donné son feu vert final à la mesure temporaire le 23 juillet 2026.
• Les amendements retenus excluent de cette mesure les communications interpersonnelles indépendantes du numéro auxquelles un chiffrement de bout en bout s’applique, s’est appliqué ou doit s’appliquer.
• Le Conseil précise que cette exclusion temporaire ne préjuge pas sa position sur le futur cadre permanent.

L’analyse côté entreprise doit distinguer la possibilité technique d’une analyse sur le terminal de ses effets sur le modèle de sécurité, la confidentialité et les obligations professionnelles, car déplacer l’inspection avant le chiffrement ne préserve pas toutes les garanties attendues de l’E2EE.

• Suivre séparément le règlement temporaire et le texte permanent.
• Identifier les services, types de communication et catégories de données réellement concernés.
• Soumettre tout mécanisme d’inspection client à une analyse de risques, de droit applicable et de gouvernance des signalements.

---

6. Où mettre l’effort en 2026 avec la Méthode Junyr™

La grille Junyr peut ordonner la progression sans constituer une certification de sécurité : Artisan traite les bases, Orchestre rend les changements pilotables et Architecte aligne durée des données, fournisseurs et gouvernance.

• Les horizons ci-dessous sont indicatifs et dépendent de l’inventaire, des contrats et des cycles de renouvellement.
• Chaque niveau doit produire des preuves vérifiables : configurations, journaux, tests et responsables.
• Aucun niveau ne dispense d’une analyse de risques adaptée au secteur.

Au niveau Artisan, l’organisation sécurise les fondations pendant un premier cycle court en traitant les identités, le stockage et la responsabilité opérationnelle.

• Corriger le stockage des mots de passe et supprimer les algorithmes rapides.
• Déployer WebAuthn sur les comptes privilégiés avec une récupération durcie.
• Vérifier le chiffrement authentifié au repos et isoler les sauvegardes critiques.
• Nommer un responsable des clés, certificats et échéances.

Au niveau Orchestre, l’organisation structure la crypto-agilité sur les cycles suivants en reliant l’inventaire aux essais, aux choix de clés et aux automatismes contrôlés.

• Cartographier flux, certificats, bibliothèques, matériels et durées de confidentialité.
• Tester les échanges hybrides TLS, IKEv2 et SSH avec une mesure d’interopérabilité.
• Choisir BYOK, External KMS ou chiffrement côté client selon le modèle de menace.
• Automatiser rotation, alertes d’expiration et contrôles de configuration.

Au niveau Architecte, l’organisation pilote la durée et les dépendances en faisant entrer les risques à long terme, la continuité et les feuilles de route fournisseurs dans ses décisions.

• Prioriser la migration post-quantique par exposition SNDL et délai de remplacement.
• Tester continuité du KMS, révocation, restauration et sortie de fournisseur.
• Intégrer les feuilles de route MLS, PKI et post-quantiques aux décisions d’achat.
• Maintenir une veille réglementaire datée avec responsables et critères de réexamen.

Junyr Agents™ peut assister les tâches répétitives d’inventaire, de surveillance et de préparation des rotations, à condition que les droits, validations et journaux soient fixés par le système et que les décisions de sécurité restent attribuées.

• Les agents collectent et rapprochent les éléments techniques.
• Les politiques déterministes limitent leurs accès et actions.
• Les responsables valident les changements de clés, de certificats et de configuration.

---

Conclusion

Une stratégie cryptographique crédible en 2026 ne repose ni sur une date de « Q-Day » ni sur une technologie présentée comme absolue, mais sur une capacité démontrable à inventorier, migrer, limiter les accès, détecter les altérations et restaurer les services.

• Commencer par les données longues, les identités privilégiées et les dépendances anciennes.
• Tester la transition post-quantique sur des chemins réels avant de l’imposer.
• Traiter séparément confidentialité, intégrité, immutabilité, disponibilité et souveraineté.
• Réexaminer les choix lorsque les standards, les textes ou le support des fournisseurs changent.

Situez votre organisation avec l’audit de maturité IA Junyr.

---

Sources : liens directs et références, mise à jour éditoriale du 6 septembre 2026

Post-quantique, standards et transition

1. NIST, NIST Releases First 3 Finalized Post-Quantum Encryption Standards
2. NIST CSRC, Post-Quantum Cryptography
3. NIST CSRC, FAQ Post-Quantum Cryptography — AES et Grover
4. Akamai, A Guide to International Post-Quantum Cryptography Standards
5. Akamai, Post-Quantum Cryptography Implementation Considerations in TLS
6. Palo Alto Networks, A Complete Guide to Post-Quantum Cryptography Standards
7. ANSSI, Follow-up position paper on Post-Quantum Cryptography (addendum 2023)

Transport (TLS, QUIC, IPsec, SSH)

8. ANSSI, Transition post-quantique du protocole TLS 1.3
9. ANSSI, Transition post-quantique de SSHv2 (PDF)
10. ANSSI, Transition post-quantique du protocole IPsec
11. DataGuidance, France: ANSSI releases guide on Post-Quantum Transition of IPsec
12. blog.ogwilliam.com, Concrete Technical Steps for Post-Quantum TLS, SSH, and IPsec
13. AWS Security Blog, Enable post-quantum key exchange in QUIC with the s2n-quic library
14. Cloudflare Blog, The state of the post-quantum Internet
15. OpenSSH, Post-Quantum Cryptography

Messagerie de groupe / MLS

16. IETF Datatracker, RFC 9420, The Messaging Layer Security (MLS) Protocol
17. Feisty Duck, RFC 9420: Messaging Layer Security
18. Gopher Security, Understanding Messaging Layer Security
19. YouTube (37C3), RFC 9420 or how to scale end-to-end encryption with Messaging Layer Security

Stockage, KMS, sauvegardes et souveraineté cloud

20. Google Cloud, Envelope encryption / Chiffrement encapsulé (Cloud KMS)
21. AWS, Protection des données dans AWS Key Management Service
22. AWS, S3 Object Lock et stockage WORM
23. Entrust, Quelles sont les meilleures stratégies de gestion des clés d’entreprise ?
24. CERT-FR (ANSSI), Secteur du cloud, État de la menace informatique (CERTFR-2025-CTI-001)
25. CNIL, Les pratiques de chiffrement dans l’informatique en nuage (cloud) public
26. ANSSI, Recommandations de déploiement d’un service IaaS OpenStack SecNumCloud (ANSSI-BP-104)

Hachage de mots de passe

27. OWASP, Password Storage Cheat Sheet
28. ANSSI / MonServiceSécurisé, Protéger les mots de passe stockés sur le service
29. ANSSI, Guide des mécanismes cryptographiques : règles et recommandations (ANSSI-PG-083)

AiTM, MFA, FIDO2 / passkeys

30. W3C, Web Authentication: An API for accessing Public Key Credentials — Level 3
31. The Hacker News, How AitM Phishing Attacks Bypass MFA and EDR, and How to Fight Back
32. Luxgap, Okta/SSO hit by vishing: how FIDO2 blocks MFA bypass
33. WorkOS, Passkeys stop phishing. Your MFA fallbacks undo it.
34. FIDO Alliance, The State of Passkeys 2026: Global Consumer and Workforce Report

eIDAS 2.0

35. Commission européenne, Questions & Answers on Trust Services under the European Digital Identity Regulation
36. EFF, eIDAS 2.0 Sets a Dangerous Precedent for Web Security
37. R Street Institute, Cybersecurity Score, European Union Electronic Identification, Authentication, and Trust Services (eIDAS 2.0)

Détection de contenus pédocriminels et E2EE

38. Conseil de l’Union européenne, Interim measure protecting children reinstated, 23 July 2026
39. European Newsroom, Privacy vs. child protection: EU’s “chat control” plans split member states
40. EFF, EU Parliament Blocks Mass-Scanning of Our Chats, What’s Next?
41. EFF, After Years of Controversy, the EU’s Chat Control Nears Its Final Hurdle: What to Know
42. EDRi, Chat Control is in the final stretch, but it could be a marathon, not a sprint
43. Tech Policy Press, How Europe’s “Chat Control” Regulation Could Compromise American Communications