Bastions et PAM : Sécuriser les accès privilégiés dans une architecture zero trust

Le Zero Trust repose sur un principe qui dérange autant qu’il s’impose : ne jamais faire confiance, toujours vérifier, y compris à l’intérieur de votre propre réseau. Vous avez un firewall. Vous avez un EDR. Vous avez peut-être même un SOC. Et pourtant, si un attaquant met la main sur un seul compte Domain Admin, tout ça ne sert plus à rien. Le périmètre a changé, l’identité est devenue le nouveau réseau. Et les accès privilégiés, qu’ils soient humains, machines ou désormais agents IA, sont la surface d’attaque que vos outils traditionnels ne couvrent pas.

En cybersécurité des infrastructures, on ne court pas après les grandes théories. On court après les comptes de service oubliés, les prestataires encore actifs six mois après la fin du contrat, et les droits Domain Admin distribués comme des bonbons il y a cinq ans. C’est ce quotidien-là que le PAM est censé résoudre, à condition de le déployer pour ce qu’il est vraiment : le plan de contrôle central de toute architecture Zero Trust, pas un outil de conformité de plus.

Récemment, un client nous a confié un périmètre à auditer avant une migration de son système d’informations. Premier résultat de l’inventaire PAM : 47 comptes de service actifs en production. Dont 12 avec des droits Domain Admin. Dont 3 dont le dernier changement de mot de passe remonte à 2018. Dont 1 appartenant à un prestataire dont le contrat s’était terminé deux ans plus tôt.

Ce n’est pas un cas isolé. C’est ce que nous voyons sur la majorité des parcs que nous auditons chez Tersedia. Et c’est exactement là que commence toute architecture Zero Trust sérieuse : pas dans les slides, mais dans l’inventaire exhaustif de tout ce qui possède des clés du royaume, humains, machines, et désormais, agents IA.

Le PAM n’est pas un projet de sécurité supplémentaire. C’est le plan de contrôle central de votre Zero Trust. Voici comment le construire pour qu’il tienne.

Les clés du royaume : pourquoi les accès privilégiés sont la cible n°1

Le modèle d’administration classique repose sur une erreur de fond : les droits élevés comme état par défaut. Domain Admin en permanence, y compris pour relire un log ou redémarrer un service, c’est un mot de passe universel qu’on ne retire jamais.

Ce modèle viole le principe fondamental du moindre privilège et augmente exponentiellement le rayon d’explosion (blast radius) en cas de compromission. Les risques sont multiples et bien documentés :

Une credential compromise (phishing, keylogger, malware) accorde à l’attaquant des droits illimités et persistants.

Un administrateur quittant l’entreprise conserve potentiellement ses accès pendant plusieurs jours, voire semaines.

Un bug applicatif exécuté sous un compte admin expose l’infrastructure entière.

Les comptes de service à privilèges élevés, rarement audités, constituent des vecteurs dormants d’attaque latérale.

Dans une architecture Zero Trust, le PAM (Privileged Access Management) n’est pas un outil périphérique, c’est le plan de contrôle central pour les identités à haut risque. Il transforme les comptes privilégiés d’un risque permanent en une ressource conditionnelle, temporaire et auditée.

Sur les projets d'infogérance que nous menons, un audit initial d'inventaire PAM révèle systématiquement entre 30 et 50 % de comptes de service avec des droits excessifs et non audités depuis plus de deux ans. Ce n'est pas un angle mort, c'est le point de départ de toute transformation Zero Trust.

Ce que prescrit l’état de l’art : éliminer les privilèges permanents

Le principe cardinal du moindre privilège

Les cadres de référence internationaux en matière de Zero Trust sont sans ambiguïté : l’accès aux ressources doit être déterminé par une politique dynamique, appliquée par requête, avec le minimum de privilèges nécessaires à la tâche. Le moindre privilège n’est pas une recommandation, c’est un élément fondamental.

Les recommandations nationales relatives à l’administration sécurisée des systèmes d’information établissent que les comptes d’administration permanents doivent être éliminés en faveur d’une approche d’élévation temporaire justifiée par un besoin fonctionnel. Cette recommandation s’applique à tous les contextes : administrateurs domaine, administrateurs cloud, comptes de service, administrateurs OT.

Parmi les mesures clés préconisées :

Isoler les postes d’administration du réseau Internet, toute pratique de type BYOD est à proscrire pour les administrateurs.
Limiter les droits d’administration au strict nécessaire, tant en périmètre qu’en durée.
Utiliser un réseau dédié pour l’administration, séparé du réseau de production.
Mettre en œuvre une gestion centralisée de l’authentification, simplifiant la gestion des comptes et permettant de réagir rapidement en cas de compromission avérée ou suspectée.
Exiger des visas de sécurité sur les matériels et logiciels utilisés pour protéger le SI d’administration.

Le PAM comme compétence clé du Zero Trust

Le PAM est un tenet du Zero Trust, pas une option de maturité avancée. NIST SP 800-207, CISA et l’ANSSI le placent parmi les capacités fondamentales de tout déploiement Zero Trust. Le PAM fournit les capacités nécessaires aux trois composants architecturaux fondamentaux : le moteur de politique (qui décide), l’administrateur de politique (qui établit ou coupe le chemin de communication) et le point d’application de politique (qui applique la décision à chaque session).

L’agence européenne de cybersécurité recommande dans ses guides techniques d’implémentation l’utilisation d’une solution PAM centralisée pour la gestion des accès privilégiés, complétée par une gouvernance stricte des identités et un inventaire permanent des comptes à privilèges.

L'audit ISO 27001 annuel pose une question simple : pouvez-vous prouver que chaque compte à privilèges a un propriétaire identifié, une justification documentée et une revue récente ? Avant de déployer une solution PAM, c'est cette question qu'il faut être capable de répondre. Nous maintenons la certification ISO 27001 de Tersedia depuis 2021 et cette exigence de preuve est le plus puissant accélérateur de maturité PAM que nous ayons observé.

ISO 27001 et PAM selon Mathieu QUIOC , RSSI chez Tersedia

Le modèle Tiering : segmenter les privilèges en niveaux de criticité

Architecture Tier 0 / Tier 1 / Tier 2

Le modèle de segmentation des ressources administrées en trois niveaux hiérarchiques est devenu le standard de facto pour les environnements Active Directory et hybrides. Il établit des frontières strictes entre les niveaux de criticité, chaque niveau ayant ses propres comptes administratifs et ses restrictions d’accès.

Isolation physique et logique

Les guides de référence recommandent une séparation physique ou logique stricte entre les tiers :

Tier 0 Network : réseau fermé, pare-feu bloquant tous les ports sauf les accès d’administration depuis des postes dédiés Tier 0, sans aucun accès Internet.
Tier 1 Network : VLAN dédié, accès autorisés uniquement depuis les postes admin Tier 1, blocage de tout accès depuis Tier 2.
Tier 2 Network : VLAN utilisateur, accès Internet, blocage de tous les accès directs vers Tier 0/Tier 1.

Un administrateur système typique dispose de trois identités distinctes : son compte utilisateur standard (Tier 2), son compte admin serveurs (Tier 1), et un accès JIT d’urgence pour les opérations Tier 0. Cette séparation empêche la compromission d’un compte bureautique de se propager vers l’infrastructure critique.

Tiering en conditions réelles : le cas d’une ETI industrielle hybride

Pour ancrer ce modèle, voici comment le tiering s’est construit concrètement sur un projet Tersedia de mise en conformité Zero Trust pour un groupe industriel, 500 utilisateurs, Active Directory on-premise couplé à Microsoft Entra ID, production OT segmentée.

Ce qui a déclenché le projet

Un prestataire de maintenance industrielle avait conservé un accès RDP direct à un serveur de supervision SCADA, sans bastion, sans MFA, avec un compte générique partagé entre trois techniciens. Le compte n’avait jamais été supprimé à la fin du contrat. La découverte s’est faite lors d’un audit préalable avant un projet de Tech Refresh, pas lors d’un incident.

Niveau	Périmètre dans ce cas	Décision clé prise	Point de friction rencontré
Tier 0 Critique absolu	Contrôleurs de domaine AD, PKI, hyperviseurs vSphere, console Azure AD Connect, SCADA superviseur (OT)	Zéro accès direct depuis Internet ou depuis un poste bureautique. Bastion dédié Tier 0 sur VLAN isolé. MFA FIDO2 obligatoire.	Azure AD Connect était considéré Tier 1 par le client. Il a fallu documenter qu’un DC virtuel compromis via l’hyperviseur exposait toute la forêt.
Tier 1 Serveurs métier	Serveurs ERP, fichiers, messagerie, serveurs applicatifs métier, NAS de production	Comptes admin serveur distincts des comptes bureautiques. Accès via bastion Tier 1 avec enregistrement de session. JIT pour les opérations sensibles.	3 administrateurs refusaient de maintenir 2 comptes distincts. Le vrai frein était l’UX, pas la technique. Résolu par SSO au bastion.
Tier 2 Postes & prestataires	Postes bureautiques, VPN utilisateurs, accès SaaS, prestataires externes	Aucun accès direct vers Tier 0/1. Les prestataires passent obligatoirement par le bastion avec des comptes JIT à durée limitée et révocation automatique.	L’ex-prestataire SCADA avait un compte Tier 2 encore actif. Sa suppression a mobilisé 3 équipes, preuve que la gouvernance des offboardings était le vrai problème.

La vraie difficulté du tiering n'est pas architecturale, elle est organisationnelle. Ce n'est pas de savoir où placer Azure AD Connect (Tier 0) : c'est de convaincre le responsable infrastructure que son hyperviseur vSphere est aussi critique que ses contrôleurs de domaine. Le modèle tiering impose une conversation sur la criticité des actifs que la plupart des organisations n'ont jamais eue.

Selon Benjamin Rochefort , Responsable Professional Services chez Tersedia

Le bastion : point de passage obligé et traçable

Architecture et fonctionnement

Le bastion (ou jump server sécurisé) est le point d’accès centralisé unique pour tous les accès privilégiés. Tout administrateur désireux d’accéder à un serveur critique doit transiter par le bastion, qui orchestre le cycle complet de l’accès :

Authentification forte : l’administrateur s’authentifie auprès du bastion via MFA (clé FIDO2, authentification fédérée via le fournisseur d’identité cloud).

Vérification des permissions : le bastion vérifie si l’administrateur est autorisé à demander accès à la ressource cible, dans le contexte actuel (horaire, localisation, posture du poste).

Demande d’élévation : si l’accès nécessite une approbation, création d’un ticket envoyé à l’approbateur désigné (directeur IT, RSSI).

Session temporaire : une fois approuvée, une session temporaire est créée (1-2 heures), avec mot de passe à usage unique (OTP) ou certificat SSH éphémère généré à la volée.

Tunnel chiffré : l’administrateur se connecte au serveur cible via le bastion (tunnel SSH/RDP chiffré), sans jamais accéder directement à la ressource.

Enregistrement intégral : toute la session est enregistrée (frappe clavier, mouvements souris, commandes terminales), audit trail complet.

Révocation automatique : à expiration, la session est fermée, l’accès révoqué, l’enregistrement archivé.

Le bastion est le gardien de vos accès critiques, mais c'est aussi un composant qui doit lui-même être résilient. Chez Tersedia, nous imposons systématiquement une architecture active-passive pour les composants PAM qui protègent des environnements de production 24/7. Un bastion en panne sans procédure break-glass éprouvée, c'est une crise opérationnelle en plus d'une crise de sécurité.

Selon Riad Roubache , CTO chez Tersedia

Capacités techniques clés

Les bastions de nouvelle génération supportent :

Protocoles multiples

RDP, SSH, VNC, Telnet, accès Citrix et VMware.

Protocoles OT (Modbus, Profinet)

Pour les environnements industriels, alignement direct avec la segmentation IEC 62443 décrite dans l’article on-premise.

Rotation automatique des secrets

Les mots de passe des comptes de service sont renouvelés automatiquement (quotidiennement ou à chaque usage), sans intervention humaine.

Certificats SSH éphémères

Génération à la volée, durée limitée, révocation automatique à expiration.

Intégration native avec les fournisseurs d'identité cloud

SSO, récupération des groupes pour autorisation, synchronisation des politiques.

IT et JEA : les deux piliers de l’accès privilégié Zero Trust

Just-In-Time (JIT) : élévation temporaire à la demande

Le JIT transforme radicalement la gestion des privilèges : un administrateur possède une identité de base sans aucun privilège élevé permanent. Lorsqu’il doit effectuer une opération sensible (redémarrage d’un contrôleur de domaine, modification de GPO, création d’utilisateur), il demande une élévation temporaire via le bastion ou la plateforme PIM cloud.

Le cycle JIT :

Demande : l’administrateur justifie le besoin (ticket, description de la tâche).
Approbation : un approbateur valide la demande (checklist, justification).
Activation : le rôle est accordé pour une durée limitée (30 minutes à 2 heures), avec MFA obligatoire à l’activation.
Exécution : l’administrateur réalise sa tâche sous surveillance.
Révocation : à expiration, les privilèges sont automatiquement révoqués.

Just-Enough-Access (JEA) : le minimum nécessaire, rien de plus

Le JEA complète le JIT en restreignant le périmètre des actions autorisées pendant la session. Un administrateur « backup » reçoit un rôle qui lui permet de déclencher une sauvegarde et de consulter les logs, mais pas de modifier la politique de rétention, encore moins d’accéder à la PKI.

Les rôles JEA sont définis de manière granulaire via :

PowerShell JEA sur les serveurs Windows : endpoint restreints avec commandes autorisées explicitement listées.
RBAC (Role-Based Access Control) sur Linux, les plateformes cloud et les environnements conteneurisés.
Rôles conditionnels sur les plateformes d’identité cloud : accès accordé uniquement si les conditions de contexte sont remplies (posture du poste, localisation, niveau de risque).

PAM Cloud-Native : l’identité comme nouveau périmètre

La gestion des identités privilégiées dans le cloud

L’extension des systèmes d’information vers le cloud impose une extension symétrique du PAM. Les plateformes d’identité cloud de nouvelle génération intègrent nativement des capacités de gestion des identités privilégiées (PIM) qui déclinent le JIT et le JEA dans l’environnement cloud.

Les capacités clés des PIM cloud-natifs :

Accès privilégié Just-In-Time aux rôles d’administration cloud et aux ressources associées.
Accès temporel avec dates de début et de fin, limitant strictement la fenêtre d’exposition.
Approbation requise pour l’activation des rôles critiques (administrateur global, administrateur de sécurité).
MFA obligatoire à chaque activation de rôle, pas seulement à l’authentification initiale.
Justification documentée : chaque activation exige un motif enregistré dans l’audit trail.
Notifications en temps réel lors de l’activation de rôles privilégiés.
Revues d’accès périodiques pour vérifier que les utilisateurs ont toujours besoin de leurs éligibilités.

L’évaluation continue : le signal de révocation en temps réel

Comme décrit dans l’article Cloud-Native SASE, le mécanisme d’évaluation continue des accès (CAE) s’applique également aux sessions privilégiées. En cas de changement de contexte (adresse IP, posture du poste, anomalie comportementale), le signal de révocation est propagé en quelques secondes, interrompant la session privilégiée en cours. Le PAM et le ZTNA convergent ici : la confiance n’est jamais acquise, même pour un administrateur en session active.

Les identités machines : l’angle mort à combler

40 fois plus d’identités machines que d’identités humaines

Les identités machines dépassent les humains dans un rapport de 40 pour 1. Elles détiennent en moyenne 3 à 5 fois plus de droits qu’un utilisateur standard et bénéficient d’un dixième de la rigueur de gouvernance. C’est l’angle mort structurel du PAM classique.

Résultat : un angle mort massif. Les attaquants le savent. Le mouvement latéral commence presque toujours par un compte de service sur-permissionné que personne n’a audité depuis 18 mois. Seulement 15 % des organisations appliquent la même rigueur de gouvernance aux identités machines qu’aux identités humaines.

Gestion des secrets dans les pipelines DevOps

Dans les environnements cloud-native et conteneurisés, les secrets (API keys, mots de passe de bases de données, tokens, certificats) circulent dans les pipelines CI/CD et les clusters d’orchestration. Les bonnes pratiques de l’état de l’art imposent :

Centraliser les secrets dans un coffre-fort dédié (vault) chiffré, jamais dans le code source ni dans les variables d’environnement en clair.
Injecter les secrets au runtime : les credentials sont fournies à l’application au moment de l’exécution, jamais stockées dans les images ou les descripteurs de déploiement.
Automatiser la rotation et l’expiration : les secrets doivent être éphémères, avec rotation automatique et révocation à expiration.
Appliquer le RBAC strict : chaque pipeline, chaque service, chaque conteneur ne dispose que des secrets strictement nécessaires à sa fonction.
Auditer chaque accès : un audit trail complet de chaque consommation de secret est indispensable pour la détection d’anomalies et la conformité.

La gestion des secrets est l’extension naturelle du PAM dans le monde cloud-native : ce que le bastion fait pour les sessions humaines, le vault le fait pour les identités machines.

Lors d’une conférence sur la sécurité de l’IA organisée par le BSI, Riad a abordé le thème de la gestion des identités machines, comptes de service, API keys, certificats, tokens, qui, constitue l’extension naturelle du PAM dans les architectures cloud-native. Mais ce spectre s’élargit encore. Depuis 2025, une nouvelle catégorie d’acteurs peuple les systèmes d’information : les agents IA. Ni humains, ni simples processus automatisés, ce sont des entités autonomes qui chaînent des décisions, consomment des APIs, lisent des données et, parfois, écrivent dans des systèmes critiques. Pour le RSSI, c’est un nouveau type d’identité à gouverner, avec les mêmes exigences que les précédentes et de nouveaux risques que le PAM traditionnel ne couvre pas encore.

IA agentique : quand les « insiders » sont des machines autonomes

Le PAM face à un nouveau type d’acteur du SI

2026 marque un seuil. L’IA générative répond à des questions. L’IA agentique agit, sur vos fichiers, vos APIs, vos systèmes internes. Pour un RSSI, c’est un nouveau type d’insider : autonome, rapide, et souvent doté de droits que personne n’a pensé à auditer.

Un agent IA n’est pas un chatbot : il enchaîne des actions, prend des décisions, se connecte à des systèmes internes, manipule des données, parfois sans supervision humaine directe. Les études récentes montrent que les shadow agents, des agents IA déployés sans gouvernance par des collaborateurs sur des plateformes no-code/low-code, sont désormais aussi répandus que les agents officiellement sanctionnés. Plus de la moitié de l’usage des plateformes d’IA générative en entreprise est classée comme shadow AI, et 32 % des travailleurs IT utilisant l’IA le cachent à leur direction.

Le résultat : des organisations qui ne savent pas combien d’agents IA tournent chez elles, avec quels droits, et sur quelles données. Des agents abandonnés continuent de tourner en arrière-plan avec des droits excessifs, constituant des vecteurs dormants d’attaque et d’exfiltration.

Pourquoi le PAM traditionnel ne suffit plus

L’ancien modèle de sécurité, centré sur l’identité humaine, ne couvre pas les agents IA. La complexité croissante des architectures hybrides/multi-cloud, couplée à l’introduction non gouvernée d’agents IA, cimente les défaillances IAM comme vecteur initial d’accès principal. D’ici fin 2026, les copilotes autonomes pourraient dépasser les humains comme source principale de fuites de données.

Les agents IA doivent être traités comme des identités à part entière dans le périmètre PAM, avec les mêmes exigences :

Authentification : chaque agent doit disposer d’une identité unique, vérifiable, jamais partagée entre agents ou entre un agent et un humain.
Autorisation granulaire (JEA) : un agent ne doit accéder qu’aux données et actions strictement nécessaires à son périmètre fonctionnel, pas à l’ensemble des ressources de son propriétaire humain.
Temporalité (JIT) : les droits d’un agent doivent être conditionnels et révocables, avec des fenêtres d’exécution limitées et des mécanismes d’expiration automatique.
Supervision continue : les actions des agents doivent être journalisées, corrélées et analysées en temps réel, comme une session bastion humaine.
Capacité de révocation immédiate : en cas de dérive comportementale, l’agent doit pouvoir être coupé en quelques secondes, l’équivalent du signal CAE appliqué aux identités machines.

De l’approbation statique à la supervision continue

Le modèle de gouvernance « one shot », on valide un agent, on le met en production, on le revoit dans un an, est obsolète. Les modèles sous-jacents sont mis à jour en continu par les fournisseurs, les prompts évoluent, les cas d’usage se multiplient. Le PAM doit intégrer une logique de surveillance et d’approbation continue des agents IA :

Enveloppes d’usage approuvées : chaque agent est validé pour un périmètre précis (type de données, cas d’usage, canal). Toute sortie de périmètre déclenche un cycle de revue risques/conformité.
Garde-fous (guardrails) : filtrage des entrées et sorties des agents pour limiter les risques de fuite de données, de prompte injection et de contenus inappropriés, avec journalisation systématique des interactions.
Monitoring continu : suivi d’indicateurs clés (volumétrie, taux d’erreur, comportements inattendus) et capacité technique de couper ou restreindre un agent rapidement, dans l’esprit d’ISO 42001 appliqué aux systèmes IA comme actifs vivants.

Les agents IA dans le modèle Tiering

L’intégration des agents IA dans le modèle Tier 0/1/2 est un impératif immédiat. Les dossiers partagés sur-permissionnés, les documents non classifiés et les règles d’accès obsolètes permettent aux copilotes de remonter des données sensibles vers des utilisateurs non autorisés. Le PAM est la brique qui doit poser aux agents IA les mêmes questions qu’aux humains : qui est autorisé à faire quoi, avec quelles données, sous quelle supervision, et avec quels mécanismes de révocation si ça se passe mal.

Rendre les agents visibles et contrôlables

Pour un RSSI, l’enjeu de 2026 n’est pas de promettre un contrôle parfait, mais de prouver qu’on dispose d’une boucle de supervision :

On sait quelles IA et quels agents sont déployés.
On sait sur quelles données ils opèrent.
On sait qui en est responsable.
On surveille des signaux de dérive.
On peut intervenir rapidement.

C’est cette capacité de contrôle dans la durée qui crée la confiance auprès des clients comme des régulateurs.

Identités humaines, machines, agents autonomes : le périmètre PAM s'est considérablement élargi. Mais quel que soit le niveau de maturité atteint, il reste un cas limite que tout architecte Zero Trust doit anticiper : celui où le système nominal est indisponible. Le bastion est en panne, le fournisseur d'identité cloud est inaccessible, et un administrateur doit redémarrer un contrôleur de domaine. C'est précisément ce que couvrent les procédures break-glass, le filet de sécurité ultime d'une architecture PAM.

Selon Riad Roubache , CTO chez Tersedia

Le résultat :

des organisations qui ne savent pas combien d'agents IA tournent chez elles, avec quels droits, et sur quelles données. Des agents abandonnés continuent de tourner en arrière-plan avec des droits excessifs, constituant des vecteurs dormants d'attaque et d'exfiltration.

A retenir :

Aucun agent IA ne doit disposer de droits Tier 0. C'est une règle, pas une recommandation.

Procédures Break-Glass ou Brise-Glace : l’urgence sous contrôle

Quand le système nominal est indisponible

Les procédures break-glass permettent l’accès d’urgence lorsque le bastion, le fournisseur d’identité cloud ou les circuits d’approbation sont indisponibles. Elles doivent être rares, justifiées et strictement auditées. Situations justifiant un break-glass :

Bastion en panne, administrateur devant redémarrer un contrôleur de domaine critique.
Fournisseur d’identité cloud inaccessible (panne du service), accès local-only requis.
Incident de sécurité en cours, besoin d’accès immédiat sans délai d’approbation.
Disaster recovery, restauration après sinistre.

Les 7 composantes d’une procédure break-glass robuste

Compte d’urgence prédéfini : compte déterminé d’avance, stocké de façon sécurisée (coffre-fort physique, enveloppe scellée, HSM), jamais utilisé en conditions normales.
Déclenchement contrôlé : seules des personnes désignées (Incident Commander, RSSI) peuvent déclarer une urgence et autoriser l’utilisation du compte.
Authentification renforcée : l’accès break-glass exige MFA, certificat ou double approbation.
Durée limitée : accès temporaire avec auto-expiration (30 minutes), extension manuelle possible sous contrôle.
Audit exhaustif : toutes les actions sont loggées, enregistrées (vidéo si possible), avec identification de l’utilisateur.
Notification immédiate : le déclenchement génère une alerte au RSSI et au SOC pour monitoring en temps réel de la session d’urgence.
Post-incident : après utilisation, mot de passe changé, certificat révoqué, enregistrement archivé pour analyse et retour d’expérience.

Les guides de référence recommandent de maintenir les comptes break-glass « propres » : pas d’email associé, pas d’accès Internet, utilisés uniquement en cas d’urgence véritable. Ces comptes doivent être supervisés en permanence : toute activation inattendue doit déclencher une alerte SOC immédiate.

Conformité réglementaire : le PAM comme réponse structurante

NIS2 : la gestion des privilèges comme pilier réglementaire

La directive NIS2 établit un cadre strict pour la gestion des accès privilégiés à travers plusieurs exigences clés. L’article 21 impose aux entités concernées de mettre en place des mesures de cybersécurité incluant explicitement la gestion et la protection des accès administrateurs.

Les exigences NIS2 adressées par le PAM portent sur trois axes :

Authentification renforcée : déploiement obligatoire de MFA pour tous les comptes privilégiés, avec des mécanismes résistants au phishing (FIDO2, certificats).
Traçabilité et audit : journalisation complète de toutes les sessions privilégiées, avec capacité de reconstitution intégrale des actions effectuées — requis pour la notification d’incident (24h/72h/1 mois).
Gestion des risques documentée : inventaire permanent des comptes à privilèges, revues d’accès périodiques, et démonstration du moindre privilège effectif.

Avec des sanctions pouvant atteindre 10 millions d’euros ou 2 % du chiffre d’affaires annuel mondial, la sécurisation des accès privilégiés n’est plus une bonne pratique, c’est une obligation légale. Et depuis 2026, votre assureur cyber en fait un prérequis de souscription, indépendamment de toute réglementation. Gartner estime que 15 à 25 % des nouveaux projets PAM sont désormais déclenchés par une exigence d’assurabilité.

DORA : résilience opérationnelle et contrôle des accès tiers

Le règlement DORA renforce ces exigences pour les entités financières et leurs prestataires TIC :

Évaluation continue des fournisseurs IT critiques : les prestataires accédant à des ressources privilégiées doivent démontrer des contrôles PAM conformes.
Tests de résilience : les procédures break-glass et les mécanismes JIT doivent être testés régulièrement et documentés.
Administration par des tiers : les dernières versions des guides nationaux ajoutent des recommandations spécifiques pour l’administration du SI par des tiers, exigeant la sécurisation des postes d’administration tiers et l’encadrement strict des sessions distantes.

CRA : security by design pour les composants d’accès

Le Cyber Resilience Act impose aux fabricants de produits numériques, y compris les solutions PAM elles-mêmes, des exigences de sécurité dès la conception, de gestion des vulnérabilités et de maintenance dans la durée. Les organisations doivent s’assurer que les solutions PAM qu’elles déploient respectent ces exigences, et que les mises à jour de sécurité sont appliquées sans interruption de service.

Métriques et pilotage : mesurer la maturité PAM

Le déploiement d’une architecture PAM Zero Trust ne se pilote pas au ressenti. Il se mesure. Voici les KPIs que nous recommandons de suivre, calibrés sur les benchmarks sectoriels les plus récents.

KPI	Définition & mode de calcul	Cible	Benchmark / source
Couverture PAM des comptes à privilèges	% de comptes admin humains ET machines couverts par une solution PAM (vault + rotation + audit). Numérateur : comptes dans le PAM. Dénominateur : inventaire total.	> 95 %	Seulement 40 % des orgs se déclarent pleinement confiantes dans leur couverture. (LLCBuddy 2025)
Taux de comptes à privilèges permanents	% de comptes admin avec droits élevés actifs en permanence (hors JIT). Objectif : tendre vers 0. Seuls les comptes break-glass sont tolérés.	< 5 % (hors break-glass)	97 % des organisations maintiennent encore des comptes permanents. (LLCBuddy 2025)
Délai de révocation post-départ / fin de contrat	Temps médian entre la date de fin de contrat/départ et la révocation effective de tous les accès privilégiés.	< 4 heures	Les organisations PAM unifiées sont 72 % moins susceptibles de découvrir des comptes actifs pour des utilisateurs partis. (LLCBuddy 2025)
Taux de secrets avec rotation automatique	% des comptes de service et API keys avec politique de rotation automatique active. Les secrets statiques sont le vecteur principal d’attaque latérale.	> 90 %	Identités machines 40x plus nombreuses que les humains — angle mort prioritaire. (Mordor Intelligence, jan. 2026)
Couverture enregistrement sessions Tier 0/1	% des sessions admin sur les ressources Tier 0 et Tier 1 faisant l’objet d’un enregistrement complet (keystroke + vidéo). Requis pour la traçabilité NIS2.	100 % Tier 0 > 80 % Tier 1	MFA + session recording = exigence de souscription cyber-assurance (Gartner, 15-25 % des nouveaux déploiements PAM, jan. 2026)
Délai moyen d’approbation JIT	Temps médian entre la demande d’élévation JIT et l’approbation effective. Un délai excessif pousse les administrateurs à contourner le process.	< 15 min (P90)	Indicateur de friction UX — trop haut = contournements ; trop bas = approbation sans vigilance.
Taux de couverture agents IA inventoriés	% d’agents IA déployés (officiels + shadow) disposant d’une identité machine dédiée dans le PAM, avec JIT/JEA définis et supervision active.	> 80 % en 2026	Shadow AI > 50 % de l’usage IA en entreprise non gouverné. KPI émergent, à inclure dans le tableau de bord RSSI dès maintenant.
Fréquence de test des procédures break-glass	Nombre de tests des procédures break-glass par an, avec comptes-rendus documentés.	Minimum 2x/an	Exigence DORA de test de résilience opérationnelle pour les entités financières. Bonne pratique universelle.

Sources : Mordor Intelligence PAM Market Report (janvier 2026), Gartner Peer Insights 2025-2026, LLCBuddy PAM Statistics 2025.

Ces indicateurs alimentent directement les tableaux de bord RSSI et les rapports réglementaires, transformant la conformité d’un exercice ponctuel en une production continue et vérifiable.

Recommandations pour agir efficacement

7 action par ordre de priorité, parce que vous ne ferez pas tout en même temps, et que l’ordre compte.

Dans une architecture Zero Trust, les accès privilégiés sont le dernier verrou et le plus critique. Le PAM n’est pas un projet technique parmi d’autres : c’est le mécanisme qui transforme la confiance implicite en confiance vérifiable, les droits permanents en accès conditionnels, et les angles morts en surface d’audit complète.

Avec l’avènement de l’IA agentique, ce mécanisme doit désormais gouverner non seulement les humains, mais aussi les machines autonomes qui agissent en leur nom. C’est le trait d’union entre la segmentation réseau (articles on-premise et cloud-native), la gouvernance des identités et la maîtrise des nouveaux acteurs intelligents du système d’information.

Recommandations pour agir efficacement

Sept actions. Par ordre de priorité, parce que vous ne ferez pas tout en même temps, et que l’ordre compte.

Inventorier exhaustivement les comptes à privilèges : comptes humains ET identités machines (comptes de service, API keys, certificats). Les entreprises modernes ont en moyenne 40 fois plus d’identités machines que d’identités humaines, chacune est un vecteur d’attaque potentiel.
Déployer le modèle Tiering : segmenter physiquement et logiquement les niveaux d’administration (Tier 0/1/2), avec des comptes distincts par niveau et des restrictions de connexion croisée. Commencer par la protection du Tier 0, c’est là que le blast radius est maximal.
Éliminer les privilèges permanents via le JIT/JEA : aucun compte ne doit disposer de droits élevés en permanence. Chaque élévation est temporaire, justifiée, approuvée et enregistrée.
Étendre le PAM au cloud : activer les capacités PIM sur les plateformes d’identité cloud pour les rôles d’administration, avec MFA à chaque activation et revues d’accès périodiques. Unifier la gouvernance des privilèges on-premise et cloud dans un même cadre de politique.
Sécuriser les identités machines : centraliser les secrets dans un vault dédié, automatiser la rotation, injecter au runtime, et auditer chaque accès. Les comptes de service à privilèges statiques sont une dette de sécurité à éradiquer.
Intégrer les agents IA dans le périmètre PAM : inventorier tous les agents IA (officiels et shadow), leur attribuer des identités machines dédiées, appliquer le JIT/JEA à leurs droits, et déployer une supervision continue avec capacité de révocation immédiate. Aucun agent IA ne doit disposer de droits Tier 0.
Documenter et tester les procédures break-glass : ces procédures sont le filet de sécurité ultime, elles doivent être testées régulièrement (au moins semestriellement) et auditées, conformément aux exigences DORA de test de résilience.

Étiqueté Bastions, Cyberrésilience, cybersécurité, DORA, NIS2, PAM, résiliences