MFA au titre de l'article 21(2)(j) de NIS 2
NIS 2 fait de l'authentification multifactorielle une obligation à part entière. L'article 21(2)(j) est l'endroit où réside l'obligation, le §11.7 du CIR (UE) 2024/2690 précise où et avec quelle robustesse, et le §30(2)(10) BSIG l'inscrit en droit allemand.
La version courte
La MFA n'est pas facultative et n'est pas un simple plus. L'article 21(2)(j) l'inscrit sur la liste des dix mesures de cybersécurité que chaque entité essentielle et importante doit mettre en place. Le même libellé couvre également les communications vocales, vidéo et textuelles sécurisées et, le cas échéant, les communications d'urgence sécurisées au sein de votre organisation.
Le §11.7 du CIR (UE) 2024/2690 en précise le détail. Les utilisateurs doivent s'authentifier avec plusieurs facteurs ou par une authentification continue lorsque la classification de l'actif auquel ils accèdent l'exige. La robustesse de l'authentification doit correspondre à cette classification. Les actifs les plus précieux exigent une authentification plus robuste qu'un portail affichant le menu de la cafétéria.
Le §11.3.2 du CIR pose ensuite un plancher strict pour les comptes à privilèges. Des procédures robustes d'identification, d'authentification et d'autorisation (l'authentification multifactorielle est l'exemple que cite le CIR) doivent être en place par défaut pour les comptes à privilèges et d'administration des systèmes. L'Allemagne reprend l'obligation via le §30(2)(10) BSIG avec un libellé presque identique.
Article 21(2)(j) de la directive NIS 2 (2022/2555)
the use of multi-factor authentication or continuous authentication solutions, secured voice, video and text communications and secured emergency communication systems within the entity, where appropriate.
Le point (j) de la liste des dix mesures de cybersécurité. Il fait deux choses à la fois : il nomme la MFA (ou l'authentification continue) comme norme de contrôle d'accès, et il intègre les communications vocales, vidéo et textuelles internes sécurisées et les communications d'urgence dans la même obligation.
CIR (UE) 2024/2690, annexe §11.7 et §11.3
The relevant entities shall ensure that users are authenticated using multiple authentication factors or continuous authentication mechanisms for accessing the network and information systems of the relevant entities, where appropriate, in accordance with the classification of the asset to be accessed.
Le §11 est le chapitre du CIR consacré au contrôle d'accès et couvre conjointement l'article 21(2)(i) et (j). Le §11.7 est la sous-section spécifique à la MFA. Le §11.3.2(a) va plus loin pour les comptes à privilèges et d'administration : des procédures robustes d'identification, d'authentification (la MFA étant nommée comme exemple) et d'autorisation sont requises. Parce que le CIR est un règlement, il constitue un droit de l'UE directement contraignant pour les secteurs nommés à son annexe.
§30(2)(10) BSIG (Allemagne)
the use of multi-factor authentication or continuous authentication solutions, secured voice, video and text communications and secured emergency communication systems within the entity, where appropriate.
L'Allemagne reprend le texte de l'UE presque mot pour mot. L'opérationnalisation pratique en Allemagne renvoie à l'IT-Grundschutz baustein ORP.4 (gestion des identités et des accès), qui est le catalogue de référence du BSI pour réussir l'authentification en exploitation.
MFA adaptée à la classification de l'actif
Les utilisateurs s'authentifient avec plusieurs facteurs ou par une authentification continue pour accéder à votre réseau et à vos systèmes d'information, calibrée selon la classification de l'actif qu'ils atteignent. La condition préalable implicite : vous avez classé vos actifs. Sans classification, vous ne pouvez pas respecter la règle.
Comptes à privilèges : MFA par défaut
Pour les comptes à privilèges et les comptes d'administration des systèmes, une identification, une authentification et une autorisation robustes sont obligatoires. Le CIR nomme l'authentification multifactorielle comme exemple concret. C'est le seul endroit où la MFA cesse d'être conditionnée à la classification et devient l'état par défaut.
La robustesse de l'authentification correspond à la classification
La robustesse de l'authentification doit être appropriée à la classification de l'actif auquel on accède. C'est le deuxième test. La MFA n'est pas une chose unique. SMS, TOTP applicatif, validation par notification, clés matérielles FIDO2 et authentification par certificat se situent à des échelons très différents. Plus la classification est élevée, plus l'échelon nécessaire est élevé.
Communications sécurisées, pas seulement la MFA (article 21(2)(j))
Le point (j) est plus large que l'authentification. Il nomme les communications vocales, vidéo et textuelles sécurisées et les systèmes de communication d'urgence au sein de l'entité, le cas échéant. Un déploiement de MFA seul ne clôt pas l'obligation. La visioconférence interne, la messagerie et tout canal d'urgence hors bande relèvent de la même obligation.
La classification des actifs détermine la profondeur (article 21(1))
L'article 21(1) exige des mesures appropriées et proportionnées. Le CIR en fait un test concret pour la MFA : la classification de l'actif fixe la robustesse. Un petit Stadtwerk n'a pas besoin de clés matérielles FIDO2 pour chaque portail interne. Un hôte de rebond d'un système de contrôle est une autre affaire. Le levier, c'est la classification, et non la seule taille de l'entreprise.
BSI / §30(2)(10) BSIG
L'Allemagne reprend le libellé de l'UE presque mot pour mot dans le §30(2)(10) BSIG. La référence de mise en œuvre du BSI est l'IT-Grundschutz baustein ORP.4 (gestion des identités et des accès), qui donne des exigences concrètes pour l'émission des identifiants, la MFA, la séparation des comptes à privilèges et l'accès d'urgence. Si vous mettez correctement en œuvre ORP.4, vous êtes dans le périmètre de l'obligation du §30(2)(10).
Guide de mise en œuvre technique de l'ENISA
Le TIG de l'ENISA pour le CIR parcourt le §11 en langage opérationnel clair et le met en correspondance avec ISO/IEC 27001:2022, NIST CSF 2.0, ETSI EN 319 401 et CEN/TS 18026:2024. Si vous exploitez déjà ISO 27001 (contrôles A.5.16, A.5.17, A.8.5), vous avez fait l'essentiel du chemin. Le TIG énumère également les preuves attendues par les auditeurs : politique de MFA, classification des comptes, registres d'enrôlement, registre des exceptions.
Lois nationales de transposition
Chaque État membre a sa propre transposition de NIS 2 (Pays-Bas : Cyberbeveiligingswet, Autriche : NISG, Belgique : NIS2-Wet). L'obligation de MFA elle-même est identique car elle figure dans la directive et le CIR. Ce qui diffère d'un pays à l'autre : le catalogue de référence (Grundschutz en Allemagne, BIO aux Pays-Bas, aucun catalogue formel ailleurs), le canal de notification et l'autorité de surveillance.
Nous avons la MFA sur le VPN, donc nous avons terminé.
La MFA du VPN est une voie d'accès. Le §11.7 du CIR porte sur l'accès aux actifs selon leur classification, et non sur un seul équipement de périmètre. Si un utilisateur à privilèges peut atteindre un contrôleur de domaine, une console de sauvegarde, une console d'administration cloud ou un locataire SaaS sans MFA, l'obligation n'est pas remplie. Le test, c'est la classification de l'actif derrière la porte, et non la porte par laquelle vous êtes passé.
La MFA par SMS convient à tout le monde.
Le §11.7.2 du CIR dispose que la robustesse de l'authentification doit correspondre à la classification. Le SMS et l'OTP vocal sont le facteur le plus faible : l'échange de carte SIM, l'interception SS7 et l'hameçonnage les déjouent tous. Pour un accès interne ordinaire, l'auditeur peut l'accepter. Pour les actifs les plus précieux (consoles d'administration, systèmes de contrôle, fournisseurs d'identité), vous avez besoin d'une authentification résistante à l'hameçonnage (FIDO2 / WebAuthn / carte à puce). La robustesse doit évoluer avec la classification.
Les comptes de service et système n'ont pas besoin de MFA.
Le §11.3.2(a) du CIR couvre explicitement les comptes à privilèges et les comptes d'administration des systèmes. Les comptes de service ne sont hors du périmètre de la MFA humaine que s'ils sont correctement classés et utilisent un autre contrôle robuste (identités gérées, identifiants à durée de vie courte, certificats signés, secrets émis par un coffre avec rotation). « Compte de service, impossible de faire la MFA, exempté » n'est pas une défense. Soit il est piloté par un humain (alors MFA), soit il est piloté par une machine (alors un modèle documenté d'identifiants machine).
La plupart des équipes du Mittelstand allemand commencent au même endroit : la MFA sur chaque compte administrateur d'abord (consoles d'administration cloud, administrateur de domaine, hyperviseur, sauvegarde, équipements réseau, locataires SaaS), puis la MFA sur la messagerie, puis la MFA sur le fournisseur d'identité pour tous les utilisateurs humains. Cela couvre le plancher du §11.3.2 et les lignes à haute classification d'un seul mouvement. Le reste est déployé pour tous les utilisateurs humains sur les actifs classés au cours de la première année.
Ce que les auditeurs ouvrent réellement : la liste de classification des actifs, le rapport d'enrôlement à la MFA de votre fournisseur d'identité et le registre des exceptions. Si ces trois éléments concordent, l'obligation est remplie. La lacune unique la plus profonde que nous voyons n'est pas technique, elle est documentaire : la classification des actifs manque, de sorte qu'il n'existe aucune règle indiquant quels actifs justifient quelle robustesse d'authentification. Corrigez d'abord la classification, puis le déploiement de la MFA se lit de lui-même à partir de la liste.
Le module ACC (contrôle d'accès) de la plateforme porte l'obligation du §11 de bout en bout. Vous enregistrez les actifs avec leur classification, recensez les groupes d'utilisateurs qui ont besoin d'un accès, et documentez la robustesse de l'authentification pour chaque ligne. Le même tableau répond à la fois aux tests du §11.7.1 (MFA le cas échéant) et du §11.7.2 (la robustesse correspond à la classification), et fait ressortir séparément les lignes des comptes à privilèges du §11.3.2.
L'approbation de l'inventaire de contrôle d'accès se fait nominativement. Les exceptions (le système hérité qui ne peut pas encore faire la MFA, l'intégration qui doit utiliser un compte de service) résident dans le même enregistrement avec une mesure compensatoire documentée et une date de revue. La piste d'audit et l'export de preuves de la plateforme donnent à l'auditeur les artefacts que nomme le TIG de l'ENISA : politique, classification, registre d'enrôlement, registre des exceptions, le tout au même endroit.
- Directive (UE) 2022/2555 (NIS 2), article 21(2)(j) — eur-lex.europa.eu/eli/dir/2022/2555/oj
- Règlement d'exécution (UE) 2024/2690 de la Commission (CIR), annexe §11.3 et §11.7 — eur-lex.europa.eu/eli/reg_impl/2024/2690/oj
- Loi sur le BSI (BSIG), §30(2)(10) tel que modifié par la loi de mise en œuvre de NIS2 et de renforcement de la cybersécurité
- BSI IT-Grundschutz, Baustein ORP.4 'Identitäts- und Berechtigungsmanagement'
- Guide de mise en œuvre technique de l'ENISA pour le CIR (UE) 2024/2690 (au mois de mai 2026)