EUDI Wallet 2026 : cinq sujets que les équipes PKI privées ne peuvent plus ignorer

Le déploiement de l'EUDI Wallet 2026 en un paragraphe

Le règlement (UE) 2024/1183, amendement couramment désigné comme eIDAS 2.0, est entré en vigueur le 20 mai 2024 et oblige chaque État membre à émettre au moins un portefeuille européen d'identité numérique (EUDI Wallet) d'ici le T4 2026. L'échéance de référence de la Commission suit les actes d'exécution publiés au titre de l'article 5a et les actes complémentaires adoptés entre novembre 2024 et 2025, qui verrouillent les exigences techniques, le périmètre de certification et les profils d'interopérabilité transfrontalière.

La spécification canonique actuelle est l'Architecture and Reference Framework (ARF) version 1.4, qui fixe les formats d'attestation (mobile driving licence (mDL) ISO/IEC 18013-5 sur OpenID for Verifiable Credentials, plus SD-JWT VC pour la divulgation sélective), les liaisons de transport (OpenID4VP pour la présentation, OpenID4VCI pour l'émission) et le modèle de confiance ancré sur les listes de confiance eIDAS (la décision d'exécution (UE) 2015/1505 s'applique toujours, étendue par l'article 22a). Quatre pilotes à grande échelle — POTENTIAL, EWC, NOBID et DC4EU — sont en cours depuis avril 2023 sous DIGITAL-2022-DEPLOY-04, avec des implémentations de référence publiées sur l'organisation GitHub EU Digital Identity.

La cryptographie de référence imposée par l'ARF reflète ce cadre : P-256 (secp256r1, OID 1.2.840.10045.3.1.7) est obligatoire pour les Wallet Instance Attestations, ECDSA avec SHA-256 est la suite de signature plancher, et l'authentification d'équipement ISO/IEC 18013-5 utilise la même courbe à travers la structure mdoc COSE_Sign1. Plus rien de tout cela n'est hypothétique.

Pourquoi « c'est pour les citoyens » n'est pas vrai pour la PKI d'entreprise

L'erreur de lecture dominante sur eIDAS 2 dans les équipes de PKI privée d'entreprise consiste à penser que le Wallet est une couche d'identité grand public maintenue par les États membres et les prestataires de services de confiance qualifiés (QTSP), et que le seul point de contact côté entreprise sera un bouton sur un site public. L'article 5b du règlement 2024/1183 contredit directement cette lecture : il exige que les « très grandes plateformes en ligne » au sens du Digital Services Act et toute partie utilisatrice privée opérant dans un secteur réglementé — banque, santé, télécoms, transport, énergie, jeux d'argent, voyages en ligne — acceptent le Wallet pour l'authentification chaque fois qu'une authentification forte du client est requise par le droit sectoriel.

La SCA de DSP2, l'obligation de vigilance client AMLD6, l'échange transfrontalier de données de santé eHDSI et le règlement Single Digital Gateway (UE) 2018/1724 convergent tous vers le Wallet comme preuve reconnue.

Pour un responsable PKI d'entreprise, cela signifie trois choses concrètes.

• D'abord, chaque parcours d'onboarding business-to-consumer (B2C) qui repose aujourd'hui sur une eID nationale, un KYC vidéo ou un scan de documents recevra des Person Identification Data (PID) et des Qualified Electronic Attestations of Attributes (QEAA) au format SD-JWT VC ou mdoc, signés par des émetteurs listés dans une liste de confiance nationale. Le logiciel de la partie utilisatrice doit valider ces signatures, remonter la chaîne jusqu'à la liste de confiance et réconcilier l'identité cryptographique avec un sujet interne. Ce moteur de validation est plus proche d'un client d'autorité de certification que d'un client OAuth, et c'est un problème de PKI.
• Ensuite, l'identité des collaborateurs pour les services B2B transfrontaliers — eDelivery, eInvoicing au titre de la directive 2014/55/UE, marchés publics au titre de la directive 2014/24/UE — sera de plus en plus exprimée sous forme d'attestations Wallet, y compris des Electronic Attestations of Attributes telles que « représentant légal de la société X, numéro d'immatriculation Y ».
• Enfin, les flux B2B réglementés dans la banque (DORA, EBA RTS sur SCA), la santé (EHDS règlement (UE) 2025/327) et les marchés publics exigeront que la partie utilisatrice honore les autorisations signées Wallet avec le même poids juridique qu'une signature électronique qualifiée au titre de l'article 25(2).

Le Wallet n'est pas un bruit grand public ; c'est un nouvel émetteur d'identifiants que votre politique PKI doit reconnaître.

Fédération d'identités : là où votre CA privée devra peut-être faire le pont

La plupart des stacks d'identité d'entreprise sont aujourd'hui un broker de fédération (Azure Entra ID, PingFederate, Keycloak, ForgeRock) parlant OIDC et SAML, devant un annuaire et une CA d'émission interne qui produit des certificats d'authentification client pour les équipements des collaborateurs. L'EUDI Wallet ne remplace pas cela ; il ajoute un plan Verifiable Credentials (VC). Les brokers doivent apprendre à consommer une présentation OpenID4VP, à valider une ou plusieurs Verifiable Presentations, à extraire des claims et à produire un jeton de session interne (id_token, assertion SAML) que les applications en aval savent déjà consommer.

La section ARF sur l'enregistrement des parties utilisatrices (ARF v1.4, sections 6.3 et 7.3.4) impose que chaque partie utilisatrice soit enregistrée dans un registre national de parties utilisatrices, avec un certificat d'accès associé émis par une autorité de certification de certificats d'accès aux parties utilisatrices. Ce certificat d'accès est un certificat X.509, profilé dans l'acte d'exécution sur l'enregistrement des parties utilisatrices Wallet, et c'est précisément là où votre CA privée pourrait avoir à faire le pont.

Concrètement, le certificat d'accès porte l'identifiant de la partie utilisatrice, l'ensemble des attributs que la partie utilisatrice est autorisée à demander (l'« intended use »), et il est signé sous une chaîne ancrée dans la liste de confiance de l'État membre. Certains États membres prévoient d'autoriser des CA d'entreprise accréditées à émettre ces certificats dans le cadre d'un accord de confiance délégué ; d'autres les émettront de manière centralisée. Dans tous les cas, votre travail sur le profil X.509 compte : le profil du certificat d'accès fixe les OID d'EKU, l'extension Subject Information Access pointant vers la fiche d'enregistrement et l'extension certificatePolicies portant l'identifiant de politique du registre. L'annexe 2 de l'ARF référence des OID en projet dans l'arc 0.4.0.194112 (ETSI) pour les extensions spécifiques au Wallet.

Si votre CA interne émet encore des certificats avec des CSR confectionnés à la main et sans mapping de politique, c'est le moment de revisiter votre gouvernance de politique de certificats et de Certification Practice Statement. La liste de confiance elle-même est publiée sous forme de document XML (ETSI TS 119 612), et votre validateur doit la récupérer, vérifier le sceau qualifié et la rafraîchir dans la fenêtre « next update ». Traitez cela comme une véritable infrastructure opérationnelle, et non comme un import trimestriel.

Flux de documents et de signature qui attendront des attestations Wallet

L'article 14 du règlement 2024/1183 amende eIDAS 1 en intégrant formellement la signature à distance dans le régime de la signature électronique qualifiée (QES) et du cachet électronique qualifié (QSeal). La combinaison de l'article 29a (service de confiance qualifié pour la gestion d'un dispositif de création de QES à distance) et du règlement d'exécution (UE) 2025/847 sur les exigences QSCD à distance signifie qu'un Wallet peut désormais héberger une clé de signature liée à un certificat qualifié, l'opération cryptographique se déroulant côté serveur dans un HSM certifié FIPS 140-3 ou EN 419 221-5, tandis que le consentement utilisateur est capturé via l'interface authentifiée du Wallet.

Le protocole technique est fixé par l'API du Cloud Signature Consortium (CSC v2.0.0.2) et l'ETSI TS 119 432 Remote Signature Protocol, tous deux référencés dans l'annexe ARF sur l'intégration QES. En pratique, lorsqu'un utilisateur signe un contrat d'achat ou une déclaration fiscale via le Wallet, la valeur de signature se matérialise sous forme de structure CAdES, PAdES ou XAdES Baseline-LTA avec un horodatage RFC 3161 embarqué émis par une TSA qualifiée.

Pour les flux de signature interne, c'est un changement modeste mais conséquent. Aujourd'hui, un workflow de signature d'entreprise typique valide face à une liste connue de fournisseurs eID nationaux et se replie sur des signatures avancées internes liées à OTP. Demain, le même workflow recevra une signature CAdES-B-LTA dont le certificat de signature aura été émis dix minutes plus tôt à une Wallet Instance pour un usage unique, avec une validité de quinze minutes et un OID certificatePolicies personnalisé.

La validation à long terme (LTV) au titre de l'ETSI TS 119 102-1 exige que vous captiez, au moment de la signature, l'état de révocation complet (CRL ou OCSP) et un instantané de la liste de confiance. Votre archive doit conserver ces artefacts pendant toute la période de rétention — dix ans pour les factures au titre de la directive 2006/112/CE, sept ans pour les dossiers AML. L'UX de signature mobile, captée via le déverrouillage biométrique du Wallet et le Signature Activation Protocol (SAP, ETSI TS 119 432 section 9) du QSCD, retire le lecteur de carte à puce de l'équation, mais elle ne retire pas l'obligation de valider. L'infrastructure interne de S/MIME et de signature d'e-mails demeure, mais perd du terrain face à la QES pilotée par Wallet partout où un contrepartie client ou transfrontalière est impliquée.

Implications crypto-agilité : courbes ECC et algorithmes de hachage

L'annexe des suites cryptographiques de l'ARF v1.4 (annexe 2, section 6.3) est plus prescriptive que la plupart des équipes PKI ne le pensent. La base obligatoire pour les Wallet Instance Attestations, les Person Identification Data et les Qualified Electronic Attestations of Attributes est ECDSA avec P-256 (secp256r1, OID NIST 1.2.840.10045.3.1.7) et SHA-256 (OID 2.16.840.1.101.3.4.2.1).

P-384 (secp384r1, OID 1.3.132.0.34) est autorisée et constitue le choix opérationnel de plusieurs implémentations d'États membres ciblant des cas d'usage à plus haut niveau d'assurance — notamment l'Allemagne, où le BSI TR-03116 recommande toujours brainpoolP256r1 (OID 1.3.36.3.3.2.8.1.1.7) et brainpoolP384r1 (1.3.36.3.3.2.8.1.1.11) pour les déploiements souverains. La France, l'Espagne et l'Italie se sont alignées sur les courbes NIST ; le pilote nordique NOBID adopte P-256 par défaut. Les courbes Edwards (Ed25519, OID 1.3.101.112) ne font pas partie de la base obligatoire, bien qu'elles apparaissent dans certains profils RP de pilote pour la clé de liaison d'équipement.

L'agilité côté hachage est tout aussi explicite. SHA-256 est le plancher obligatoire, SHA-384 est autorisée et SHA-3 (SHA3-256, OID 2.16.840.1.101.3.4.2.8) apparaît dans l'ARF comme option future, conditionnée aux recommandations de l'ENISA sur les standards cryptographiques. RSA n'est admis qu'avec le padding PSS (RSA-PSS, OID 1.2.840.113549.1.1.10) et une longueur de clé minimale de 3072 bits pour les nouveaux QSCD, conformément à SOG-IS ACM v1.3 et ETSI TS 119 312.

Pour les équipes PKI qui exploitent une CA d'émission sur RSA-2048 avec SHA-256, rien de tout cela n'est dramatique en 2026, mais cela contraint ce que vous pouvez présenter à un validateur côté Wallet et ce que votre CA doit accepter sur un CSR. Si votre CA interne ne peut pas frapper un SubjectAltName avec l'identifiant Wallet Instance basé sur URN, ne peut pas honorer l'usage du profil ARF de l'extension id-pkix-ocsp-no-check et ne peut pas faire tourner un Trust Service Token (TST) sur un cycle de quinze minutes, vous ferez du développement d'urgence au T3 2026.

Au-delà du choix de la courbe, la question post-quantique est dans la pièce. La recommandation de la Commission du 11 avril 2024 sur une feuille de route PQC coordonnée et le rapport ENISA 2024 « Post-Quantum Cryptography: Current State and Quantum Mitigation » identifient tous deux les identifiants liés à eIDAS comme candidats prioritaires aux profils de signature hybrides. L'ARF n'impose pas encore ML-DSA (FIPS 204) ou SLH-DSA (FIPS 205), mais le cadre de confiance est explicitement conçu pour accepter de nouvelles suites de signature par acte d'exécution. Un examen sérieux de la crypto-agilité et de la préparation post-quantique de votre logiciel de CA, du firmware de vos HSM (support fournisseur PKCS#11 pour CKM_ML_DSA_KEY_PAIR_GEN) et de vos consommateurs de certificats a sa place dans la feuille de route 2026, pas dans celle de 2028.

La feuille de route d'intégration sur 18 mois

Un plan à 18 mois du S2 2026 à fin 2027 devrait ressembler à ce qui suit. Il n'est pas maximaliste ; c'est le minimum pour éviter un constat réglementaire au titre des obligations de conformité réglementaire PKI adjacentes à eIDAS 2 (article 21 de NIS2, article 9 de DORA, article 13 du CRA).

• T3 2026 — Inventaire et périmètre. Cartographiez chaque flux d'onboarding, de signature et d'authentification orienté client face aux obligations d'acceptation eIDAS 2. Identifiez les flux qui déclenchent l'acceptation au titre de l'article 5b, ceux qui relèvent du droit sectoriel (SCA DSP2, AML, eSanté) et ceux qui sont hors périmètre. Inventoriez les configurations cryptographiques actuelles : profils TLS sur les points d'extrémité des parties utilisatrices, algorithmes de signature du pipeline de signature, courbes supportées dans le broker de fédération, configuration OCSP et CRL sur la CA d'émission. Confrontez-les à l'annexe 2 de l'ARF v1.4 et à l'ETSI TS 119 312. Livrable : un document de gap indexé sur l'annexe des suites cryptographiques, avec des responsables nommés par gap.
• T4 2026 — Intégration de la liste de confiance et enregistrement RP. Mettez en production un client de liste de confiance qui consomme la LOTL européenne (List of Trusted Lists), valide la signature de chaque TL nationale (ETSI TS 119 612), se rafraîchit selon la cadence « next update » et expose un magasin d'ancres de confiance interrogeable. Enregistrez l'entreprise comme partie utilisatrice dans au moins un registre RP d'État membre. Obtenez les premiers certificats d'accès. Câblez-les dans le broker de fédération. Choisissez le premier fournisseur d'intégration Wallet ou la première bibliothèque open source (EUDI Reference Wallet, sd-jwt-js, openid4vp-rs). Mettez en place un bac à sable interne connecté à un Wallet pilote (POTENTIAL, EWC, NOBID ou DC4EU).
• T1 2027 — Mise à niveau du broker de fédération. Ajoutez un endpoint vérificateur OpenID4VP au broker. Implémentez le mapping de claims des payloads SD-JWT VC et mdoc vers les attributs utilisateur internes. Définissez la relation entre un PID émis par Wallet et l'enregistrement utilisateur interne — provisionnement initial, liaison de compte, rafraîchissement d'attributs, suppression de compte. Mettez à jour les logs de consentement et d'audit pour capturer le presentation_submission OpenID4VP, le hash de la presentation vérifiable et l'instantané de la liste de confiance au moment de la validation. Confirmez la minimisation au titre de l'article 5 du RGPD en ne stockant que les claims divulgués, et non l'attestation complète.
• T2 2027 — Flux de signature et de documents. Intégrez au moins un parcours QES lié au Wallet via l'API CSC v2 face à un TSP qualifié. Mettez à jour le pipeline de validation à long terme (LTV) pour honorer les CAdES, PAdES et XAdES Baseline-LTA produits sous le nouveau profil. Vérifiez que la couche d'archive préserve l'instantané de la liste de confiance et les tokens d'horodatage qualifiés. Désactivez tout fallback hérité en signature avancée qui ne respecte plus la barre contractuelle ou réglementaire.
• T3 2027 — Crypto-agilité et revue de garde des clés. Auditez la CA d'émission face à ETSI EN 319 411-1 et 319 411-2. Confirmez le support de P-384 et des courbes brainpool pour les juridictions qui les exigent. Vérifiez que le firmware HSM expose ML-DSA et ML-KEM via les mécanismes fournisseur PKCS#11 ou via l'extension certifiée Common Criteria actuellement en préparation. Planifiez un pilote de signature hybride sur un flux non production. Rafraîchissez la politique de certificat et le CPS pour refléter formellement le périmètre d'acceptation Wallet.
• T4 2027 — Durcissement opérationnel. Exécutez un exercice red team contre la surface d'acceptation Wallet : presentations contrefaites, nonces rejoués, listes de confiance dégradées, certificats d'accès expirés, structures mdoc COSE malformées. Confirmez que les runbooks de réponse à incident au titre de l'article 17 de DORA et de l'article 23 de NIS2 couvrent les événements liés au Wallet. Formez le support et le juridique aux nouveaux types de preuves stockés dans l'archive. Validez le passage du programme en mode régime établi.

Le rôle d'Evertrust

Le déploiement de l'EUDI Wallet n'est pas un univers parallèle à la PKI privée ; c'est une extension du même appareillage X.509 et de listes de confiance que votre CA opère déjà, avec de nouveaux profils, de nouveaux consommateurs et de nouvelles obligations de validation. L'ingestion des listes de confiance, le cycle de vie des certificats d'accès, l'enregistrement RP, les pipelines de signature qualifiée et la crypto-agilité pour les familles ECC et post-quantiques sont autant de problèmes que votre plateforme CA actuelle résout déjà ou complique activement.

Les produits PKI et de gestion du cycle de vie des certificats d'Evertrust sont conçus autour de cette réalité : émission pilotée par politique pour les profils X.509 d'entreprise, support natif des suites ECC et des futures suites PQC, intégration avec les HSM et les QSCD distants alignés sur les standards ETSI, et les leviers de gouvernance opérationnelle qui rendent l'acceptation Wallet auditable plutôt qu'improvisée. Explorez la plateforme PKI Evertrust pour voir comment un socle de confiance unique peut porter à la fois votre parc de CA privées et votre surface de partie utilisatrice EUDI Wallet au cours des dix-huit prochains mois.