Intune Endpoint Privilege Management vs. die Alternativen
- Florian Salzmann
- Veröffentlicht am 12 Jun, 2026
- Aktualisiert am 12 Jun, 2026
- 06 Mins read
- Microsoft Intune
Ich entziehe lokale Admin-Rechte, wo immer ich kann. Bei den meisten Fleets, die ich betreue, sind die Benutzer bereits Standardbenutzer, und genau das ist das Ziel.
Aber es gibt immer ein paar Ausnahmen. Ein Team mit einer Nischenapplikation. Ein Installer, den die IT nicht schnell genug umpaketieren und über Intune ausrollen kann. CAD-Benutzer, die je nach Projekt in der jeweiligen Woche für ihr Tooling elevaten müssen und danach wieder zurückfallen.
Genau bei dieser letzten Meile wird Least Privilege schwierig. Du willst nicht wegen zwei Apps und einer Handvoll Benutzer gleich wieder vollen lokalen Admin vergeben. Du willst, dass nur diese spezifischen Aufgaben elevaten, und sonst nichts.
Genau diese Lücke schliesst Microsoft Intune Endpoint Privilege Management. Ich habe es in produktiven Tenants betrieben, direkt mit den üblichen Marktteilnehmern verglichen, und dieser Beitrag ist die ehrliche Version dessen, was ich dabei herausgefunden habe.
Was Intune Endpoint Privilege Management eigentlich ist
Intune Endpoint Privilege Management, kurz EPM, lässt einen Standardbenutzer eine bestimmte Aufgabe mit erhöhten Rechten ausführen, ohne dass er lokaler Administrator sein muss.
Du definierst, welche signierten Dateien oder Aufgaben elevaten dürfen. Die Elevation läuft über den EPM-Agent, oft innerhalb eines isolierten virtuellen Kontos, sodass der elevierte Prozess das Benutzerprofil nie berührt. (Du hast aber auch die Option, es als aktueller Benutzer auszuführen.)
Es gibt vier Regel-Verhalten: Automatic, User confirmed, Support approved und Deny.
Eines möchte ich vorab klarstellen. EPM ist Endpoint Least Privilege. Es ist keine vollständige Privileged-Access-Management-Plattform. Es verwaltet keine Credentials in einem Vault, rotiert keine Secrets und zeichnet keine privilegierten Sessions auf Servern auf. Behalte diesen Scope für den folgenden Vergleich im Hinterkopf.
Warum lokale Admin-Rechte immer noch das eigentliche Problem sind
Die Gefahr liegt selten im Bestand, den du bereits bereinigt hast. Sie liegt in den wenigen Ausnahmen, die du stehen liessen, damit ein, zwei Teams weiterarbeiten konnten.
Diese Ausnahmen sind nach wie vor lokaler Admin. Microsofts eigener Digital Defense Report 2025 hat festgestellt, dass die grosse Mehrheit der Ransomware-Angriffe Remote-Management-Tools auf Endpoints berührt hat. Lokaler Admin ist das, was aus einem Foothold eine vollständige Kompromittierung macht, und ein einziger ausgenommener Benutzer reicht dafür bereits aus.
Die eigentliche Aufgabe ist also nicht, Admin-Rechte zu entfernen. Sie besteht darin, diese letzten Ausnahmen zu schliessen, ohne den Service Desk zu überfluten. Genau darum geht es bei einer Elevation-Lösung: Benutzer bleiben Standardbenutzer, nur die Handvoll Aufgaben, die es wirklich brauchen, elevaten, und jede einzelne davon wird protokolliert.
Womit du EPM tatsächlich vergleichst
Wenn du EPM nur mit den grossen PAM-Giganten vergleichst, vergleichst du die falschen Dinge. Hier ist die ehrliche Übersicht in der Kategorie Endpoint Least Privilege.
- CyberArk und BeyondTrust liefern ausgereifte Endpoint-Privilege-Produkte innerhalb breiterer PAM-Plattformen. Tiefe Policy-Engines, jahrelanges Regel-Tuning und Abdeckung weit über Windows hinaus. CyberArk hält den grössten PAM-Marktanteil.
- Delinea bietet Endpoint Least Privilege mit einem für den Midmarket freundlichen Footprint, direkt neben seinem Secret- und Server-PAM-Tooling.
- Admin By Request wird durchgehend für einfaches Deployment und eine saubere User Experience gelobt, inklusive plattformübergreifender Abdeckung.
- ThreatLocker nähert sich der Elevation über seine Application-Control- und Ringfencing-Story, weshalb es Teams anspricht, die bereits Allowlisting betreiben.
Keines dieser Tools ist schlecht. Mehrere sind sogar exzellent. Die richtige Frage ist nicht, welches abstrakt das beste ist. Sie lautet, welches zu dem Bestand passt, den du bereits betreibst.
Wo Intune Endpoint Privilege Management wirklich differenziert ist
Genau hier lande ich zugunsten von Intune Endpoint Privilege Management für eine Microsoft-first-Flotte, und zwar aus folgenden Gründen.
Keine neue Infrastruktur, keine zweite Konsole. EPM läuft über den Intune-Agent und lebt im Microsoft Intune Admin Center, das du bereits betreibst. Es gibt keine separate Appliance, keinen zusätzlichen Policy-Server, keinen neuen Agent-Stack, den du patchen und zertifizieren musst. Für ein schlankes Team zählt das mehr als jede Feature-Checkbox.
Nativer Identitäts- und Gerätekontext. Regeln zielen auf Entra-ID-Gruppen. Sie stehen direkt neben deinen Compliance-Richtlinien, deinem Settings Catalog und dem Rest deiner Endpoint-Posture an einem Ort. Du musst kein weiteres Produkt in deine Identitätsebene einflechten.
Threat-Kontext direkt in der Genehmigungsentscheidung. Wenn eine Support-approved-Anfrage eintrifft, kannst du die Datei mit Security Copilot analysieren, gestützt auf Microsoft Defender Threat Intelligence, bevor du genehmigst oder ablehnst. Das Risikosignal sitzt direkt neben der Anfrage. Kein anderer Anbieter verdrahtet Endpoint-Elevation mit demselben Threat-Graph wie deine XDR.
Sinnvolles Elevation-Modell. Automatic für vertrauenswürdiges Tooling, User confirmed für alltägliche Aufgaben, Support approved für den Long Tail, Deny für bekannt Böses. Wiederverwendbare Settings-Gruppen halten deine Signaturzertifikate einmal fest und geben Updates an jede Regel weiter, die darauf verweist.
Es ist jetzt Teil der Lizenz, die du ohnehin schon kaufst. Mehr dazu weiter unten, aber die Kurzversion: Der Budgetkampf ist grösstenteils vorbei.
Wo die Alternativen weiterhin vorne liegen
Ich werde nicht so tun, als würde EPM bei allem gewinnen. Das tut es nicht.
Plattformabdeckung. EPM ist heute nur für Windows verfügbar. Wenn du Least Privilege auf macOS- oder Linux-Endpoints brauchst, decken BeyondTrust, CyberArk und Admin By Request Boden ab, den EPM nicht abdeckt.
Track Record. Diese Plattformen haben ein Jahrzehnt an Referenzen. EPM ist neuer. Für stark regulierte Käufer zählt diese Historie immer noch etwas.
Uneingeschränkte Elevation. EPM elevatet nach Regel. Du definierst einen Publisher, ein Zertifikat oder einen Hash, oder du behandelst den Long Tail über Support approved. Manchmal passt das nicht. Ein Entwickler kompiliert bei jedem Build ein neues Binary, also gibt es keinen stabilen Hash und oft keine Signatur. Er will alles spontan elevaten, ohne auf eine Genehmigung zu warten. EPM bietet das nicht an, und das ist bewusst so: offene Selbst-Elevation ist genau das, was Least Privilege verhindern soll. Für manche Teams bleibt das aber eine echte Lücke. Admin By Request kann zum Beispiel eine zeitlich begrenzte Admin-Session gewähren, in der der Benutzer alles elevatet, was er braucht. Für diese Use Cases gewinnen die Alternativen.
Sei ehrlich mit dir selbst, welche davon du wirklich brauchst. Für die meisten Windows-first-Umgebungen sind keine davon Blocker. Und für DEV-Umgebungen könntest du beispielsweise eine separate Windows 365 Cloud PC mit Admin-Rechten in einem nicht verbundenen Netzwerk betreiben.
Wie es sich für Enterprise, SMB und Government auswirkt
Enterprise. Wenn du bereits den Microsoft-Security-Stack betreibst, konsolidiert EPM ein Tool, das du sonst separat kaufen und betreiben müsstest. Prüfe die Plattformabdeckung und ob du zusätzlich vollständiges PAM brauchst. Wo die Antwort Windows Least Privilege lautet, ist EPM der Weg des geringsten Widerstands.
SMB. Das ist der Sweet Spot. Keine Appliance, die du aufsetzen musst, keine zusätzliche Konsole, die du lernen musst, und ein Elevation-Reporting, das ein kleines Team tatsächlich im Griff behalten kann. Der geringere operative Aufwand zählt hier mehr als überall sonst.
Government. Least Privilege ist zunehmend ein Mandat, keine Präferenz mehr. EPM hält die Control Plane innerhalb der Microsoft Cloud, die diese Tenants ohnehin bereits betreiben, passt sauber zu Zero Trust und protokolliert jede einzelne Elevation. Prüfe zuerst deine Umgebungs- und Datenresidenz-Anforderungen, bevor du bewertest.
So sieht das Deployment in der Praxis aus
Ich halte das kurz, denn das Setup ist nicht das Schwierige an EPM. Das Denken ist die eigentliche Arbeit, nicht die Klicks.
Ein Grundsatz entscheidet darüber, wie sich der gesamte Rollout anfühlt. Ziel ist keine Admin-Rechte als Standard, nicht als etwas, das du später wegnimmst.
Wenn du einen Benutzer mit Admin startest und ihm die Rechte später wieder entziehst, spürt er den Verlust und beschwert sich. Startest du ihn standardmässig und gibst ihm EPM, um seine eigenen Elevationen zu lösen, bedankt er sich stattdessen bei dir.
Der Rollout ist eine kurze Schleife. Du schaltest EPM im Audit-Modus ein, lässt dir über den Elevation-Report zeigen, was Benutzer tatsächlich elevated ausführen, und baust anschliessend Regeln aus diesen echten Daten auf. Vertrauenswürdiges signiertes Tooling geht zu Automatic, alltägliche Aufgaben zu User confirmed, und der Long Tail zu Support approved. Erst wenn deine Regeln die gängigen Fälle abdecken, migrierst du Benutzer vom lokalen Administrator zum Standardbenutzer.
Das ist im Grunde die ganze Form davon. Eine grossartige Walkthrough/Starter-Anleitung von Peter findest du hier: All about Microsoft Intune | Getting started with Endpoint Privilege Management
Testing und Verifizierung
Beweise zuerst die Baseline. Bestätige, dass der Pilotbenutzer kein lokaler Administrator mehr ist.
# Confirm the signed in user is a standard user, not a local admin
$me = "$env:USERDOMAIN\$env:USERNAME"
$admins = Get-LocalGroupMember -Group "Administrators" | Select-Object -ExpandProperty Name
if ($admins -contains $me) {
Write-Output "Still a local admin. EPM cannot prove its value here yet."
} else {
Write-Output "Standard user confirmed. Good baseline for EPM."
}
Teste anschliessend eine Elevation end to end:
- Rechtsklick auf eine Zieldatei und Run with elevated access wählen.
- Bei einer User-confirmed- oder Support-approved-Regel eine geschäftliche Begründung angeben.
- Bestätigen, dass die Aufgabe mit Elevation abgeschlossen wird, danach den Elevation-Report unter Endpoint security > Endpoint Privilege Management prüfen.
- Bei einer Support-approved-Anfrage die Anfrage öffnen, die Datei mit Security Copilot analysieren und genehmigen oder ablehnen.
Wenn die Elevation mit der richtigen Datei, dem richtigen Benutzer und der richtigen Begründung im Report erscheint, funktioniert deine Schleife.
Möchtest du zusätzlich verhindern, dass unerwünschte Installer überhaupt erst zum Elevation-Prompt gelangen, kombinierst du EPM mit Application Control.
Die Packaging-Änderung, die du kennen solltest
Hier kommt der Teil, der die Rechnung verändert. Intune Endpoint Privilege Management ist jetzt in Microsoft 365 E5 enthalten, statt hinter einem separaten Premium-Add-on zu stehen.
Die erweiterten Intune-Funktionen rollen im Verlauf von 2026 aus, mit der kommerziellen Listenpreisänderung ab dem 1. Juli 2026. Zahlst du EPM bereits als Add-on, fliesst es ab diesem Datum in deine E5-Lizenz ein.
Jahrelang war der Standalone-Preis der Grund, weshalb Pilotprojekte ins Stocken gerieten. EPM kostete etwa drei US-Dollar pro Benutzer und Monat als Einzelprodukt. Die E5-Inklusion federt das und mehr für einen deutlich kleineren Listenpreis-Aufschlag ab. Der Budgeteinwand, der so viele Evaluierungen getötet hat, ist damit vom Tisch.
Allein das ist Grund genug, es jetzt zu evaluieren, bevor deine nächste Verlängerung feststeht.
Betreibst du eine Windows-first-Flotte auf Microsoft 365 E5, ist Intune Endpoint Privilege Management die Least-Privilege-Kontrolle mit dem grössten Impact und dem geringsten Aufwand, die du einschalten kannst. Keine neue Infrastruktur, nativer Threat-Kontext, und jetzt auch keine zusätzliche Lizenz mehr. Der ehrliche Vorbehalt: Brauchst du macOS, Linux oder vollständiges PAM, behalte dein Spezialtool und lass EPM Windows übernehmen. Starte im Audit-Modus, baue auf echten Daten auf, und entziehe erst danach die Admin-Rechte.
