Exigences NIS2 pour la sécurité des identités : ce que les équipes AD et Entra doivent prouver

Exigences NIS2 pour la sécurité des identités : partir de ce que dit réellement le texte

Si vous cherchez à comprendre les exigences NIS2 pour la sécurité des identités, la première erreur à éviter consiste à traiter NIS2 comme si c’était un guide de configuration Microsoft. Ce n’est pas le cas. La directive (UE) 2022/2555 fixe des obligations de gestion du risque et des attentes de gouvernance au niveau de l’Union. Elle ne dit pas aux équipes de déployer Microsoft Entra Privileged Identity Management, d’appliquer un modèle précis de Conditional Access, ni de fixer une longueur de mot de passe particulière dans Active Directory.

Cette distinction est essentielle, parce que les équipes identité doivent malgré tout démontrer quelque chose de concret. Même si NIS2 ne cite pas de produits Microsoft, les équipes AD et Entra doivent être capables de montrer que les accès privilégiés sont maîtrisés, que l’authentification est suffisamment robuste au regard du risque, que le contrôle d’accès est réellement appliqué en production et que la supervision permet de prouver les violations de politique ou la dérive des droits.

Cet article sépare volontairement quatre niveaux :

C’est cette séparation qui permet de produire une analyse défendable au lieu d’un article de conformité qui sur-interprète le texte.

Quelles sont réellement les exigences NIS2 pour la sécurité des identités ?

Au plus haut niveau, l’article 21(1) de NIS2 impose aux États membres de veiller à ce que les entités essentielles et importantes prennent des mesures techniques, opérationnelles et organisationnelles appropriées et proportionnées pour gérer les risques pesant sur la sécurité des réseaux et systèmes d’information. Il s’agit d’une obligation fondée sur le risque, pas d’une checklist produit.

L’identité apparaît plus directement dans l’article 21(2). Pour ce sujet, deux points comptent particulièrement :

• L’article 21(2)(i) vise les politiques et procédures permettant d’évaluer l’efficacité des mesures de gestion du risque cyber.
• L’article 21(2)(j) vise l’usage de l’authentification multifacteur ou de solutions d’authentification continue, des communications sécurisées et des systèmes de communication d’urgence sécurisés, lorsque cela est approprié.

NIS2 apporte aussi un contexte important dans le considérant 89, qui cite les pratiques d’hygiène cyber de base telles que les principes zero trust, les mises à jour logicielles, la segmentation réseau, l’identity and access management et la sensibilisation des utilisateurs. Ce considérant n’est pas une baseline Microsoft cachée. C’est un signal fort indiquant que la gouvernance des identités, l’authentification et la discipline d’accès font partie des fondamentaux attendus par les régulateurs.

La lecture prudente pour les équipes identité est donc la suivante : NIS2 ne prescrit pas un modèle éditeur unique, mais elle attend clairement des contrôles d’identité défendables, basés sur le risque, revus, et capables de réduire l’impact d’un incident.

Où l’identity and access management s’inscrit dans NIS2

Pour les équipes AD et Entra, la vraie question n’est pas « quelle fonctionnalité Microsoft est requise par NIS2 ? ». La vraie question est : « quels objectifs de sécurité des identités serions-nous incapables de prouver lors d’un contrôle ? »

Une lecture technique utile ressemble plutôt à ceci :

C’est aussi pour cela que Conformité AD & Azure : NIS2, ISO 27001, CIS reste utile. Cet article fait un mapping plus large entre plusieurs référentiels. Celui-ci se concentre sur une question plus difficile : ce qu’une équipe identité peut réellement démontrer dans un contrôle orienté NIS2.

Pourquoi le périmètre compte : NIS2, règles sectorielles et transposition nationale

C’est sur le périmètre que la plupart des articles de conformité dérapent.

D’abord, NIS2 est une directive, pas une norme produit directement auto-exécutoire. Les États membres la transposent en droit national, et les attentes de supervision dépendent en partie de cette mise en oeuvre nationale. Une équipe opérant en France, en Allemagne, en Italie ou dans un autre État membre retrouve la même base UE, mais pas nécessairement le même emballage de supervision, les mêmes documents de référence ni le même workflow d’application.

Ensuite, tous les détails techniques souvent associés à NIS2 ne viennent pas du texte de la directive elle-même. Le règlement d’exécution (UE) 2024/2690 fixe des exigences techniques et méthodologiques pour certaines catégories d’entités couvertes par l’article 21(5), notamment les fournisseurs de services DNS, les fournisseurs de cloud, les exploitants de centres de données, les managed service providers, les managed security service providers et les prestataires de services de confiance. Ce règlement est important, mais ce n’est pas un raccourci générique que l’on peut appliquer tel quel à toute organisation assujettie à NIS2.

Enfin, certaines entités relèvent aussi de textes sectoriels ou nationaux plus spécifiques. Une revue identité sérieuse dans une logique NIS2 doit donc répondre à trois questions avant même de commencer :

1. L’entité est-elle dans le périmètre NIS2, et dans quelle catégorie ?
2. Est-elle aussi couverte par des textes européens ou nationaux plus spécifiques ?
3. Quelles attentes techniques viennent de la directive elle-même, lesquelles viennent d’actes d’exécution, et lesquelles viennent de guides nationaux ?

Sans cette discipline, on finit par lire ou écrire des formules du type « NIS2 impose PIM » ou « NIS2 impose 12 caractères ». Ces affirmations ne sont pas défendables techniquement à partir du seul texte européen.

Contrôles AD et Entra qui soutiennent souvent les objectifs identité de NIS2

NIS2 ne cite ni Active Directory ni Microsoft Entra. Mais si votre environnement repose sur eux, ce sont évidemment des points où la preuve sera recherchée.

Accès privilégié

Une revue identité mature doit pouvoir montrer quels utilisateurs et groupes disposent d’un accès administratif effectif on-premises et dans Entra, comment cet accès a été accordé, et s’il reste justifié.

Cela implique généralement d’examiner :

• les appartenances directes et imbriquées dans les groupes AD privilégiés
• les principals disposant de droits équivalents à DCSync
• les droits délégués sur des objets AD sensibles, en particulier lorsque GenericAll, WriteDACL ou WriteOwner créent des chemins d’escalade
• les assignations de rôles Entra permanentes par rapport aux assignations éligibles
• les comptes qui conservent des privilèges malgré l’inactivité ou la dérive de propriété

C’est précisément pour cela que Dérive des accès privilégiés Active Directory : comment les droits admin reviennent après les audits et Acces Privilegie Azure : Trop d'Admins Globaux sont des lectures internes pertinentes. Ils ne prouvent pas la conformité NIS2 à eux seuls. Ils montrent les conditions identité qu’une équipe aurait du mal à défendre sous examen.

Robustesse de l’authentification

NIS2 donne clairement une place au MFA ou à l’authentification continue, mais la formule « lorsque cela est approprié » reste importante. Un programme identité défendable doit donc pouvoir expliquer :

• quels comptes privilégiés sont systématiquement protégés par MFA
• quels workflows d’administration et quelles applications à risque sont soumis à des contrôles d’accès renforcés
• si des chemins d’authentification legacy restent ouverts
• si le tenant repose encore sur un schéma mot de passe plus exceptions

La documentation Microsoft est utile ici, car elle explique ce qu’est réellement Conditional Access : un moteur de politique qui combine des signaux et applique des décisions d’accès. C’est donc une preuve de chemin de contrôle, pas la preuve que NIS2 aurait spécifiquement imposé Conditional Access comme produit.

De la même façon, Sécurité des Identités Azure : Pourquoi le MFA Seul ne Suffit Pas aide à poser la limite technique correctement : le MFA est important, mais une mauvaise gouvernance des rôles, des accès invités trop ouverts ou un consentement applicatif mal maîtrisé peuvent laisser subsister une exposition identité majeure.

Contrôle d’accès, comptes invités et permissions applicatives

Le périmètre identité dans NIS2 dépasse largement la simple connexion des employés. Le contrôle d’accès touche aussi les utilisateurs externes, l’accès applicatif et les délégations de droits.

Une équipe technique doit pouvoir montrer :

• comment l’accès invité est restreint
• qui est autorisé à inviter des invités
• si la collaboration cross-tenant est étroitement gouvernée ou laissée trop ouverte
• comment les permissions applicatives et le consentement sont contrôlés
• si les enterprise apps sur-privilégiées sont revues périodiquement

Ce ne sont pas des préoccupations abstraites. Microsoft documente que les application permissions peuvent accorder un accès app-only et que le consentement utilisateur ou admin détermine comment une application obtient l’accès à des ressources protégées. Microsoft documente aussi comment restreindre les paramètres de user consent pour réduire les consentements malveillants ou excessifs. C’est pour cela que Applications Azure Sur-Privilegiees dans Votre Tenant et OAuth Consent Phishing : comment les applications malveillantes contournent le vol de mot de passe doivent faire partie d’une lecture sérieuse du sujet, même si NIS2 n’emploie jamais ces noms de produits.

Quelles preuves une équipe sécurité doit être capable de produire

Un programme identité faible présente souvent de belles politiques, mais pas de dossier de preuve. Dans une logique de revue NIS2, les équipes AD et Entra doivent pouvoir produire des preuves actuelles, revoyables, et directement liées aux contrôles qu’elles prétendent appliquer.

Un package de preuve pratique comprend généralement :

C’est aussi là que Comment auditer la sécurité Microsoft Entra ID (Azure AD) : guide pratique, Audit de sécurité Active Directory : checklist pratique et Supervision Sécurité AD : Événements Clés aident à transformer le langage du cadre en étapes de revue opérationnelles.

Écarts fréquents entre politique écrite et contrôles identité réellement appliqués

Les plus gros échecs identité dans une lecture NIS2 ne viennent généralement pas d’un manque de politique écrite. Ils viennent de l’écart entre ce que la politique dit et ce que le tenant ou l’annuaire appliquent réellement.

Exemples fréquents :

• une politique de moindre privilège existe, mais il y a trop d’admins permanents dans Entra ou trop de groupes privilégiés permanents dans AD
• une politique MFA existe, mais elle laisse encore hors couverture certains workflows d’administration sensibles ou des chemins d’authentification legacy
• une politique d’accès tiers existe sur le papier, alors que les paramètres d’invitation d’invités ou les accès cross-tenant restent trop ouverts
• un processus trimestriel de revue d’accès existe, mais personne n’est capable de montrer les preuves actuelles que les revues d’invités, de groupes ou de rôles ont réellement eu lieu
• une politique de gouvernance applicative existe, mais personne ne sait produire l’état courant des permissions de service principals, des grants app-only ou des paramètres de consentement
• une politique d’audit et de supervision mentionne des contrôles, mais personne ne peut prouver l’état actuel de l’audit AD ou la couverture actuelle des Entra audit logs

C’est pour cela qu’un article NIS2 orienté identité ne doit pas finir par des slogans de gouvernance. Une équipe technique doit être capable de montrer un état appliqué, pas seulement une intention écrite.

Contexte France et ANSSI

Parce que cet article est centré UE d’abord, la France relève ici du contexte, pas du coeur normatif.

La page officielle ANSSI consacrée à NIS2 indique qu’ANSSI communiquera tout au long de la transposition nationale, que les futures entités essentielles et importantes sont encouragées à engager dès maintenant une démarche cohérente avec NIS2, et que depuis le 17 mars 2026 l’ANSSI met le Référentiel Cyber France (ReCyF) à disposition comme document de travail. L’ANSSI précise aussi que ReCyF n’est, par défaut, pas obligatoire à ce stade et qu’il correspond au cadre mentionné à l’article 14 du projet de loi Résilience.

La lecture prudente est simple :

• ReCyF n’est pas la directive NIS2 elle-même
• ReCyF ne remplace pas la lecture des textes juridiques applicables
• les entités basées en France peuvent néanmoins l’utiliser comme point de référence pratique vis-à-vis de la supervision nationale
• les équipes doivent traiter le statut de transposition française et les attentes ANSSI comme une couche nationale qui se superpose à la directive UE

Dans cette logique, Guide ANSSI Active Directory : appliquer les recommandations de sécurité en pratique est une lecture utile en complément, mais pas un substitut à l’analyse NIS2.

Remediation

Avant même la validation formelle, les équipes doivent engager une remédiation concrète sur les points qu’elles ne sauraient pas défendre lors d’un contrôle. En pratique, cela signifie réduire les privilèges permanents injustifiés, fermer les chemins d’authentification legacy encore actifs, resserrer la gouvernance des comptes invités et du cross-tenant, revoir les service principals sur-privilégiés, puis documenter l’état corrigé.

Validation après remédiation

Un programme identité réellement compatible avec une revue NIS2 doit être capable de prouver que les écarts ont été corrigés, pas seulement identifiés.

Après remédiation, les équipes doivent pouvoir produire :

1. un inventaire à jour des accès privilégiés pour AD et Entra
2. une preuve actuelle que les contrôles d’authentification forte s’appliquent là où l’organisation dit qu’ils doivent s’appliquer
3. des paramètres mis à jour pour les invités, le cross-tenant et la gouvernance applicative après changement
4. une preuve d’audit actuelle montrant que les changements d’identité restent visibles
5. une liste d’exceptions revue qui distingue le risque résiduel de la dérive ou de la négligence

Concrètement, les actions prioritaires qui améliorent le plus la défendabilité d’une posture identité sont souvent les mêmes : supprimer les privilèges permanents inutiles, refermer les accès legacy encore ouverts, revoir les comptes invités et les accès cross-tenant, inventorier les service principals sur-privilégiés, puis rerun les exports et journaux qui servent de preuve. Le but n’est pas de produire un slide de plus. Le but est de montrer qu’un contrôle annoncé existe encore réellement après correction.

C’est cette étape de validation qui sépare un exercice ponctuel de conformité d’une revue capable de tenir au prochain cycle d’audit.

Comment EtcSec aide à mesurer les écarts identité pertinents pour NIS2

Il faut positionner EtcSec de manière étroite ici.

Le point n’est pas de dire qu’EtcSec « prouve la conformité NIS2 ». Le point est qu’EtcSec aide à mesurer des écarts techniques d’identité qui comptent souvent lorsque l’équipe doit démontrer que les contrôles d’accès, d’authentification, de gouvernance des privilèges et de supervision sont effectivement appliqués.

Exemples :

• EXCESSIVE_PRIVILEGED_ACCOUNTS
• PRIVILEGED_ACCOUNT_STALE
• DANGEROUS_GROUP_NESTING
• DCSYNC_CAPABLE
• ACL_GENERICALL
• CA_NO_MFA_REQUIREMENT
• PA_PIM_NOT_ENABLED
• GUEST_INVITATION_UNRESTRICTED
• B2B_CROSS_TENANT_OPEN
• AZ_SECURITY_DEFAULTS_DISABLED

Ces findings ne créent pas de présomption juridique. Ils aident l’équipe sécurité à répondre à une question plus difficile : si nous affirmons que nos contrôles d’identité sont fondés sur le risque et réellement appliqués, quelle preuve technique actuelle soutient cette affirmation ?

Références primaires

• Directive (UE) 2022/2555 (NIS2) — EUR-Lex
• Règlement d’exécution (UE) 2024/2690 — EUR-Lex
• Résumé juridique EUR-Lex sur la cybersécurité des réseaux et systèmes d’information
• ANSSI : La directive NIS 2
• Microsoft Learn : What is Conditional Access?
• Microsoft Learn : What is Microsoft Entra Privileged Identity Management?
• Microsoft Learn : What are Microsoft Entra audit logs?
• Microsoft Learn : Overview of permissions and consent in the Microsoft identity platform
• Microsoft Learn : Configure how users consent to applications
• Microsoft Learn : Restrict guest access permissions in Microsoft Entra ID
• Microsoft Learn : What are access reviews?
• Microsoft Learn : Advanced security audit policy settings