Schéma ENISA de certification du portefeuille EUDI : l'essentiel

Un schéma de certification aux conséquences bien réelles

Le 2 avril 2026, l'Agence de l'Union européenne pour la cybersécurité (ENISA) a publié le projet de schéma de certification cybersécurité des portefeuilles EUDI v0.4.614 et ouvert une consultation publique. Les retours des parties prenantes sont attendus jusqu'au 30 avril 2026. L'ENISA a organisé un webinaire explicatif le 8 avril 2026.

Ce n'est pas un exercice administratif obscur. Au titre du cadre eIDAS modifié, les États membres doivent fournir à leurs citoyens au moins un portefeuille européen d'identité numérique certifié avant la fin 2026. Le schéma que l'ENISA finalise en ce moment même est l'instrument par lequel cette certification sera concrètement accordée. Les portefeuilles qui le respectent, et ceux qui ne le respectent pas, conditionneront directement les attestations qu'un vérificateur pourra considérer comme dignes de confiance au lancement.

Si vous construisez ou exploitez un vérificateur, ce document mérite d'être compris — même si vous n'avez jamais à certifier quoi que ce soit vous-même.

Ce que l'ENISA certifie

Le projet de schéma est une certification cybersécurité du logiciel du portefeuille lui-même, pas de l'utilisateur final, pas du vérificateur, ni de l'écosystème global. Il évalue si une implémentation donnée de portefeuille EUDI atteint un certain seuil de sécurité face à un ensemble de menaces publié.

Le schéma s'appuie sur la fondation existante EUCC (schéma européen de certification cybersécurité fondé sur les Critères communs) tout en l'adaptant au modèle de risque spécifique d'un portefeuille mobile. Les Critères communs sont bien maîtrisés dans les univers des cartes à puce et des HSM, mais ils sont plus lourds que ce à quoi la plupart des logiciels grand public sont habitués. Une approche purement EUCC aurait impliqué un processus de certification de plusieurs années — bien trop lent pour l'échéance de décembre 2026. Le projet de schéma adopte donc une voie médiane pragmatique.

Trois choses que le projet réussit

La transparence du modèle de menaces. Le projet énumère les classes d'attaquants contre lesquelles le schéma protège, avec des notations de risque explicites. Ce choix tranche heureusement avec les approches antérieures de certification européenne, qui avaient tendance à dissimuler leur modèle de menaces derrière des délibérations internes.

Des niveaux de garantie différenciés. Tous les portefeuilles n'ont pas besoin du même seuil de sécurité. Un portefeuille qui autorise des voyages transfrontaliers ou des justificatifs bancaires à forte valeur ne porte pas le même risque qu'un portefeuille dédié uniquement à la vérification d'âge. Le projet autorise des niveaux de garantie différenciés afin que les États membres puissent calibrer.

L'alignement avec l'architecture de référence du portefeuille. Le schéma est rédigé par rapport à la version du cadre d'architecture et de référence du portefeuille EUDI (ARF) actuellement en discussion, ce qui garantit que les contrôles évalués correspondent directement aux composants techniques que possède réellement un portefeuille.

Trois choses que le projet laisse ambiguës

Les exigences d'attestation à distance. Plusieurs sections évoquent la nécessité pour le portefeuille de prouver sa propre intégrité au vérificateur — par exemple via Android Key Attestation ou iOS DeviceCheck — sans définir pleinement quelles preuves sont acceptables. C'est en partie inévitable à ce stade, mais cela crée de l'incertitude pour les implémenteurs côté vérificateur qui doivent décider quels signaux d'attestation contrôler.

La question de la compatibilité avec l'open source. Le projet n'aborde pas directement la façon dont un portefeuille entièrement open source, avec des builds reproductibles, peut être certifié. Plusieurs réponses de la communauté dans la consultation militent pour un langage plus clair sur ce point. La récente divulgation autour de l'application européenne de vérification d'âge a aiguisé ce débat : si les implémentations open source doivent être admises à grande échelle, le schéma de certification doit pouvoir les accueillir sans imposer des cérémonies de certification à chaque build.

L'articulation avec les schémas nationaux. Chaque État membre dispose de son propre organisme national de certification. La manière dont le schéma de l'ENISA interagit avec les certifications nationales — s'il les supplante, cohabite avec elles, ou requiert une reconnaissance mutuelle — est évoquée mais pas pleinement détaillée.

Ce que les vérificateurs doivent faire

Le schéma de certification régit les émetteurs de portefeuilles, pas les vérificateurs. Vous n'avez pas besoin d'être certifié pour bâtir dessus. Mais le schéma façonne tout de même votre logique de vérification à deux égards concrets.

Des métadonnées dignes de confiance. Une fois le schéma en vigueur, les attestations de portefeuilles incluront des métadonnées signées indiquant la certification détenue par le portefeuille. Votre code vérificateur pourra prendre des décisions de confiance en fonction de ces métadonnées — par exemple en refusant les flux à forte valeur des portefeuilles certifiés uniquement au niveau de garantie de base.

Des scénarios de menace à anticiper. Le modèle de menaces du projet constitue une excellente liste de lectures pour le codage défensif côté vérificateur. Même si vous n'êtes pas responsable du côté portefeuille, savoir contre quelles attaques le portefeuille se protège vous dit contre quelles attaques votre vérificateur ne peut pas présumer que le portefeuille s'est déjà prémuni. Consultez notre analyse technique approfondie de la vérification eIDAS pour comprendre comment ces couches interagissent.

Comment aborder la consultation

Si vous souhaitez participer à la consultation, l'ENISA publie les modalités de réponse sur sa page certification. Les réponses utiles proviennent généralement :

• Des opérateurs de vérificateurs qui ont une expérience concrète des métadonnées d'attestation utiles à consommer.
• Des implémenteurs open source qui peuvent parler des enjeux de builds reproductibles.
• Des autorités nationales ayant des vues sur l'alignement avec les schémas nationaux.

Une lecture rapide du projet prend quelques heures. Une réponse détaillée prend plusieurs jours. Si vous ne prévoyez pas de répondre, vous pouvez tout de même tirer profit d'une lecture attentive du modèle de menaces et de la section sur la différenciation des niveaux de garantie.

Le contexte budgétaire

À noter : le travail de certification de l'ENISA est soutenu par un accord de contribution de 1,6 million d'euros signé avec la Commission européenne en février 2026, pour une durée de deux ans. L'accord s'inscrit dans le programme de travail Europe numérique 2025-2027. Il finance à la fois le développement du schéma central et le renforcement des capacités nationales pour soutenir les organismes de certification des États membres.

Cet accord de contribution importe parce qu'il signale l'anticipation par la Commission que la certification est une activité vivante et continue — pas une cérémonie unique avant l'échéance de décembre 2026. Les portefeuilles seront recertifiés, de nouvelles versions seront évaluées, et les contrôles de métadonnées côté vérificateur resteront pertinents longtemps après le lancement.

Le calendrier à venir

• 30 avril 2026 — Clôture de la consultation.
• T2 2026 — L'ENISA consolide les retours et publie le prochain projet.
• T3 2026 — Adoption formelle du schéma attendue.
• T4 2026 — Début des premières certifications de portefeuilles ; alignement des certifications nationales.
• Fin décembre 2026 — Les États membres doivent avoir au moins un portefeuille certifié en service.

Le rythme est soutenu. Réalistement, la première vague de certifications couvrira les portefeuilles en bac à sable du Palier 1 : France, Allemagne, et probablement Danemark et Irlande. Consultez notre traqueur de déploiement des États membres en avril 2026 pour connaître l'état actuel de chaque projet national.

Comment cela s'articule avec la stratégie vérificateur

Si vous planifiez le côté vérificateur de votre intégration, trois implications pratiques.

Traitez les métadonnées de certification comme une donnée d'entrée de premier plan. Ne codez pas en dur la confiance dans des émetteurs de portefeuilles spécifiques. Votre vérificateur devrait consulter les métadonnées de certification signées à chaque présentation et adapter sa logique en conséquence. Notre SDK OpenEUDI expose ces métadonnées via une interface standard précisément parce qu'elles vont jouer un rôle critique.

Anticipez le renouvellement des certifications. Un portefeuille certifié aujourd'hui peut cesser de l'être demain si une brèche change son statut. Votre vérificateur doit gérer gracieusement les portefeuilles dont la certification a été révoquée, pas planter ou rejeter tout le trafic.

Comprenez ce dont vous n'êtes pas responsable. Le schéma de certification retire toute une catégorie de préoccupations de vérification — altération côté portefeuille, extraction de clés, falsification d'attestation — de votre assiette. Savoir ce que le portefeuille garantit vous permet de concentrer votre propre durcissement sur ce qu'il ne garantit pas.

Pour le contexte réglementaire qui encadre tout cela, consultez notre décryptage du règlement d'exécution 2026/798 sur l'enrôlement des portefeuilles. Pour un article d'opinion sur la manière dont le récent cycle de divulgation valide l'approche open source retenue par l'UE, consultez Le premier vrai audit des portefeuilles open source.

---

Le vérificateur managé d'eIDAS Pro consomme automatiquement les métadonnées de certification et met à jour sa chaîne de confiance à mesure que les portefeuilles sont certifiés ou décertifiés. Si vous voulez que cette logique soit prise en charge pour vous, consultez nos offres managées.