Intune Endpoint Privilege Management : déléguer des droits admin sans risque

L'intune endpoint privilege management résout un problème que tout responsable IT connaît bien : comment permettre à un commercial d'installer son plugin CRM, à un technicien de configurer un équipement réseau, ou à un comptable de lancer son logiciel de paie — sans leur donner les clés du château ? Pendant des années, la réponse par défaut était d'ajouter l'utilisateur au groupe Administrateurs locaux, "juste le temps de la migration", et de ne jamais le retirer. En 2026, avec la multiplication des ransomwares ciblant les postes Windows et l'explosion des attaques par mouvement latéral, cette pratique est devenue une faute professionnelle. EPM propose une alternative précise : des règles d'élévation granulaires, basées sur l'identité de l'application, son éditeur, son chemin et son empreinte numérique. L'utilisateur obtient les droits dont il a besoin, pour l'application qui les nécessite, pendant la durée strictement nécessaire. Vous gardez la trace de tout. C'est exactement ce que le principe de moindre privilège exige — et ce que les auditeurs ISO 27001 et NIS2 viennent vérifier.

Qu'est-ce qu'Intune Endpoint Privilege Management ?

Endpoint Privilege Management (EPM) est une fonctionnalité de Microsoft Intune introduite en 2023 et désormais mature, qui permet de gérer finement les élévations de privilèges sur les postes Windows 10/11 gérés par Intune. Plutôt que d'accorder des droits administrateur permanents à un utilisateur, EPM déploie des règles précises définissant quand et comment une application peut s'exécuter avec des privilèges SYSTEM ou Administrateur.

Concrètement, voici ce que vit un utilisateur avec une règle EPM de type "User-initiated" : il fait un clic droit sur l'exécutable, voit apparaître l'option "Exécuter avec élévation de droits gérée" (ajoutée par le client EPM), saisit une justification si la règle le demande, et l'application se lance avec les droits nécessaires. L'utilisateur n'a jamais eu les droits admin. L'action est journalisée avec le nom de l'utilisateur, l'application, le hash et l'horodatage. Simple, traçable, conforme.

Ce qui distingue EPM des solutions tierces comme BeyondTrust ou CyberArk Endpoint Privilege Manager, c'est l'intégration native dans l'écosystème Microsoft. Pas d'agent supplémentaire à déployer, pas de console additionnelle à apprendre. Tout se gère depuis le centre d'administration Intune que vos équipes IT connaissent déjà. Pour les organisations déjà dans Microsoft 365, c'est un avantage décisif en termes de TCO et de complexité opérationnelle.

Pour approfondir la sécurisation de votre environnement Microsoft 365, consultez notre guide d'audit sécurité Microsoft 365 et notre article sur l'implémentation Zero Trust dans Microsoft 365.

Pourquoi les comptes administrateurs locaux permanents sont-ils si dangereux ?

Voici la réalité terrain telle que je la vois dans les audits : environ 60% des PME françaises ont au moins un tiers de leur parc avec des utilisateurs membres du groupe "Administrateurs locaux". Parfois par facilité, parfois parce qu'une application métier l'exigeait il y a cinq ans et que personne n'a revu la configuration depuis. Le résultat est prévisible.

Un utilisateur avec droits admin local peut :

• Vider la mémoire LSASS pour extraire les hachages de mots de passe (Mimikatz, ProcDump)
• Désactiver l'EDR ou l'antivirus sans alerte immédiate dans certaines configurations
• Modifier les clés de registre pour établir une persistance
• Accéder à tous les fichiers locaux y compris les certificats stockés
• Installer des outils de pivoting pour le mouvement latéral vers d'autres machines

Le rapport Microsoft Digital Defense 2025 estime que plus de 90% des attaques par ransomware auraient pu être stoppées ou considérablement limitées par l'application du principe de moindre privilège. Ce n'est pas une statistique marketing — c'est ce que confirme chaque rapport post-incident que j'ai eu à analyser.

Côté conformité, ISO 27001:2022 (contrôle A.8.2), NIS2 (article 21.2.i sur la gestion des accès) et le CIS Benchmark pour Windows 11 exigent tous que les droits admin soient strictement limités. EPM vous donne la démonstration technique concrète que vous appliquez ce contrôle.

Prérequis et licences : ce qu'il faut vérifier avant de commencer

EPM exige la licence Microsoft Intune Plan 2 ou la Microsoft Intune Suite. Ce n'est pas inclus dans Intune Plan 1, Microsoft 365 Business Standard, Business Premium ou E3. En juillet 2026, le tarif indicatif est d'environ 3,80 $/utilisateur/mois pour Intune Plan 2 (add-on), ou inclus dans Intune Suite à environ 10,60 $/utilisateur/mois avec Remote Help, Tunnel et Advanced Endpoint Analytics.

Prérequis techniques à valider :

• Windows 10 version 22H2 minimum — Windows 11 22H2 recommandé pour l'expérience complète
• Appareil géré par Intune (Entra ID Join ou Hybrid Entra Join) — les appareils co-gérés avec SCCM doivent avoir la charge de travail Endpoint Protection basculée sur Intune
• Client EPM déployé automatiquement une fois la licence activée (aucune action manuelle)
• Rôle "Intune Administrator" ou rôle personnalisé avec les permissions "Endpoint Privilege Management" dans le portail
• Pas de conflits avec des GPO locales désactivant les élévations de privilèges — vérifier les politiques UAC

Un point souvent négligé que j'ai rencontré sur le terrain : si votre organisation utilise des politiques AppLocker ou WDAC (Windows Defender Application Control), ces politiques s'appliquent avant les règles EPM. Une application bloquée par WDAC ne sera pas débloquée par EPM. Vérifiez la compatibilité en amont. La documentation Microsoft EPM détaille les interactions avec ces mécanismes.

Les trois types d'élévation : lequel choisir pour quelle application ?

C'est la question centrale lors du déploiement. Le choix du type d'élévation détermine l'expérience utilisateur et le niveau de risque accepté.

Dans les déploiements que j'ai accompagnés, la répartition saine ressemble à ceci : 30% de règles Automatic pour les outils internes parfaitement maîtrisés, 60% de règles User-initiated avec justification obligatoire pour les applications métier standards, 10% de Support-approved pour les demandes exceptionnelles. Cette répartition équilibre sécurité et productivité sans créer de friction excessive.

Ma recommandation ferme : pour les règles Automatic, utilisez impérativement le hash SHA-256 en plus de l'éditeur. Un attaquant sophistiqué capable de signer un exécutable malveillant avec un certificat volé (scénario vu dans des supply-chain attacks en 2025) contournerait une règle basée uniquement sur la signature de l'éditeur. Le hash garantit que c'est le binaire exact attendu.

Comment créer une règle d'élévation dans le portail Intune ?

La configuration se fait dans le centre d'administration Intune sous Endpoint security → Endpoint Privilege Management → Policies → Create policy. Voici la procédure complète pour une règle de type User-initiated :

Configurer le workflow Support-approved : le bon processus

Le mode Support-approved crée un vrai workflow ITSM léger directement dans Intune. L'utilisateur soumet sa demande depuis la Company Portal app, un approbateur désigné reçoit une notification dans le portail Intune sous "Elevation requests", et peut approuver ou refuser avec un commentaire. Une fois approuvée, la fenêtre d'élévation est configurée entre 1h et 24h.

# Gérer les demandes d'approbation EPM via Microsoft Graph PowerShell
# Prérequis : module Microsoft.Graph.Beta installé

Connect-MgGraph -Scopes "DeviceManagementElevationRequest.ReadWrite.All"

# Lister toutes les demandes en attente d'approbation
$pending = Get-MgBetaDeviceManagementElevationRequest -Filter "status eq 'pending'"
$pending | Select-Object Id, DeviceName, Requestor, ApplicationName, Justification, CreatedDateTime | Format-Table -AutoSize

# Approuver une demande spécifique
$requestId = "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
Invoke-MgBetaApproveDeviceManagementElevationRequest `
    -ElevationRequestId $requestId `
    -ReviewComment "Approuvé - installation Sage 100 v9.1 validée par DRH" `
    -ExpirationDateTime (Get-Date).AddHours(4).ToUniversalTime().ToString("o")

# Refuser une demande
Invoke-MgBetaDenyDeviceManagementElevationRequest `
    -ElevationRequestId $requestId `
    -ReviewComment "Refusé - application non référencée. Ouvrir un ticket ITSM."

Un conseil pratique : créez des groupes d'approbateurs distincts par domaine fonctionnel. L'équipe finance approuve les demandes liées aux outils comptabilité, l'équipe RH approuve les outils RH, et l'IT central garde la main sur les demandes système. Cela responsabilise les métiers et évite les goulots d'étranglement au helpdesk.

Auditer et monitorer les élévations EPM

L'audit est natif et complet. Dans le centre d'administration Intune : Endpoint Privilege Management → Reports → Elevation report. Chaque événement inclut l'utilisateur, l'appareil, l'application (nom, chemin, hash), le type d'élévation, la règle correspondante, la justification fournie et le résultat.

Pour une intégration SIEM, les événements EPM arrivent dans Microsoft Defender for Endpoint (table DeviceEvents, ActionType EpmElevationResult ou EpmElevationApproved) et sont exportables vers Azure Monitor / Log Analytics.

# Requête KQL pour Microsoft Sentinel — détecter les élévations hors heures de bureau
// Alerte : élévation EPM hors plage horaire 8h-19h
DeviceEvents
| where ActionType in ("EpmElevationResult", "EpmElevationApproved")
| where Timestamp > ago(7d)
| extend Hour = datetime_part("Hour", Timestamp)
| where Hour < 8 or Hour > 19
| project Timestamp, DeviceName, AccountName, FileName, FolderPath,
          todynamic(AdditionalFields).ElevationType, todynamic(AdditionalFields).RuleName
| order by Timestamp desc

// Alerte : même utilisateur avec plus de 10 élévations par jour
DeviceEvents
| where ActionType == "EpmElevationResult"
| where Timestamp > ago(24h)
| summarize ElevationCount = count() by AccountName, DeviceName, bin(Timestamp, 1d)
| where ElevationCount > 10
| order by ElevationCount desc

Pour une visibilité complète sur votre posture de sécurité Microsoft 365, lisez notre article sur l'audit avancé des journaux Microsoft 365 et notre guide sur la détection des attaques Azure AD.

Automatiser la gestion EPM avec Microsoft Graph PowerShell

Pour les équipes qui gèrent des centaines de règles ou plusieurs tenants, l'automatisation via Microsoft Graph est indispensable. Le module Microsoft.Graph.Beta expose les cmdlets EPM.

# Inventaire complet des politiques EPM et de leurs règles
Connect-MgGraph -Scopes "DeviceManagementConfiguration.Read.All"

# Lister les politiques EPM
$epmPolicies = Get-MgBetaDeviceManagementConfigurationPolicy | Where-Object {
    $_.templateReference.templateFamily -eq "endpointPrivilegeManagement"
}

foreach ($policy in $epmPolicies) {
    Write-Host "Politique : $($policy.Name)" -ForegroundColor Cyan
    $settings = Get-MgBetaDeviceManagementConfigurationPolicySetting -DeviceManagementConfigurationPolicyId $policy.Id
    $settings | ForEach-Object {
        Write-Host "  Règle : $($_.SettingDefinitions[0].DisplayName)"
    }
}

# Exporter le rapport d'élévations des 30 derniers jours en CSV
$reportData = Get-MgBetaDeviceManagementElevationReport -Top 1000
$reportData | Select-Object DeviceName, UserName, ApplicationName, ElevationType,
    RuleName, RequestJustification, ApproverName, ElevationStatus, ElevationDateTime |
    Export-Csv "C:\Audit\EPM_Elevations_$(Get-Date -Format 'yyyyMMdd').csv" -NoTypeInformation -Encoding UTF8
Write-Host "Export terminé : $($reportData.Count) élévations exportées."

# Vérifier les appareils sans politique EPM assignée
$allDevices = Get-MgBetaDeviceManagementManagedDevice -Filter "operatingSystem eq 'Windows'"
$epmGroups = $epmPolicies | ForEach-Object {
    Get-MgBetaDeviceManagementConfigurationPolicyAssignment -DeviceManagementConfigurationPolicyId $_.Id
}
Write-Host "Appareils Windows gérés : $($allDevices.Count)"
Write-Host "Politiques EPM actives : $($epmPolicies.Count)"

EPM vs LAPS : deux outils complémentaires, pas concurrents

La confusion revient régulièrement. Non, EPM ne remplace pas LAPS (Local Administrator Password Solution). Ils opèrent à des niveaux différents et doivent coexister dans toute stratégie de sécurité des postes de travail mature.

LAPS gère le compte Administrateur local intégré (RID 500) : il génère un mot de passe aléatoire unique par machine, le stocke dans Entra ID ou AD DS, et le fait tourner régulièrement. Résultat : plus de risque de "passe-partout" admin sur tout le parc. LAPS ne dit rien sur qui peut utiliser ce compte, quand et pour quoi.

EPM gère l'élévation applicative pour les utilisateurs standard : il définit quelles applications peuvent s'exécuter avec des droits élevés, pour quels utilisateurs, dans quelles conditions. EPM ne touche pas au compte Administrateur local. Il permet aux utilisateurs de travailler sans droits permanents.

La stratégie recommandée : LAPS est actif sur tous les postes pour sécuriser le compte admin local (utilisé uniquement par les techniciens IT en cas d'urgence ou de dépannage), EPM est déployé pour permettre aux utilisateurs métier d'élever des applications spécifiques sans jamais connaître — ni utiliser — le mot de passe LAPS. Pour plus de contexte sur les audits M365, lisez notre article sur l'automatisation des audits Microsoft 365 avec PowerShell.

Bonnes pratiques pour un déploiement EPM réussi en entreprise

Après plusieurs déploiements EPM dans des PME et ETI françaises de 100 à 2000 postes, voici les enseignements concrets :

• Commencez par un mode audit : avant de créer des règles de blocage, activez EPM en mode "Report only" pendant 3 à 4 semaines. Vous capturerez toutes les élévations existantes et identifierez les applications qui en ont besoin. La liste sera bien plus longue que vous ne le pensez.
• Pilote sur 10-20 utilisateurs volontaires : choisissez des power users dans chaque département. Leurs retours en première semaine valent six mois de tests en lab.
• Documentez chaque règle : pourquoi existe-t-elle, qui l'a demandée, quelle application elle couvre, et quelle est sa date de révision. Une règle sans documentation est une règle oubliée.
• Combinez toujours au moins deux critères : nom de fichier seul = insuffisant. Ajoutez l'éditeur (signature) et si possible le hash. Pour les applications qui changent de hash à chaque mise à jour, éditeur + chemin + arguments est un bon compromis.
• Planifiez une revue trimestrielle des règles : les applications évoluent, les vendors changent de certificat, des applications sont abandonnées. Une règle EPM périmée est une surface d'attaque potentielle.
• Communiquez avec vos utilisateurs : expliquez pourquoi les droits admin ont été retirés et comment EPM les remplace. Un utilisateur qui comprend coopère. Un utilisateur frustré trouve des contournements — ou signale tout comme "bug" au helpdesk.

Pour une vision complète de la conformité dans votre tenant Microsoft 365, consultez notre guide sur les outils d'audit conformité Microsoft 365.

Résoudre les problèmes courants lors du déploiement EPM

Quelques situations que vous rencontrerez inévitablement en production :

• L'option "Exécuter avec élévation gérée" n'apparaît pas : vérifiez que le client EPM est bien déployé (visible dans Apps → App status), que l'appareil a redémarré après assignation de la politique, et que la licence Plan 2 est bien assignée à l'utilisateur — pas seulement à l'appareil.
• Une application est élevée mais plante immédiatement : certaines applications installent des services ou accèdent à des ressources réseau nécessitant des droits supplémentaires. Vérifiez avec Process Monitor si des accès sont refusés, et ajustez les critères de la règle ou activez l'élévation des processus enfants en dernier recours.
• Le hash SHA-256 ne correspond pas après mise à jour : comportement attendu. Mettez à jour la règle avec le nouveau hash ou passez en mode éditeur + chemin pour cette application. La politique sera récupérée par l'appareil dans les 15 minutes suivant la modification (ou immédiatement après une synchronisation manuelle depuis l'application Paramètres → Accès professionnel).
• Les demandes Support-approved ne génèrent pas de notification : configurez les notifications d'approbation dans Intune Administration → Tenant administration → Notifications et créez un template de notification pour le rôle Helpdesk Operator. Sans cela, les approbateurs doivent vérifier manuellement le tableau de bord.

Questions fréquentes

Intune EPM fonctionne-t-il avec Windows 10 ?

Oui, EPM est supporté sur Windows 10 version 22H2 et supérieure. Cependant, Microsoft recommande Windows 11 22H2+ pour la meilleure expérience, notamment pour l'interface Company Portal qui gère les Support Approvals. Sur Windows 10, certaines fonctionnalités d'interface sont moins polies mais le moteur de règles fonctionne identiquement. Si votre parc est mixte Windows 10/11, une seule politique EPM s'applique aux deux sans configuration séparée.

Peut-on tester EPM sans la licence complète Intune Plan 2 ?

Oui, Microsoft propose un essai gratuit de 90 jours pour Intune Plan 2 (ou Intune Suite) via le portail M365 Admin Center sous Facturation → Services d'achat. Cela suffit pour un projet pilote complet. Attention : à l'expiration de l'essai, les politiques EPM restent en place mais ne s'appliquent plus aux appareils — les utilisateurs reprennent leur comportement habituel sans les règles d'élévation.

EPM peut-il couvrir les applications 32 bits et les scripts PowerShell ?

EPM couvre les exécutables Windows (PE 32 et 64 bits), les MSI, les MSIX et les scripts PowerShell. Pour les scripts PS1, la règle doit cibler powershell.exe ou pwsh.exe avec l'argument spécifiant le chemin du script. La granularité est suffisante pour la plupart des scénarios d'entreprise. Les scripts BAT et les applications Java (via java.exe) sont également gérables avec les arguments de ligne de commande comme critère discriminant.

Comment gérer la mise à jour des règles quand le hash SHA-256 change ?

C'est le principal frein opérationnel d'EPM. Trois approches selon le contexte : (1) Pour les applications avec des MAJ fréquentes, utiliser éditeur + chemin sans hash — moins précis mais auto-adaptatif. (2) Pour les applications critiques, maintenir une liste de hashes valides via Graph API et automatiser la mise à jour avec un script PowerShell déclenché par un webhook. (3) Pour les applications internes, distribuer via Intune en Package Win32 — le hash est alors maîtrisé. La documentation Microsoft sur les règles EPM détaille ces scénarios.

EPM remplace-t-il complètement BeyondTrust ou CyberArk pour la gestion des privilèges ?

Pour les PME et ETI déjà dans l'écosystème Microsoft, EPM couvre 80 à 90% des besoins de gestion des privilèges sur les postes Windows. Les solutions tierces comme BeyondTrust ou CyberArk apportent plus de profondeur sur des scénarios avancés : gestion des sessions privilégiées (enregistrement vidéo), couverture multi-OS (Linux, macOS), intégration PAM pour les serveurs. Si votre périmètre est exclusivement Windows et Microsoft 365, EPM est suffisant. Si vous avez des exigences PAM server-side ou un environnement hétérogène, une solution tierce reste pertinente en complément.