PAM et comptes d’accès d’urgence pour ISO 27001 en 2026

À 02 h 14 un dimanche matin, le responsable de la gestion de l’incident reçoit le message que tout RSSI redoute : « L’authentification de production échoue. La console d’administration est inaccessible. Le basculement de la base de données est bloqué. »

L’ingénieur cloud d’astreinte voit le problème, mais ne peut pas le corriger. Son rôle à privilèges habituel dépend du même fournisseur d’identité, désormais dégradé. Le responsable des opérations demande l’identifiant administrateur d’urgence. Le responsable conformité demande si le compte d’accès d’urgence a déjà été testé. Le DPO demande si l’accès à la base de données de production peut exposer des données à caractère personnel. Le RSSI pose la question qui déterminera si la situation deviendra un rétablissement maîtrisé ou un cauchemar d’audit :

« Pouvons-nous prouver qui a utilisé l’accès d’urgence, pourquoi, ce qui a été fait et que le compte a été réinitialisé ensuite ? »

Une autre organisation peut rencontrer le même problème dans une salle plus silencieuse. Le RSSI d’une FinTech fait face à des auditeurs externes après une mauvaise configuration d’une base de données cloud. L’incident a été corrigé rapidement, mais l’analyse de la cause racine n’était pas rassurante. Un développeur tiers disposait de privilèges administratifs permanents. Lorsque l’administrateur principal était indisponible, ce développeur a utilisé un compte d’accès d’urgence reposant sur un mot de passe partagé, stocké dans une note « sécurisée » accessible à l’équipe DevOps.

Les auditeurs ne se sont pas concentrés uniquement sur la mauvaise configuration. Ils ont demandé si l’accès était limité dans le temps, si la responsabilité individuelle existait, si les commandes étaient journalisées, si les données à caractère personnel étaient protégées au titre de GDPR Article 32, si les obligations DORA relatives aux risques liés aux TIC étaient respectées et si les exigences NIS2 d’hygiène cyber pouvaient être démontrées.

C’est le véritable point de pression de la gestion des accès à privilèges (PAM) et des comptes d’accès d’urgence en 2026. La PAM n’est plus un projet de niche de sécurité des identités. C’est le point de convergence entre rançongiciel, compromission du cloud, risque fournisseur, protection des données, résilience opérationnelle et éléments probants d’audit.

L’accès à privilèges est l’endroit où les attaquants cherchent à gagner. L’accès d’urgence est l’endroit où les défenseurs cherchent à rétablir l’activité. Les deux reposent sur la même capacité dangereuse : un accès élevé pouvant contourner les contrôles, modifier des configurations, lire des données sensibles, effectuer une rotation des clés, désactiver la journalisation, restaurer des sauvegardes, déployer du code ou détruire des éléments de preuve.

La position pratique de Clarysec est simple : l’accès d’urgence est nécessaire, mais un accès d’urgence non gouverné est un risque non maîtrisé. La bonne réponse n’est pas « aucun compte d’accès d’urgence ». La bonne réponse est un modèle gouverné de gestion des accès à privilèges (PAM), avec inventaire, approbation, limites temporelles, authentification forte, journalisation des sessions, revue post-utilisation, réinitialisation des identifiants et éléments probants d’audit.

Pourquoi l’accès à privilèges est un enjeu de conformité au niveau du conseil d’administration

Dans les environnements de moindre maturité, l’accès à privilèges est souvent traité comme une tâche d’administration informatique. Quelqu’un a besoin de droits administrateur, un ticket est ouvert, un rôle est accordé, puis l’activité se poursuit. Ce modèle ne résiste pas aux rançongiciels modernes, à l’infrastructure cloud native, à la responsabilité prévue par NIS2, à la résilience opérationnelle DORA ni à l’examen des violations au titre du GDPR.

La Directive NIS2 place la gouvernance de la sécurité dans la salle du conseil. Article 20 exige que les organes de direction des entités essentielles et importantes approuvent les mesures de gestion des risques de cybersécurité, supervisent leur mise en œuvre et suivent une formation en cybersécurité. Article 21 exige des mesures techniques, opérationnelles et organisationnelles appropriées et proportionnées, notamment l’analyse des risques, la gestion des incidents, la continuité d’activité, la sécurité de la chaîne d’approvisionnement, l’efficacité des contrôles, l’hygiène cyber, la sécurité RH, le contrôle d’accès, la gestion des actifs et l’authentification MFA ou l’authentification continue lorsque cela est approprié.

Pour les fournisseurs SaaS, les prestataires de services managés, les prestataires de sécurité managée, les services cloud, les centres de données et les autres organisations d’infrastructure numérique, l’applicabilité de NIS2 dépend du secteur, de la taille, du rôle, de l’impact transfrontalier et de l’établissement dans l’UE. La leçon opérationnelle est directe : le contrôle d’accès n’est plus enfoui dans une annexe technique. Il fait partie du socle d’hygiène cyber que la direction doit approuver, surveiller et corriger.

Pour les entités financières, le Digital Operational Resilience Act change le vocabulaire, mais pas le risque sous-jacent. DORA s’applique depuis le 17 janvier 2025 et établit un cadre uniforme pour la gestion des risques liés aux TIC, le signalement des incidents majeurs liés aux TIC, les tests de résilience opérationnelle numérique et la gestion des risques liés aux tiers TIC. Article 5 exige des dispositifs de gouvernance et de contrôle du risque TIC, l’organe de direction définissant, approuvant et supervisant ces dispositifs, et en assumant la responsabilité. Article 6 exige un cadre documenté de gestion des risques liés aux TIC comprenant des politiques, procédures, protocoles et outils destinés à protéger les actifs TIC. Article 17 exige un processus de gestion des incidents liés aux TIC permettant de détecter, d’enregistrer, de classifier, d’escalader et de rétablir des opérations sécurisées.

Le GDPR ajoute l’angle de la vie privée et de la responsabilité. Article 5(1)(f) exige que les données à caractère personnel soient traitées avec intégrité et confidentialité. Article 5(2) exige la responsabilité. Article 25 exige la protection des données dès la conception et par défaut. Article 32 exige des mesures techniques et organisationnelles appropriées pour la sécurité du traitement. Si un utilisateur à privilèges peut exporter des enregistrements clients, accéder à des données de catégories particulières, désactiver les journaux d’audit ou modifier des paramètres de conservation sans revue, l’organisation n’a pas seulement commis une erreur IAM. Elle peut être incapable de démontrer une sécurité appropriée.

ISO/IEC 27001:2022 constitue l’ossature du système de management qui permet de traiter ces obligations dans un programme intégré unique. La Clause 4.2 exige que l’organisation comprenne les parties intéressées et leurs exigences, y compris les obligations légales, réglementaires et contractuelles. La Clause 5.1 exige leadership et engagement. La Clause 6.1.2 exige une appréciation des risques de sécurité de l’information. La Clause 6.1.3 exige le traitement des risques. La Clause 8 exige la planification et le contrôle opérationnels.

Pour l’accès à privilèges, cela déplace la discussion de « quel outil PAM devons-nous acheter ? » vers « quels risques traitons-nous, quels contrôles sont sélectionnés, qui en est propriétaire, comment sont-ils opérés et quels éléments probants démontrent qu’ils fonctionnent ? »

La PAM n’est pas un contrôle unique, c’est une chaîne d’éléments probants

Un outil PAM peut mettre des mots de passe en coffre-fort, intermédiariser des sessions, enregistrer des frappes clavier, effectuer la rotation des identifiants et appliquer l’accès juste-à-temps. Ces capacités sont importantes. Mais si l’organisation n’a pas défini les rôles à privilèges, approuvé l’accès d’urgence, mis en correspondance les accès avec les actifs, revu les droits, protégé les journaux et formé les administrateurs, l’outil devient un contrôle partiel à faible défendabilité en audit.

La manière la plus utile de gouverner l’accès à privilèges consiste à raisonner en résultats de contrôle, et non en noms d’outils.

Le Zenith Controls: The Cross-Compliance Guide Zenith Controls traite le contrôle ISO/IEC 27002:2022 8.2, Privilèges d’accès, comme le centre de gravité de la PAM. Il classe ce contrôle comme préventif, soutenant la confidentialité, l’intégrité et la disponibilité, aligné sur la fonction de cybersécurité Protect, la capacité opérationnelle de gestion des identités et des accès, et le domaine de sécurité Protection.

Le contrôle 8.2 est puissant parce qu’il se rattache aux contrôles environnants qui rendent l’accès à privilèges auditable :

C’est pourquoi un auditeur s’arrête rarement à la question : « Disposez-vous d’un système PAM ? » Les questions d’audit plus robustes sont : disposez-vous d’un inventaire des comptes à privilèges ? Les rôles à privilèges sont-ils approuvés ? Les droits sont-ils limités dans le temps ? Les identifiants d’urgence sont-ils sécurisés ? Pouvez-vous prouver qui les a utilisés ? Les commandes sont-elles journalisées ? Les administrateurs fournisseurs sont-ils inclus ? Les droits d’accès sont-ils revus ? Les identifiants ont-ils été réinitialisés ? Les exceptions ont-elles fait l’objet d’une acceptation du risque ?

La cartographie des droits d’accès de Zenith Controls le dit directement : la gestion des droits d’accès opérationnalise les principes de contrôle d’accès tels que le moindre privilège, le besoin d’en connaître et l’autorisation, tandis que les comptes à privilèges exigent une attention particulière et une révocation rapide lorsqu’ils ne sont plus nécessaires.

Exigences de politique pour un accès d’urgence digne de confiance

Un compte d’accès d’urgence n’est pas un mot de passe administrateur partagé dans une enveloppe scellée. En 2026, ce modèle est trop faible pour le cloud, la fintech, le SaaS, la santé, les services managés et les opérations numériques réglementées.

Un modèle d’accès d’urgence défendable nécessite sept règles minimales de politique :

1. Le compte doit être documenté.
2. Le compte doit être approuvé.
3. L’utilisation doit être attribuable de manière unique lorsque cela est techniquement possible.
4. L’utilisation doit être limitée aux urgences réelles.
5. L’utilisation doit être journalisée et revue.
6. Les identifiants ou facteurs d’authentification doivent être réinitialisés ou faire l’objet d’une rotation après utilisation.
7. Le compte doit être testé et inclus dans le périmètre d’audit.

La bibliothèque de politiques Clarysec transforme ces principes en langage de gouvernance directement utilisable.

La Politique de gestion des comptes utilisateurs et des privilèges - PME Politique de gestion des comptes utilisateurs et des privilèges - PME indique :

« L’accès d’urgence, par exemple les comptes administrateur “break glass”, doit être clairement documenté, sécurisé et utilisé uniquement lorsque cela est absolument nécessaire. »

Extrait de la section « Traitement des risques et exceptions », clause 7.3.1 de la politique.

La même politique PME poursuit :

« Ces comptes doivent être journalisés, revus après utilisation et réinitialisés après chaque événement d’urgence. »

Extrait de la section « Traitement des risques et exceptions », clause 7.3.2 de la politique.

Pour l’élévation de privilèges au quotidien, la politique PME exige également :

« Les privilèges élevés ou administratifs exigent une approbation supplémentaire du directeur général ou du responsable informatique et doivent être documentés, limités dans le temps et soumis à une revue périodique. »

Extrait de la section « Exigences de mise en œuvre de la politique », clause 6.2.2 de la politique.

Pour les organisations de plus grande taille, l’ensemble de politiques d’entreprise va plus loin. La Politique de gestion des comptes utilisateurs et des privilèges Politique de gestion des comptes utilisateurs et des privilèges exige que :

« Les sessions à privilèges doivent être entièrement journalisées, y compris les commandes émises et les actions effectuées. Les journaux doivent être revus périodiquement par des réviseurs désignés. »

Extrait de la section « Exigences de mise en œuvre de la politique », clause 6.4.2 de la politique.

La même politique exige que les comptes d’accès à privilèges temporaires ou d’urgence suivent une procédure d’accès d’urgence documentée dans la clause 6.2.5, tandis que la clause 7.4 décrit les exigences applicables à cette procédure.

La Politique de contrôle d’accès Politique de contrôle d’accès renforce la conservation à des fins d’audit :

« Les décisions d’approbation doivent être journalisées et conservées à des fins d’audit pendant une durée minimale de 2 ans. »

Extrait de la section « Exigences de gouvernance », clause 5.3.2 de la politique.

La Politique de journalisation et de surveillance - PME Politique de journalisation et de surveillance - PME définit les attentes relatives à la journalisation de l’authentification :

« Journaux d’authentification : tentatives de connexion réussies et échouées, durée de session, utilisation de l’authentification MFA »

Extrait de la section « Exigences de gouvernance », clause 5.4.2 de la politique.

Ensemble, ces clauses transforment l’accès d’urgence d’un contournement héroïque en un événement maîtrisé. Le compte est exceptionnel, mais la gouvernance ne l’est pas.

L’approche Zenith Blueprint pour mettre en œuvre la PAM

Le Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint traite l’accès à privilèges comme un problème pratique de mise en œuvre, et non comme une déclaration théorique de contrôle. Dans la phase Contrôles en action, étape 19, Contrôles technologiques I, il indique :

« Dans tout système d’information, l’accès à privilèges est un pouvoir ; et ce pouvoir crée un risque. »

Extrait de la phase Contrôles en action, étape 19 : Contrôles technologiques I.

L’étape 19 exige que les organisations identifient les comptes à privilèges dans les environnements sur site, cloud, SaaS, de développement et d’infrastructure. Elle inclut les administrateurs de domaine, les utilisateurs root, les administrateurs de tenant cloud, les super-utilisateurs de bases de données et les contrôleurs de pipelines CI/CD. Elle insiste également sur la réduction de l’accès à privilèges au moyen du contrôle d’accès basé sur les rôles (RBAC), de l’élévation juste-à-temps et des workflows d’approbation.

C’est important parce que de nombreux incidents graves ne commencent pas avec le compte d’accès d’urgence formel. Ils commencent par un privilège permanent. Un ingénieur cloud conserve des droits de propriétaire « au cas où ». Un administrateur de base de données conserve un accès à l’environnement de production après avoir changé d’équipe. Un compte de service CI/CD dispose d’autorisations étendues dans plusieurs environnements. Un compte de prestataire de services managés est exempté de l’authentification MFA parce qu’« ils ont besoin d’un accès rapide ».

L’étape 20 du Zenith Blueprint étend le même raisonnement aux utilitaires à privilèges. Elle demande aux organisations de créer ou de mettre à jour un inventaire des utilitaires à privilèges, de restreindre leur exécution aux administrateurs autorisés, de vérifier que leur utilisation est journalisée et génère des alertes, et d’envisager la journalisation des scripts, par exemple la journalisation PowerShell via une stratégie de groupe. C’est essentiel parce qu’un compte à privilèges n’est souvent que le point d’entrée. Les dommages surviennent lorsque l’attaquant exécute des outils qui désactivent des contrôles, extraient des identifiants ou permettent un déplacement latéral.

L’étape 22 formalise le cycle de vie du contrôle d’accès. Elle appelle à un provisionnement et à un déprovisionnement structurés, idéalement intégrés aux RH et soutenus par des workflows de demandes d’accès, avec des revues d’accès trimestrielles documentées. L’étape 16 relie ce cycle de vie au départ en exigeant une liste de contrôle de fin de contrat utilisée conjointement par les RH et l’informatique, comprenant la désactivation des comptes, le retour des actifs et les rappels relatifs aux accords de non-divulgation.

Le Zenith Blueprint fait de la PAM un modèle opérationnel connecté : identité, RH, utilitaires à privilèges, journalisation, réponse aux incidents, revues d’accès et éléments probants d’audit se renforcent mutuellement.

Un modèle pratique de gouvernance de l’accès d’urgence pour 2026

Un processus d’accès d’urgence bien conçu doit fonctionner pendant une défaillance. S’il dépend du même fournisseur d’identité, de la même plateforme de ticketing et du même service de messagerie indisponibles pendant la panne, ce n’est qu’une mise en scène.

Dans le même temps, l’accès d’urgence ne doit pas devenir un canal de contournement par commodité. Clarysec conçoit généralement la gouvernance de l’accès d’urgence autour de quatre couches : prévention, activation, observation et rétablissement.

Pour les environnements cloud, incluez les administrateurs au niveau du tenant, les comptes root cloud, les administrateurs d’urgence des fournisseurs d’identité, les comptes de service à privilèges, les utilisateurs maîtres de bases de données, les rôles cluster-admin Kubernetes, les clés de déploiement CI/CD, les administrateurs de coffres-forts de secrets et les comptes de support tiers.

Pour les environnements hybrides, incluez les administrateurs de domaine, les administrateurs de sauvegarde, les administrateurs d’hyperviseurs, les administrateurs de pare-feu, les administrateurs de consoles EDR et les utilisateurs d’utilitaires à privilèges.

Pour les environnements sensibles du point de vue de la vie privée, incluez les administrateurs pouvant accéder aux bases de données contenant des données à caractère personnel, aux journaux contenant des identifiants, aux dossiers RH, aux données de vérification biométrique d’identité, aux systèmes de surveillance de la fraude ou aux outils de support client.

L’état cible est simple à décrire et difficile à simuler : chaque chemin d’urgence est connu, approuvé, sécurisé, observable, réversible et revu.

Un exercice de collecte d’éléments probants d’accès d’urgence en 60 minutes

Un RSSI ou un responsable conformité peut réaliser cette semaine un exercice utile d’accès d’urgence sans acheter de nouvel outil. L’objectif n’est pas seulement de confirmer que le compte fonctionne. L’objectif est de prouver que le contrôle produit des éléments probants.

Scénario

Supposons que le fournisseur d’identité principal soit dégradé. L’élévation juste-à-temps normale est indisponible. Un cluster de bases de données de production nécessite des changements de configuration d’urgence pour rétablir le service. Le compte administrateur cloud d’accès d’urgence doit être activé.

Étape 1 : confirmer que le compte figure dans l’inventaire des comptes à privilèges

Utilisez le Zenith Blueprint, phase Contrôles en action, étape 19, pour valider que le compte figure dans l’inventaire des comptes à privilèges. Enregistrez le nom du compte et l’environnement, le propriétaire métier, le propriétaire technique, les systèmes accessibles, l’impact sur les données à caractère personnel, la méthode d’authentification, l’emplacement du coffre-fort, la méthode de rotation et la date du dernier test.

Si le compte est absent, traitez cette absence comme une lacune de contrôle et ajoutez-la au registre des risques.

Étape 2 : vérifier l’alignement avec la politique

Mettez l’événement en correspondance avec les exigences de la Politique de gestion des comptes utilisateurs et des privilèges relatives aux procédures d’accès d’urgence documentées et à la journalisation des sessions à privilèges. Si vous êtes une PME, utilisez les clauses 7.3.1 et 7.3.2 de la Politique de gestion des comptes utilisateurs et des privilèges - PME comme référentiel minimal : documenté, sécurisé, nécessaire, journalisé, revu et réinitialisé.

Mettez la conservation des approbations en correspondance avec la clause 5.3.2 de la Politique de contrôle d’accès, qui exige que les décisions d’approbation soient journalisées et conservées pendant au moins 2 ans.

Étape 3 : ouvrir un enregistrement d’accès d’urgence

Créez un ticket ou un enregistrement d’incident avant l’activation ou au moment de celle-ci. Incluez :

• Motif de l’urgence
• Service impacté
• Compte demandé
• Demandeur
• Approbateur
• Heure de début
• Heure de fin prévue
• Impact client ou réglementaire
• Impact GDPR sur les données à caractère personnel
• Indicateur de surveillance pour le signalement NIS2 ou DORA

N’attendez pas la fin pour reconstruire l’histoire. La valeur d’audit est maximale lorsque l’enregistrement commence avant l’utilisation de l’accès.

Étape 4 : activer et observer

Activez le compte d’accès d’urgence. Confirmez que l’authentification MFA ou une authentification compensatoire est utilisée, que la session est enregistrée, que les commandes ou actions administratives sont journalisées, que les journaux sont transférés vers la journalisation centralisée, que la synchronisation temporelle permet de reconstruire la chronologie et qu’une alerte est générée lors de l’utilisation du compte d’urgence.

Cela s’aligne sur Zenith Controls pour 8.15 Journalisation, qui décrit la journalisation comme la couche de données fondamentale de la surveillance et précise que les utilisateurs à privilèges et l’exécution d’utilitaires à privilèges doivent faire l’objet d’une journalisation complète.

Étape 5 : clôturer, réinitialiser et revoir

Après la tâche d’urgence, désactivez le compte ou remettez-le à l’état scellé, effectuez la rotation des identifiants ou réinitialisez le facteur d’authentification, revoyez les journaux de session, documentez les commandes et les changements de configuration, confirmez qu’aucun accès non nécessaire aux données n’a eu lieu, mettez à jour l’enregistrement d’incident, consignez les enseignements tirés et déterminez si les seuils de notification NIS2, DORA ou GDPR sont déclenchés.

Si des données à caractère personnel ont été consultées, impliquez le DPO. Si l’événement a provoqué une interruption de service ou pourrait entraîner un impact significatif, impliquez le responsable du signalement NIS2 ou DORA. Si le compte d’accès d’urgence a échoué, documentez l’échec comme un constat de résilience opérationnelle, et pas seulement comme un problème IAM.

Cartographie de conformité croisée pour les contrôles PAM et d’accès d’urgence

Le modèle de gouvernance le plus solide ne duplique pas les contrôles pour chaque réglementation. Il construit une chaîne unique d’éléments probants qui soutient plusieurs obligations.

NIST CSF 2.0 est particulièrement utile pour traduire la PAM en profil actuel et en profil cible. Sa méthode de profil commence par le périmètre, puis rassemble les politiques, priorités de risque, registres, exigences, pratiques et rôles professionnels, avant de créer un plan d’action priorisé. Pour l’accès à privilèges, cela signifie définir le périmètre du profil autour de la sécurité des identités, de l’administration cloud, de la résilience face aux rançongiciels, des systèmes financiers critiques ou de l’accès fournisseur.

Pour les entités financières couvertes par DORA, DORA fonctionne comme le régime sectoriel de cyberrésilience de l’UE pour les obligations équivalentes de risque et d’incident prévues par NIS2. Cela ne rend pas NIS2 non pertinente. Cela signifie que l’entité financière doit utiliser DORA comme régime directeur pour les exigences de risque TIC et d’incident, tout en maintenant la coordination avec les stratégies nationales de cybersécurité, les autorités compétentes et les CSIRT lorsque cela est applicable.

Comment les auditeurs testent les éléments probants relatifs à l’accès à privilèges

Les auditeurs n’évaluent pas la PAM uniquement en lisant la politique. Ils recoupent politique, configuration, journaux, tickets, entretiens et pratiques observées.

La méthodologie d’audit de Zenith Controls pour les privilèges d’accès renvoie aux pratiques d’audit ISO/IEC 19011:2018. Les auditeurs examinent les politiques définissant les droits élevés, ainsi que les procédures de provisionnement, de surveillance et de révocation. Ils examinent les inventaires de comptes utilisateurs, les enregistrements d’attribution de privilèges et les journaux. Ils corroborent les éléments probants au moyen d’entretiens, d’outils PAM, de services d’annuaire et d’échantillons de journaux.

Pour les droits d’accès, Zenith Controls indique que les auditeurs échantillonnent les demandes d’accès utilisateurs, vérifient les approbations documentées et confirment que l’informatique n’a accordé que les accès approuvés. Ils comparent également les rôles des utilisateurs avec les droits réels, afin de vérifier si le moindre privilège est appliqué. Pour la journalisation, les auditeurs inspectent le périmètre de journalisation, les types d’événements, les durées de conservation, les protections et les entrées de journaux réelles. Ils évaluent si les connexions échouées, l’accès aux données sensibles et les changements de configuration sont capturés et revus.

Un bon dossier d’éléments probants d’accès d’urgence comprend :

• Demande d’accès d’urgence approuvée
• Contexte d’incident ou d’indisponibilité
• Identité de l’utilisateur activant l’accès
• Identité de l’approbateur
• Heure de début et de fin
• Élément probant MFA ou d’authentification
• Enregistrement de session ou journal de commandes
• Journaux système et alerte SIEM
• Changements effectués
• Confirmation de la réinitialisation des identifiants
• Revue post-utilisation
• Évaluation de l’accès aux données
• Évaluation de notification réglementaire
• Actions correctives si un élément a échoué

Si votre exercice ne peut pas produire ce dossier, le contrôle n’est pas prêt pour l’audit.

La défaillance cachée : l’accès à privilèges des tiers

De nombreuses organisations gouvernent mieux les administrateurs employés que les administrateurs fournisseurs. Pour les environnements cloud, SaaS, fintech et de services managés, c’est l’inverse de ce qu’il faut faire.

NIS2 Article 21 inclut la sécurité de la chaîne d’approvisionnement et les relations avec les fournisseurs et prestataires de services directs. DORA Articles 28 à 30 vont plus loin pour les entités financières, en exigeant une stratégie de gestion des risques liés aux tiers TIC, des registres des contrats de services TIC, des diligences préalables, l’évaluation du risque de concentration, des droits d’audit, des droits de résiliation, des stratégies de sortie et des mesures de sécurité contractuelles.

L’accès fournisseur à privilèges doit être inclus dans le périmètre PAM si le fournisseur peut administrer la production, soutenir des fonctions critiques ou importantes, accéder à des données à caractère personnel, modifier des configurations de sécurité, gérer des sauvegardes, déployer du code ou exploiter des outils de surveillance.

Clarysec attend généralement que les contrôles d’accès fournisseur à privilèges incluent :

• Utilisateurs fournisseurs nominatifs, et non comptes fournisseurs partagés
• Exigences de sécurité contractuelles pour l’accès à privilèges
• Authentification MFA et accès à distance sécurisé
• Fenêtres d’accès limitées dans le temps
• Approbation client pour l’accès d’urgence
• Journalisation des sessions ou pistes d’audit équivalentes
• Révocation immédiate lorsque le personnel change
• Obligations de coopération en cas d’incident
• Conservation des éléments probants alignée sur les besoins d’audit du client
• Plan de sortie pour supprimer les accès fournisseur

Les résultats relatifs à la chaîne d’approvisionnement de NIST CSF 2.0 sont fortement alignés ici. Ils appellent à définir les rôles et responsabilités des fournisseurs, à prioriser les fournisseurs selon leur criticité, à inclure des exigences dans les contrats, à réaliser des diligences préalables, à assurer une surveillance continue, à impliquer les fournisseurs dans la planification des incidents et à prévoir des plans de risque post-contractuels.

Si un compte de prestataire de services managés est exempté de votre workflow PAM interne, ce n’est pas une commodité. C’est une exception à haut risque qui doit figurer dans le registre des risques, le registre des fournisseurs et la revue d’accès.

Constats PAM et accès d’urgence courants en 2026

Dans les missions Clarysec, les constats sont rarement surprenants. Ils résultent généralement d’une combinaison de bonnes intentions, de pression opérationnelle et d’éléments probants incomplets.

Les constats les plus fréquents sont :

• Des comptes d’accès d’urgence existent, mais ne sont pas listés dans l’inventaire des comptes à privilèges.
• Les comptes d’urgence sont exclus des revues d’accès normales.
• L’organisation ne peut pas prouver qui a utilisé un compte d’urgence.
• Le compte n’a pas été réinitialisé après utilisation.
• Les sessions à privilèges sont journalisées, mais les commandes ne le sont pas.
• Les journaux existent localement, mais ne sont pas protégés contre les utilisateurs à privilèges.
• Les comptes root cloud ne sont pas testés.
• Les processus de récupération MFA ne sont pas documentés.
• L’accès à privilèges des pipelines CI/CD et des comptes de service est ignoré.
• L’accès support des tiers contourne l’approbation interne.
• L’approbation d’accès existe dans des messages de chat, mais n’est pas conservée comme élément probant d’audit.
• Le départ supprime le courriel et le VPN, mais pas les droits administrateur SaaS.
• Le DPO n’est pas impliqué lorsque l’accès à privilèges peut exposer des données à caractère personnel.
• Les playbooks d’incident n’incluent pas les points de décision de notification NIS2, DORA ou GDPR.

Chaque constat peut être traité au moyen du traitement des risques ISO/IEC 27001:2022. Identifiez le risque, affectez un propriétaire, sélectionnez les contrôles, mettez à jour la Déclaration d’applicabilité, mettez en œuvre le plan de traitement et conservez les éléments probants documentés. C’est la force d’un SMSI plutôt qu’un ensemble dispersé de tâches de sécurité.

À quoi ressemble un dispositif maîtrisé

Un modèle opérationnel PAM et d’accès d’urgence mature comporte cinq routines récurrentes.

Premièrement, inventorier les accès à privilèges mensuellement ou en continu. Incluez les administrateurs humains, les comptes de service, les comptes d’urgence, les rôles cloud, les identités CI/CD, les utilisateurs de bases de données, les utilitaires à privilèges et les administrateurs tiers.

Deuxièmement, appliquer le moindre privilège au moyen de rôles, de l’élévation juste-à-temps et des approbations. Les privilèges permanents doivent être rares, justifiés et revus plus fréquemment que les accès utilisateurs standard.

Troisièmement, surveiller le comportement à privilèges. Journalisez l’authentification, la durée de session, l’utilisation MFA, les commandes, les changements de configuration, les exports de données, les tentatives échouées, l’élévation de privilèges et l’exécution d’utilitaires à privilèges.

Quatrièmement, tester les comptes d’accès d’urgence avant l’urgence. Un compte d’accès d’urgence qui n’a jamais été testé est une hypothèse, pas un contrôle.

Cinquièmement, rendre compte à la direction. NIS2 et DORA placent toutes deux la cybersécurité et le risque TIC sous la responsabilité de l’organe de direction. Le conseil d’administration n’a pas besoin de chaque journal de commandes, mais il a besoin d’indicateurs : nombre de comptes à privilèges, revues en retard, activations d’urgence, comptes administrateur fournisseurs, tests échoués, exceptions critiques et statut de remédiation.

C’est ici que la boîte à outils Clarysec devient pratique. La bibliothèque de politiques fournit le langage de gouvernance. Le Zenith Blueprint fournit la séquence de mise en œuvre. Zenith Controls fournit la cartographie de conformité croisée, les relations entre contrôles, les normes de support et la méthodologie d’audit.

Prochaines étapes : transformer l’accès d’urgence en résilience prête pour audit

Si votre organisation n’a pas testé l’accès d’urgence au cours des 90 derniers jours, commencez par là. Ne commencez pas par un atelier de sélection d’outil. Commencez par les éléments probants.

1. Créez ou mettez à jour votre inventaire des comptes à privilèges.
2. Identifiez chaque compte d’accès d’urgence et chaque chemin d’administration d’urgence.
3. Mettez chaque compte en correspondance avec le propriétaire métier, le propriétaire du système et l’impact sur les données.
4. Confirmez la couverture de la politique à l’aide de la Politique de gestion des comptes utilisateurs et des privilèges Politique de gestion des comptes utilisateurs et des privilèges de Clarysec ou de la Politique de gestion des comptes utilisateurs et des privilèges - PME Politique de gestion des comptes utilisateurs et des privilèges - PME.
5. Utilisez le Zenith Blueprint Zenith Blueprint, phase Contrôles en action, étapes 19, 20, 22 et 16, pour relier l’accès à privilèges, les utilitaires à privilèges, les revues du cycle de vie et le départ.
6. Utilisez Zenith Controls Zenith Controls pour mettre en correspondance les contrôles ISO/IEC 27002:2022 8.2, 5.18 et 8.15 avec les attentes NIS2, DORA, GDPR et NIST en matière d’éléments probants.
7. Réalisez un exercice de collecte d’éléments probants d’accès d’urgence et consignez les résultats.
8. Ajoutez les lacunes au plan de traitement des risques et suivez la remédiation jusqu’à clôture.

L’accès à privilèges est un pouvoir. L’accès d’urgence est un pouvoir d’urgence. En 2026, les organisations qui se rétabliront proprement après des rançongiciels, des indisponibilités cloud et des défaillances d’identité seront celles qui pourront prouver que l’accès d’urgence était maîtrisé avant, pendant et après la crise.

Clarysec peut vous aider à construire cette preuve, de la politique à la cartographie des contrôles jusqu’aux éléments probants prêts pour l’audit. Commencez avec le Zenith Blueprint, associez-le à la Politique de gestion des comptes utilisateurs et des privilèges et à la Politique de contrôle d’accès, puis utilisez Zenith Controls pour montrer comment votre programme PAM soutient ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST CSF 2.0 et COBIT 2019.