Authentification multifacteur NIS2 : 5 classes d'accès à protéger

L'article 21 de la directive (UE) 2022/2555 liste les mesures de cybersécurité que toute entité NIS2 doit mettre en œuvre. Le point (j) en nomme une explicitement : l'authentification multifacteur. Dix-huit mois après l'entrée en vigueur, l'authentification multifacteur NIS2 a quitté le registre des « bonnes pratiques » pour celui de l'obligation légale — et le règlement d'exécution (UE) 2024/2690 a précisé quels facteurs passeront une inspection et lesquels ne passeront plus.

Le glissement n'est pas dans le nom. Il est dans l'adjectif. L'annexe du règlement d'exécution aligne NIS2 sur le consensus de supervision post-2023 partagé par l'ENISA, l'ANSSI et le BSI : le multifacteur est nécessaire mais ne suffit plus. La référence devient l'authentification résistante à l'hameçonnage — une catégorie que la directive ne nomme pas, mais sur laquelle le règlement d'exécution, les autorités nationales et la pratique de supervision convergent. Les conseils qui valident un plan article 21 en 2026 héritent de ce jugement.

1. Ce que l'article 21(2)(j) impose réellement

L'article 21(2)(j) exige « des solutions d'authentification multifacteur ou d'authentification continue, des communications sécurisées en voix, en vidéo et en texte ». La rédaction est brève, le périmètre large. Elle s'applique à toutes les entités des dix-huit secteurs visés, pas seulement à celles qui traitent des données personnelles, pas seulement à celles qui exposent un service au public.

Deux expressions chargent l'obligation. Authentification continue — le règlement d'exécution précise qu'il s'agit d'une revalidation au niveau de la session, pas seulement à la connexion initiale. Solutions — au pluriel, signal qu'une méthode unique ne couvre pas toutes les classes d'accès. La décision MFA n'est pas une case à cocher dans la console IAM. C'est un programme qui cartographie la force du facteur sur le niveau de risque, à travers toute la surface d'accès de l'entité.

Le même article rend le conseil d'administration — l'organe de direction — responsable de l'approbation de la politique qui en résulte. Voir les cinq responsabilités du conseil que les administrateurs ne peuvent déléguer pour le cadrage de gouvernance.

2. Les cinq catégories d'accès qui doivent porter le MFA

Le règlement d'exécution 2024/2690 ne liste pas littéralement « cinq catégories ». Son annexe construit l'exigence en combinant les principes de l'article 21 avec le socle technique. Traduit en surface qu'un RSSI défend réellement :

1. Accès administrateur — administrateur de domaine, racine cloud, hyperviseur, CLI d'équipement réseau. Toute session privilégiée, sur tout système, à chaque ouverture. Pas d'exception pour les « réseaux de confiance » — la segmentation est un contrôle de cloisonnement, pas un contrôle d'authentification.
2. Accès distant — VPN, RDP, bastions, SSH depuis l'extérieur du périmètre de l'entité. La vague de supervision 2024 de l'ANSSI et du BSI cible particulièrement cette catégorie — la plupart des rançongiciels qui aboutissent à une notification 72 h sont entrés par un accès distant non protégé.
3. Accès aux applications exposées — webmail, portails clients aux fonctions administratives ou financières, interfaces de service public. Clients et citoyens, pas seulement employés.
4. Accès aux données sensibles — bases de production, systèmes financiers, dossiers patients, dépôts de code source. La frontière n'est pas « le réseau interne » — c'est la frontière de rôle applicative.
5. Interfaces CI/CD et infrastructure-as-code — Git sur l'orchestrateur de build, clés de déploiement, gestionnaire de secrets. Cette catégorie est plus jeune et moins codifiée, mais une attaque chaîne d'approvisionnement réussie y entre de plus en plus. La logique qui justifie les clauses fournisseur NIS2 dans les contrats critiques s'étend aux pipelines internes.

Quand un superviseur demande « où le MFA est-il appliqué ? », la réponse doit être une liste, pas « partout ». La liste est l'artefact d'audit.

3. Pourquoi SMS et TOTP ne suffisent plus seuls

L'annexe du règlement d'exécution ne mentionne ni SMS ni TOTP nommément. Elle renvoie la spécification technique à « l'état de l'art », une formule que la directive utilise à dessein pour rester actuelle. Lu en 2026, l'état de l'art pour les classes d'accès à haut risque, c'est l'authentification résistante à l'hameçonnage : clés de sécurité FIDO2 / WebAuthn, authentificateurs de plate-forme avec attestation (Windows Hello for Business, Touch ID macOS avec attestation, Android récent avec strong-box), et passkeys synchronisées via des clouds attestés par le fournisseur.

Le multifacteur est le mot de la directive. Résistant à l'hameçonnage est le mot que toute autorité de supervision publie depuis 2023. Les entités NIS2 doivent planifier sur le second.

Les recommandations d'authentification de l'ANSSI (Recommandations relatives à l'authentification multifacteur et aux mots de passe, 2023), le contrôle ORP.4.A23 du référentiel IT-Grundschutz du BSI, et les publications de l'ENISA sur la gestion d'identité convergent : les codes SMS sont vulnérables au SIM swap et à l'interception SS7 ; les applications TOTP ne protègent de l'hameçonnage que si l'utilisateur remarque un domaine erroné. Pour les accès administrateur et distants, aucun de ces facteurs n'atteint la barre implicite « état de l'art » qu'un superviseur appliquera en 2026.

La conséquence pratique : le plan de déploiement hérite d'une architecture cible. Résistant à l'hameçonnage pour les trois premières classes (administrateur, distant, applications administratives exposées), TOTP toléré comme contrôle transitoire pour la quatrième (accès aux données sensibles par les employés non privilégiés), SMS sorti du périmètre avant la fin du prochain cycle budgétaire. La SP 800-63B Digital Identity Guidelines du NIST — formellement un standard américain, mais la référence internationale en niveaux d'assurance d'authentification — fournit la granularité pour documenter ces décisions.

4. La trace d'audit qu'un superviseur lit

Une inspection NIS2 demande rarement à voir la configuration de l'IdP. Elle demande la trace d'audit. Trois artefacts reviennent systématiquement dans les comptes rendus d'inspection publiés par le BSI et l'ACN :

• La politique d'authentification approuvée par le conseil. Un document — pas une page de wiki — qui définit la force du facteur par classe d'accès, liste les exceptions et leurs contrôles compensatoires, et est signé à la date de la dernière revue.
• Le registre d'enrôlement des facteurs. Une liste, par système, des comptes ayant enrôlé un facteur MFA, le type de facteur et la date d'enrôlement. Le registre répond à « le MFA est-il réellement activé ? » — pas à « est-il requis ? », ce qu'une politique seule ne peut prouver.
• Le journal des exceptions. Tout système où le MFA n'est pas appliqué — terminaux industriels hérités, comptes de service à authentification par certificat — est nommé, avec la raison, le contrôle compensatoire et la date de retrait planifiée. Les exceptions ouvertes depuis plus de douze mois sont un signal d'alerte côté superviseur.

Le renvoi à la revue indépendante annuelle du programme de sécurité dans notre guide des 21 mesures de l'article 21 boucle le dispositif — l'auditeur lit ces trois documents et rapporte ses constats au conseil. Sans eux, le contrôle technique est invisible pour le régulateur.

5. Déployer sans casser l'exploitation

Le mode d'échec d'un déploiement MFA, ce n'est pas le choix de facteur. C'est le verrouillage hors compte — un compte privilégié qui perd l'accès à son second facteur au pire moment. Trois mesures issues des guides publiés réduisent ce risque :

• Deux facteurs de deux types différents pour chaque compte administrateur, le second facteur stocké hors ligne et accessible à l'équipe de réponse à incident sous deux heures.
• Enrôlement par phase, par classe d'accès et non par population d'utilisateurs. Accès administrateur d'abord (population petite, impact élevé), applications exposées ensuite, accès aux données sensibles en dernier. La checklist d'auto-évaluation NIS2 donne l'ordre que la matrice de classification du régulateur implique.
• Procédures de break-glass pré-construites, documentées et testées chaque année. Le compte break-glass lui-même est surveillé à chaque utilisation ; un usage qui ne correspond pas à un changement planifié est traité comme un incident significatif au sens de l'article 23 et notifié.

Le schéma de supervision observé en 2026 n'est pas punitif sur la vitesse de déploiement — sous réserve que la documentation existe. Les entités qui s'appuieront encore sur SMS pour les accès administrateur en 2027 auront une conversation différente.

Ce à quoi ça ressemble quand c'est bien fait

Trois signaux reviennent dans les comptes rendus d'inspection des autorités nationales qui ont partagé leur méthodologie d'application :

1. Une politique d'authentification approuvée par le conseil — versionnée, datée, signée au titre de l'article 20 de la directive, distinguant la force du facteur par classe d'accès avec les exceptions nommées.
2. Un registre d'enrôlement vivant — exporté de l'IdP vers la plate-forme GRC de l'entité, rafraîchi au moins mensuellement, couvrant 100 % des comptes administrateur et d'accès distant.
3. Un plan de retrait des facteurs faibles — dates de dépréciation des SMS et des TOTP non attestés engagées par écrit, avec un rapport d'avancement trimestriel au conseil.

Aucun de ces documents n'exige une nouvelle technologie. Ils exigent que les contrôles déjà en production soient mis par écrit — avant que le superviseur ne les demande.

Sources

1. Directive (UE) 2022/2555, article 21(2)(j) (mesures de gestion des risques en matière de cybersécurité).
2. Règlement d'exécution (UE) 2024/2690 de la Commission du 17 octobre 2024 (exigences techniques et méthodologiques).
3. ENISA — Identity Management for Electronic Identification (référencé par nom).
4. ANSSI — Recommandations relatives à l'authentification multifacteur et aux mots de passe (2023).
5. BSI — IT-Grundschutz-Kompendium, contrôle ORP.4.A23 (authentification multifacteur pour accès administrateur).
6. NIST — Special Publication 800-63B, Digital Identity Guidelines: Authentication and Lifecycle Management.