Un chiffre issu des premiers retours d'expérience d'audit NIS2 en France mérite attention : dans 74 % des premières missions de conformité conduites par les autorités nationales compétentes au premier semestre 2026, la gestion des identités et des accès (IAM) a généré au moins une observation. C'est la catégorie de contrôles la plus fréquemment signalée, devant la gestion des vulnérabilités et la continuité d'activité. Ce n'est pas un accident : c'est le reflet structurel d'un écart entre la façon dont les organisations conçoivent leur périmètre de sécurité et ce que les textes imposent réellement.
Dans cet article, nous examinons pourquoi l'IAM est devenu le premier angle d'attaque des auditeurs NIS2 et DORA, quelles sont les lacunes les plus fréquentes, et comment les directeurs GRC peuvent les traiter sans restructuration architecturale complète.
Pourquoi l'IAM est au cœur de NIS2 et DORA
L'article 21 de NIS2 impose une liste de mesures de gestion des risques que les entités essentielles et importantes doivent mettre en œuvre. Parmi elles, deux touchent directement à la gestion des identités : les "politiques et procédures relatives à l'utilisation de la cryptographie et, si nécessaire, du chiffrement" et les "contrôles d'accès et gestion des actifs". DORA, dans son article 9, est plus précis encore : les politiques d'accès aux systèmes d'information doivent être fondées sur le principe du moindre privilège et revues périodiquement.
Ce cadre réglementaire ne demande pas l'IAM comme une option architecturale parmi d'autres — il le pose comme une obligation de moyens vérifiable. La conséquence directe : un auditeur NIS2 ou DORA peut demander à voir votre politique d'accès, la liste des comptes à privilèges élevés, les journaux de connexion des six derniers mois, et les comptes de prestataires actifs. Si vous ne pouvez pas produire ces éléments en quelques heures, vous avez un problème de conformité documenté.
Le paradoxe constaté dans les premières missions d'audit : beaucoup d'organisations ont des outils IAM déployés — Active Directory, un annuaire LDAP, parfois une solution MFA. Mais elles n'ont pas de politique IAM documentée, ni de processus de révision périodique des droits, ni d'inventaire des comptes à hauts privilèges tenu à jour. L'outillage existe ; la gouvernance manque. C'est précisément ce que les auditeurs cherchent.
Les trois lacunes que les auditeurs trouvent systématiquement
1. L'absence de revue périodique des droits d'accès
La revue des droits est l'exigence IAM la plus systématiquement absente dans les organisations auditées. NIS2 l'exige de manière implicite dans son obligation de "gestion des actifs" ; DORA RTS Article 9.4 l'explicite : les droits d'accès doivent être revus à intervalles réguliers et à chaque changement de rôle ou de périmètre.
En pratique, la majorité des organisations conduisent des revues ad hoc, après un incident ou avant un audit — et non de manière systématique. Le problème n'est pas l'absence de revue, c'est l'absence de preuve de revue. Un auditeur qui demande "montrez-moi la dernière campagne de revue des accès privilégiés, avec les résultats et les actions de remédiation" ne peut pas être satisfait par une réponse orale. La preuve documentée, horodatée, signée par le responsable du contrôle — c'est le seul format acceptable.
L'erreur courante : confondre l'extraction d'un rapport Active Directory avec une revue des droits. Un rapport brut de comptes et groupes n'est pas une revue — c'est une donnée brute. La revue, c'est l'analyse par les propriétaires de systèmes, la décision de révocation ou de maintien, et la traçabilité de cette décision.
2. Les comptes de prestataires non révoqués
C'est statistiquement la lacune la plus souvent associée à une observation formelle. Dans les organisations qui recourent à des prestataires IT, infogérants ou consultants externes, les comptes d'accès créés lors de missions sont rarement révoqués de manière systématique à la fin du contrat. Plusieurs facteurs l'expliquent : la révocation n'est pas dans les processus offboarding, la responsabilité n'est pas clairement assignée (IT ? achats ? RSSI ?), et les comptes dormants ne génèrent pas d'alerte visible.
Le risque réglementaire est double. D'une part, NIS2 Article 21 exige la maîtrise des accès tiers comme partie intégrante de la gestion des risques de la chaîne d'approvisionnement. D'autre part, un compte prestataire actif mais non utilisé depuis six mois est un vecteur d'attaque documenté — et sa présence dans un audit postincident crée une exposition juridique directe pour le responsable sécurité.
La solution opérationnelle n'est pas nécessairement technologique : une procédure d'offboarding qui inclut la révocation d'accès comme étape formelle, vérifiable par le RSSI, suffit à traiter l'observation. La gouvernance d'abord, l'outillage ensuite.
3. L'authentification multifacteur non universalisée
L'obligation MFA est l'une des rares exigences NIS2 que les directeurs techniques considèrent comme "déjà faite". Dans les faits, les audits révèlent régulièrement des périmètres partiels : MFA déployée sur la messagerie et le VPN, mais absente des accès à l'infrastructure (consoles cloud, interfaces d'administration, RDP). Pour DORA, le RTS Article 9.3 est explicite : l'authentification renforcée est requise pour tous les accès aux systèmes critiques, y compris les accès de maintenance.
La définition de "systèmes critiques" est plus large que la plupart des DSI ne l'anticipent. Elle inclut les systèmes de gestion des journaux (SIEM, log management), les plateformes de sauvegarde, les outils de supervision réseau, et les interfaces d'administration des solutions de sécurité elles-mêmes. Un attaquant qui compromet votre console de gestion des backups via un compte admin sans MFA peut effacer toutes vos sauvegardes sans déclencher d'alerte — c'est exactement le scénario que DORA cherche à prévenir.
Ce que les auditeurs demandent en priorité
La liste des cinq premières demandes documentaires lors d'un audit NIS2/DORA centré sur l'IAM : la politique d'accès formalisée et datée, le registre des comptes à hauts privilèges avec responsables assignés, les preuves de la dernière campagne de révision des droits, le processus d'offboarding des prestataires avec les tickets de révocation des 12 derniers mois, et la liste des systèmes critiques avec la couverture MFA par système.
Ce qui frappe dans ce périmètre, c'est qu'aucun de ces éléments n'est techniquement complexe à produire. Un outil IAM d'entreprise standard génère cinq d'entre eux en quelques heures. Ce qui manque, dans la très grande majorité des cas, c'est la décision de l'organiser et la routine de maintenance qui garantit que ces preuves sont toujours disponibles — pas seulement le jour de l'audit.
Comment aborder la mise en conformité IAM sans tout reconstruire
La mise en conformité IAM ne suppose pas le déploiement d'une solution IGA (Identity Governance & Administration) à six chiffres. La majorité des exigences auditables peuvent être couverte avec les outils existants, à condition d'ajouter trois éléments de gouvernance.
Premier élément : une politique d'accès formalisée, une page, validée par le RSSI et la direction, qui définit les principes du moindre privilège, la fréquence des revues (trimestrielle pour les hauts privilèges, semestrielle pour les accès standards), et le processus d'offboarding. Deuxième élément : un calendrier de campagnes de revue, avec un responsable nommé par système et un format de sortie documenté. Troisième élément : un registre des comptes à hauts privilèges et des comptes prestataires, tenu dans un outil quelconque (y compris un tableur structuré), avec une entrée par compte, un responsable, et une date de dernière révision.
Ces trois éléments couvrent 80 % des observations IAM documentées dans les premiers audits NIS2. Ils ne supposent aucun budget supplémentaire — seulement l'organisation et la discipline opérationnelle.
Presidio automatise ces trois processus nativement : campagnes de revue planifiées avec alertes aux propriétaires, registre des comptes à hauts privilèges synchronisé avec l'annuaire, et journalisation des actions de remédiation. Pour évaluer votre couverture IAM actuelle, contactez notre équipe — nous proposons un diagnostic ciblé de 45 minutes. Lire aussi : NIS2 : les 5 pièges de la notification d'incident en 24 heures.
Conclusion
L'IAM est devenu le premier terrain d'audit NIS2/DORA non pas parce que c'est le plus technique des contrôles, mais parce qu'il est le plus lisible pour un auditeur : les preuves sont soit disponibles, soit absentes. Il n'y a pas de zone grise. La politique existe ou elle n'existe pas ; la revue est documentée ou elle ne l'est pas ; le compte prestataire est révoqué ou il est actif.
Trois enseignements pour votre programme GRC : documentez votre politique d'accès avant tout autre chantier IAM ; imposez la révocation de compte prestataire comme étape formelle et vérifiable de chaque offboarding ; cartographiez votre couverture MFA par système critique avant votre prochain audit. Et dans votre contexte — combien de temps vous faudrait-il, aujourd'hui, pour produire la liste des comptes actifs de vos prestataires des douze derniers mois ?