Conditional Access richtig planen: Warum Device Compliance allein nicht reicht

In vielen Tenants stützt sich das Conditional-Access-Konzept auf eine einzige Grant Control. Meist lautet sie:

Require compliant device

Diese Vorgabe wirkt auf den ersten Blick umfassender, als sie ist. Entra ID prüft damit, ob das verwendete Gerät die in Intune festgelegten Anforderungen erfüllt. Über die Person hinter der Anmeldung, das aktuelle Anmelderisiko oder den Zugriffskontext sagt dieser Status wenig aus.

Device Compliance bleibt deshalb ein wichtiger Baustein, bildet aber kein vollständiges Sicherheitskonzept. Für eine belastbare Zugriffsentscheidung musst du den Gerätestatus mit weiteren Signalen verbinden und auf jedes erkannte Risiko mit einer passenden Kontrolle reagieren.

Was Device Compliance abdeckt

Ein Gerät gilt als compliant, sobald es die in Intune definierten Compliance-Regeln erfüllt. Du kannst dort zum Beispiel vorgeben, dass BitLocker aktiv sein muss, Microsoft Defender einen bestimmten Status melden soll und nur unterstützte Betriebssystemversionen zugelassen sind. Auch die von Defender for Endpoint gemeldete Geräterisikostufe kann in die Bewertung einfließen.

Der Begriff compliant besitzt deshalb keine feste Aussagekraft. Er fasst lediglich das Ergebnis deiner eigenen Compliance-Richtlinien zusammen. Wenn diese Richtlinien nur wenige oder schwache Anforderungen enthalten, bleibt auch ein als compliant markiertes Gerät entsprechend schwach abgesichert.

Hinzu kommt, dass Intune mit diesem Status das Gerät bewertet und nicht die gesamte Anmeldung. Ein Angreifer kann gültige Zugangsdaten besitzen, eine bestehende Sitzung missbrauchen oder von einem auffälligen Standort zugreifen. Das Gerät kann dabei weiterhin alle Compliance-Vorgaben erfüllen. Eine Policy mit Require compliant device erfasst somit nur einen klar abgegrenzten Teil des Risikos.

Conditional Access verbindet Signale und Kontrollen

Bei jeder Anmeldung stehen Entra ID mehrere Informationen zur Verfügung. Dazu gehören die Identität, der Zustand und die Einbindung des Geräts, der Standort sowie das Benutzer- und Anmelderisiko. Conditional Access führt diese Signale anhand deiner Policies zusammen und entscheidet, welche Bedingungen eine Anmeldung erfüllen muss.

Abhängig von diesen Signalen kann eine Policy den Zugriff gewähren oder blockieren. Sie kann außerdem MFA, ein compliant markiertes Gerät oder einen bestimmten Join-Status verlangen. Wählst du mehrere Grant Controls aus, musst du zusätzlich festlegen, ob eine davon genügt oder ob die Anmeldung alle ausgewählten Bedingungen erfüllen soll. Gerade diese kleine Einstellung hat großen Einfluss auf die Schutzwirkung einer Policy.

Die Lücken einer einzelnen Grant Control

In einer einfachen Umgebung sieht die zentrale Policy häufig so aus:

IF User = All Users
THEN Require compliant device

Die Policy kontrolliert den Gerätestatus konsequent, lässt aber mehrere Angriffswege offen. Ohne MFA können gültige, gestohlene Zugangsdaten für einen Zugriff ausreichen. Ohne risikobasierte Bedingungen berücksichtigt Entra ID seine Erkenntnisse über auffällige Benutzer oder Anmeldungen nicht. Auch bekannte und ungewöhnliche Zugriffssituationen behandelt die Policy gleich. Die folgende Tabelle fasst diese Lücken zusammen:

Ein Angreifer muss in diesem Aufbau also nur die eine geprüfte Bedingung erfüllen. Sobald er eine Anmeldung von einem compliant markierten Gerät oder über eine bereits bestehende Sitzung zustande bringt, bietet die Policy keine weitere Hürde. Der Gerätestatus bleibt korrekt, obwohl die konkrete Anmeldung riskant sein kann.

Mehrere Schutzebenen gezielt kombinieren

Ein tragfähiges Konzept beginnt weiterhin beim Device State, denn ein verwaltetes und compliant markiertes Gerät reduziert die Angriffsfläche. Dazu kommt MFA, damit gültige Zugangsdaten allein keinen Zugriff ermöglichen. Über die Risk Evaluation beziehst du Hinweise auf kompromittierte Konten und auffällige Anmeldungen ein. Der Context ergänzt schließlich Informationen über die Zielanwendung, den Standort, die Plattform und die Sitzung. Aus diesen Bereichen entsteht kein einzelner großer Schalter, sondern eine kleine Gruppe von Policies mit klar getrennten Aufgaben.

Beispiel für eine Baseline

Die Policy-Architektur im Überblick

Für eine kompakte Ausgangsbasis kannst du die Kontrollen auf drei Policies verteilen. Die Baseline schützt reguläre Anmeldungen mit MFA und Device Compliance. Zwei weitere Policies reagieren auf ein erhöhtes Anmelde- oder Benutzerrisiko:

Diese Trennung erleichtert den Betrieb, weil jede Policy eine klar erkennbare Aufgabe erfüllt. Bevor du sie aktivierst, kannst du sie im Report-only-Modus testen und die Auswirkungen in den Sign-in Logs prüfen. Ausnahmen für Notfallkonten gehören ebenfalls in die Planung, damit eine fehlerhafte Zuweisung dich nicht aus dem Tenant aussperrt.

Die genaue Kombination hängt von deinen Lizenzen, den eingesetzten Gerätetypen und den vorhandenen Wiederherstellungsprozessen ab. Device Compliance liefert dabei weiterhin ein wertvolles Gerätesignal. Erst im Zusammenspiel mit MFA und den Risikoinformationen von Entra ID entsteht daraus eine Zugriffsentscheidung, die auch die Person und die konkrete Anmeldung berücksichtigt.