Conditional Access ohne Device Compliance ist eine verschlossene Tür ohne Rahmen

Die meisten Conditional-Access-Deployments beginnen bei der Identität und hören dort auch wieder auf. MFA erzwingen, Legacy-Auth blocken, fertig. Das ist ein Anfang, aber es ist eine Tür, die man in eine Wand ohne Rahmen gesetzt hat: Sie schließt, aber sie hält nichts auf, das um sie herum geht.

Der fehlende Rahmen ist der Zustand des Endpoints. Ein authentifizierter User auf einem unmanaged, nicht-compliant Gerät ist kein kontrollierter Zugriff — es ist ein kontrollierter Login gefolgt von unkontrollierter Ausführung. Session-Token, OAuth-Grants und Refresh-Tokens leben auf genau dem Gerät, dessen Patch-Stand, Disk-Encryption und EDR-Status niemand geprüft hat.

Device Compliance ist die tragende Bedingung

require compliant device oder require Hybrid Azure AD joined device als Grant Control verschiebt die Kontrolle von “wer bist du” zu “von wo aus, und in welchem Zustand”. Intune liefert das Compliance-Signal, Entra ID wertet es in der Policy aus. Erst diese Kopplung macht aus Conditional Access eine Zugangskontrolle statt einer Anmeldekontrolle.

Der Reihenfolge-Fehler, den ich am häufigsten sehe: Compliance wird als Reporting-Feature behandelt, nicht als Grant Control. Man sammelt den Zustand ein, aber man macht ihn nie zur Bedingung. Das Dashboard ist grün, die Policy ist trotzdem blind.

Der Übergang muss geplant sein

Der Grund, warum diese Bedingung oft fehlt, ist selten Unwissen — es ist Angst vor dem Lockout. Zu Recht: Eine harte require compliant device-Policy über einen unvorbereiteten Gerätebestand sperrt am Montagmorgen die halbe Belegschaft aus.

Der Weg dahin ist ein Report-only-Rollout, eine saubere Compliance-Baseline in Intune und eine Ausnahme-Strategie, die man auditieren kann. Aber das Ziel bleibt dasselbe: Die Tür bekommt einen Rahmen, und der Rahmen ist der Zustand des Geräts.