Sektion 19: Compliance Policies: Definition von ‚Healthy‘ Devices

Einleitung: „Healthy“ ist kein Status, sondern ein Vertrag

Conditional Access prüft die Identität: Passwort, MFA, Risikolevel, Anmeldeort. Aber keines dieser Signale sagt etwas über die Maschine aus, von der aus die Anmeldung passiert. Ein gestohlener Session-Cookie authentifiziert sich von einem kompromittierten Rechner exakt so sauber wie die gleiche Anmeldung vom gepatchten Firmenlaptop. Die Identität beweist, dass die Person berechtigt ist – nicht, dass das Gerät es ist.

Genau diese Lücke schließt die Compliance-Policy. Sie ist der Baustein, mit dem Intune eine technische, maschinenprüfbare Definition von „gesund“ aufstellt: Secure Boot gesetzt, BitLocker aktiv, Firewall an, Defender scharf, Betriebssystem in unterstützter Version. Conditional Access macht daraus eine harte Grenze über die Grant-Control „Require device to be marked as compliant“. Wer diese Definition nicht hat, betreibt Zero Trust als Folklore: Die Tür ist zu, aber niemand prüft das Schloss.

Diese Sektion ist eine der wichtigsten des gesamten Masterkurses, weil sie die Brücke zwischen Device Management und Security-Architektur bildet. Ohne Compliance-Policies gibt es keinen sauberen Weg, den Zugriff auf Microsoft 365 an den Zustand des Endpoints zu koppeln. Mit ihnen baust du ein System, in dem ein infiziertes oder veraltetes Gerät automatisch den Zugriff auf Unternehmensdaten verliert – ohne dass ein Mensch eingreifen muss.

Grundkonzepte: Wie Intune Compliance denkt

Konfigurationsprofil vs. Compliance-Policy: Schreiben vs. Lesen

Der wichtigste Unterschied, den Administratoren am Anfang häufig durcheinanderbringen: Ein Konfigurationsprofil ist imperativ – es bringt das Gerät in einen Zustand („BitLocker aktivieren“). Eine Compliance-Policy ist deklarativ – sie misst, ob der Zustand erreicht ist („Ist BitLocker aktiv?“). Die Compliance-Policy ändert nichts am Gerät. Sie bewertet nur.

Daraus folgen drei Konsequenzen:

• Noncompliance entsteht nicht durch die Policy, sondern durch das Gerät. Eine Compliance-Policy kann ein Gerät niemals „kaputtmachen“ – sie kann nur sichtbar machen, dass es bereits kaputt ist.
• Erst die Kombination ist stark. Die bewährte Architektur: Ein Konfigurationsprofil stellt einen Zustand her (BitLocker via Profil aktivieren), die Compliance-Policy überwacht ihn (BitLocker-Status prüfen). Konfiguration ist die Therapie, Compliance ist der Gesundheitscheck.
• Compliance ist ein Berichts- und Enforcement-Signal. Der Zustand fließt in Reports, in das Company Portal des Nutzers und – entscheidend – in Conditional Access.

Die fünf Zustände eines Geräts

Jedes verwaltete Gerät hat in Intune einen Compliance-Zustand, der an zentraler Stelle unter „Geräte → Compliance“ sichtbar ist:

• Compliant: Das Gerät erfüllt alle zugewiesenen Anforderungen. Nur dieser Zustand erfüllt die Conditional-Access-Bedingung.
• Not compliant: Mindestens eine Anforderung ist verletzt – etwa der Firewall deaktiviert. Das Gerät bleibt verwaltet, aber Conditional Access kann den Zugriff blockieren.
• In grace period: Das Gerät hat gegen eine Regel verstoßen, aber die Karenzzeit läuft noch. Es gilt als „provisional compliant“ – die Nutzer bekommen Zeit zum Reagieren, ohne sofort ausgesperrt zu werden.
• Error: Die Evaluierung selbst ist fehlgeschlagen – häufig Kommunikationsprobleme, Attestation-Fehler oder widersprüchliche Platform-Konfigurationen. Error ist ein Infrastruktur-Problem, kein Nutzer-Problem, und gehört immer zuerst analysiert.
• Not applicable / not evaluated: Für das Gerät ist keine passende Compliance-Policy zugewiesen, oder die Evaluierung läuft noch. Achtung: In diesem Zustand verhält sich das Gerät bei Conditional Access wie ein noncompliantes Gerät – sofern die Mandanten-Einstellung „Geräte ohne Compliance-Policy als noncompliant markieren“ aktiv ist (die Standardeinstellung).

Der Evaluationszyklus: Wann wird geprüft?

Compliance ist kein Dauerstrom, sondern ein periodischer Snapshot. Windows-Geräte evaluieren ihre Compliance-Policies:

• bei der Enrollment unmittelbar nach dem Onboarding,
• alle 8 Stunden im regulären MDM-Check-in-Zyklus,
• bei bestimmten Live-Einstellungen (etwa Firewall-Status, Antivirus-Schutz) bei jedem einzelnen Check-in, und
• bei jedem manuellen Sync aus dem Company Portal.

Das bedeutet für die Praxis: Wenn du eine Policy änderst, dauert es bis zu 8 Stunden, bis der Bestand den neuen Stand reflektiert. Für Tests immer den manuellen Sync verwenden – das ist der schnellste Weg, Feedback zu bekommen.

Device Health Attestation: Kryptografischer Nachweis statt Selbstauskunft

Ein Kernstück der Windows-Compliance ist die Device Health Attestation (DHA). Das Betriebssystem attestiert über das TPM kryptografisch nachweisbare Eigenschaften der Boot-Kette: War Secure Boot während des Bootvorgangs aktiv? Wurde Early Launch Antimalware geladen? Ist Code Integrity (HVCI) aktiv? Diese Messwerte werden gegen Microsofts Attestation-Service geprüft, und Intune wertet das Ergebnis aus. Das ist kein simples Auslesen eines Registry-Werts, das Malware fälschen könnte – das ist ein vom TPM signierter Beweis über den Zustand beim Boot.

Folge: Die Device-Health-Einstellungen einer Compliance-Policy sind die einzigen, die Aussagen über den Boot-Zustand treffen können – und gleichzeitig die, die am häufigsten false negatives auf Virtualisierung produzieren. Genauere 1.0-Generation-VMs kennen schlicht kein UEFI Secure Boot. Darauf gehen wir im Troubleshooting ein.

Grace Period und Aktionen für Noncompliance

Compliance ohne Eskalationsmechanismus ist ein Statusreport. Compliance mit Aktionen ist ein Kontrollsystem. Jede Compliance-Policy definiert eine Timeline von Aktionen, die bei Noncompliance ausgelöst werden:

• Mark device as noncompliant: Der eigentliche Schalter. Sein Schedule (sofort bis 30 Tage) ist zugleich die Grace Period. Erst wenn diese Aktion greift, wird das Gerät als „effective noncompliant“ markiert und Conditional Access sperrt. Davor gilt es als „in grace period“.
• Send email: Informiert den Endnutzer über den Verstoß – mit Vorlagen-Variablen für Gerätename, Verstoß und Helpdesk-Link.
• Send push notification: Erzeugt eine Meldung im Company Portal.

Eine sinnvolle Timeline für den Mittelbau sieht so aus: E-Mail bei Tag 1 („BitLocker ist auf Ihrem Gerät nicht aktiv – bitte wenden Sie sich an den Helpdesk“), Push bei Tag 2, Markierung als noncompliant bei Tag 3. Der Nutzer wird nie kalt ausgesperrt, sondern hat 72 Stunden Reaktionsfenster – und die Karenzzeit läuft auch übers Wochenende.

Compliance trifft Conditional Access

Der Enforcement-Pfad: In Entra ID erstellst du eine Conditional-Access-Richtlinie mit der Grant-Control „Require device to be marked as compliant“. Bei jeder Anmeldung wird live der Compliance-Zustand aus Intune abgefragt. Die Konsequenz: Noncompliance in Intune ist nicht länger ein Dashboard-Wert, sondern ein harter Zugriffshebel. Ein Laptop mit deaktiviertem Defender verliert in dem Moment den Zugriff auf Exchange Online, SharePoint und Teams, in dem die Grace Period abläuft.

Praxis-Implementierung: Eine produktionsreife Baseline bauen

Schritt 1: Mandantenweite Compliance-Einstellungen prüfen

Bevor die erste Policy entsteht: Im Intune-Portal unter „Geräte → Compliance“ die globalen Einstellungen prüfen. Dort stehen zwei der am häufigsten übersehenen Regeln des gesamten Konstrukts:

• „Geräte ohne Compliance-Policy als noncompliant markieren“: Muss aktiv sein. Sonst entsteht eine Sicherheitslücke: Jedes Gerät, dem versehentlich keine Policy zugewiesen wurde, gilt automatisch als compliant und erhält Zugang. Mit der Einstellung wird Nicht-Managemant zur Noncompliance.
• Compliance-Status-Gültigkeitsdauer: Standard 30 Tage. Geräte, die sich länger nicht melden, werden automatisch noncompliant. Für geräuschlose, verlorene oder stillgestellte Laptops ist das die letzte Sicherheitslinie – halte den Wert bei 30 Tagen oder kürzer.

Schritt 2: Die Windows-Baseline-Policy erstellen

Im Portal: „Geräte → Compliance-Policies → Create → Windows 10/11“. Die entscheidenden Einstellungsgruppen im Detail:

Device Health – das Herzstück:

• Require Secure Boot enabled: Prüft via DHA, ob Secure Boot beim Boot aktiv war. Hardware ohne UEFI kann das nicht erfüllen – auf Altgeräten vorher den Fleet-Status prüfen.
• Require Code Integrity: Verlangt hypervisor-enforced Code Integrity (HVCI). Das ist Memory Integrity unter Windows-Sicherheit – prüfe vorher, welche Treiber im Bestand HVCI blocken, sonst baust du dir eine Support-Welle.
• Require Early Launch Antimalware: Ein Windows-10-Setting; prüft via DHA, ob ELAM beim Boot geladen wurde.
• Require BitLocker: Verlangt, dass das Betriebssystemlaufwerk verschlüsselt ist. Wichtig: Nicht die Verschlüsselung wird erzwungen – ihr Vorhandensein wird geprüft. Die Aktivierung gehört in ein Konfigurationsprofil (Sektion 14).

System Security:

• Firewall: Require – Windows-Firewall muss aktiv sein. Live-Check bei jedem Check-in, daher der schnellste Indikator für manipulierte Geräte.
• Microsoft Defender Antivirus: Muss aktiv und mit Echtzeitschutz laufen. Werden die Defender-Einstellungen im Bestand über eine Nicht-Microsoft-Endpoint-Security-Lösung verwaltet, diese Compliance-Settings weglassen – sonst entsteht ein Dauerfehler.
• SmartScreen: Muss aktiv sein.

Password – modern und NIST-800-63B-konform:

• Password required: Ja, Block simple passwords: Ja
• Minimum length: 12 Zeichen (Länge schlägt Komplexität)
• Password expiration: 0 – keine erzwungene Rotation. Rotierende Passwörter erzeugen schwache Muster wie „Sommer2026!“ und sind moderner Sicherheitslehre widersprechend.
• Inactivity before lock: 5 Minuten – das ist zugleich ein Data-Protection-Setting.

Operating System:

• Minimum OS version: Zum Beispiel „10.0.22631“ (Windows 11 23H2) oder „10.0.19045“ (Windows 10 22H2). Das Format ist die Build-Nummer, nicht die Marketing-Version.
• Maximum OS version mit Vorsicht: Nützlich, um Rollouts neuer Windows-Versionen zu kontrollieren – aber in Produktion ein permanentes Risiko. Wenn ein Feature-Update automatisch durchrollt und die Max-Version nicht rechtzeitig angehoben wird, sperrt du den halben Bestand aus. Wenn überhaupt: nur in Übergangsphasen verwenden und mit einem Kalender-Reminder im Change-Management koppeln.

Microsoft Defender for Endpoint: Wenn der Mandant mit MDE verbunden ist (Tenant Admin → Connectors), kannst du zusätzlich ein Device Threat Level als Compliance-Kriterium definieren – etwa „Require device to be at or under the low risk score“. Damit fließt die Live-Bedrohungsbewertung von MDE direkt in die Zugriffskontrolle: Ein Gerät, das in diesem Moment einen aktiven Malware-Vorfall hat, wird sofort noncompliant – auch wenn alle statischen Checks bestanden sind.

Schritt 3: Assignment, Ringe und Filter

Die Baseline-Policy wird der Gruppe „All Devices“ zugewiesen – oder besser: einer dynamischen Entra-Device-Gruppe mit Filterkriterien wie deviceOwnership = Corporate. Ausnahmen (Testgeräte, VM-Farmen, kiosk-Systeme) gehören nicht in die Policy selbst, sondern in eine eigene, bewusst geschwächte Ausnahme-Policy und werden per Assignment-Filter ausgeschlossen:

# Assignment-Filter: virtuelle Maschinen ausschliessen
(device.model -in ["Virtual Machine", "VMware7,1", "Parallels Arm"]) -or
(device.model -startsWith "Virtual")

Warum Filter statt getrennte Policies überall: Filter sind revisionssicher und evaluierbar – sie werden auf Device-Eigenschaften geprüft, die du über den Graph jederzeit verifizieren kannst.

Schritt 4: Noncompliance-Aktionen konfigurieren

Im Policy-Blade unter „Actions for noncompliance“: Schedule für „Mark device noncompliant“ auf 3 Tage setzen (= Grace Period), dann „Send email“ bei Tag 1 und „Send push“ bei Tag 2 ergänzen. E-Mail-Vorlagen vorher unter „Tenant administration → Notifications“ anlegen – mit Firmenname, konkretem Hinweis und Helpdesk-Link, damit die Meldung nicht wie ein generischer System-Fehler wirkt, sondern wie eine Handlungsanweisung.

Schritt 5: Automatisierung via Microsoft Graph

Was im Portal Klickerei ist, ist über die Graph API reproduzierbar – entscheidend für Umgebungen mit Infrastructure-as-Code. Auslesen:

Connect-MgGraph -Scopes `
  "DeviceManagementConfiguration.ReadWrite.All", `
  "DeviceManagementManagedDevices.Read.All"

# Alle Compliance-Policies mit Zuweisungsstatus
Get-MgDeviceManagementDeviceCompliancePolicy -All | `
  Select-Object DisplayName, Id, LastModifiedDateTime | `
  Sort-Object DisplayName

Eine Baseline-Policy vollständig anlegen:

$policy = @{
  "@odata.type"                     = "microsoft.graph.windows10CompliancePolicy"
  displayName                       = "WIN - Compliance - Baseline - v1.0"
  description                       = "Definition eines gesunden Windows-Devices"
  passwordRequired                  = $true
  passwordBlockSimple               = $true
  passwordRequiredType              = "alphanumeric"
  passwordMinimumLength             = 12
  passwordExpirationDays            = 0
  passwordMinutesOfInactivityBeforeLock = 5
  secureBootEnabled                 = $true
  codeIntegrityEnabled              = $true
  bitLockerEnabled                  = $true
  activeFirewallRequired            = $true
  defenderEnabled                   = $true
  storageRequireEncryption          = $true
  osMinimumVersion                  = "10.0.22631"
} | ConvertTo-Json -Depth 8

$policyId = (Invoke-MgGraphRequest -Method POST `
  -Uri "https://graph.microsoft.com/v1.0/deviceManagement/deviceCompliancePolicies" `
  -Body $policy).id

# Grace Period: Markierung als noncompliant erst nach 72h
$actions = @{
  ruleName = "PasswordRequired"
  scheduledActionConfigurations = @(
    @{ actionType = "block"; gracePeriodHours = 72 }
  )
} | ConvertTo-Json -Depth 6

Invoke-MgGraphRequest -Method POST `
  -Uri "https://graph.microsoft.com/v1.0/deviceManagement/deviceCompliancePolicies/$policyId/scheduledActionsForRule" `
  -Body $actions

Und der operative Alltags-Check – welcher Bestand ist noncompliant:

Get-MgDeviceManagementManagedDevice -All `
  -Filter "complianceState eq 'noncompliant'" | `
  Select-Object DeviceName, OperatingSystem, OSVersion, `
    UserPrincipalName, LastSyncDateTime | `
  Sort-Object LastSyncDateTime

Reporting: Die drei entscheidenden Views

• Policy-Compliance-Report: Pro Policy der Prozentwert – dein KPI für Fleet-Gesundheit. Ziel im Betrieb: >95 % compliant, stabile Tendenz.
• Noncompliant Devices: Das Arbeitsinstrument für den Service Desk – inklusive Grund je Gerät.
• Devices without compliance policy: Dein Frühwarnsystem. Jedes Gerät in dieser Liste hat den Status „not evaluated“ – und blockiert damit bei aktiver CA-Einstellung automatisch. Liste regelmäßig auf null fahren.

Best Practices: Compliance als Architektur

• Report-Only vor Enforcement: Die erste Policy wird ohne Conditional-Access-Kopplung ausgerollt und 2–3 Wochen nur beobachtet. Danach erst die CA-Richtlinie scharfschalten. Sonst sperrt der erste Rollout dir die halbe Belegschaft aus – klassischer Selbst-DoS.
• Layered Policies statt Monolith: Eine Baseline für alle, darauf aufbauend geschärfte Policies für privilegierte Gruppen (Admins: TPM required, Code Integrity zwingend), plus eine bewusste VM-Ausnahme-Policy. Drei kleine Schichten statt einem Riesenwerk, das jede Änderung global ins Wanken bringt.
• Grace Period realistisch wählen: 24–72 Stunden. Zu kurz = Nutzer werden während der Arbeit ausgesperrt. Zu lang (Wochen) = du hast faktisch keine Kontrolle. 30 Tage Grace Period ist kein Sicherheitsmechanismus, es ist Alibi.
• Naming Convention durchziehen: „[PLattform] – Compliance – [Schicht] – v1.0“, etwa „WIN – Compliance – Baseline – v1.0“ oder „WIN – Compliance – Admins – v1.1“. Die Version im Namen macht Change-History im Portal lesbar.
• Defender-Settings nur wenn MDE auch die Realität ist: Third-Party-Endpoint-Schutz plus Defender-Compliance-Checks = Dauer-Noncompliance. Beide Welten sauber trennen.
• Plattformspezifische Ergänzungen nicht vergessen: iOS/iPadOS (Jailbreak-Erkennung, Mindest-OS, Root-Zertifikate), macOS (Gatekeeper, FileVault, System-Integritätsschutz), Android Enterprise (Play Integrity, Root-Erkennung, Verschlüsselung). Dieselbe Logik, andere Settings – aber auch hier: pro Plattform eine Baseline.
• Compliance-Drift als KPI monitoren: Der Bestand driftet – neue Hardware, alte Treiber, Feature-Updates. Wöchentlicher Blick auf den Compliance-Trend statt einmaliges Konfigurieren und vergessen.

Troubleshooting: Die sechs klassischen Fehlerbilder

1. „Compliance pending“ – die Evaluierung läuft nie ab

Das Gerät meldet sich, aber der Status bleibt leer. Fast immer ein Sync-Problem: In der Ereignisanzeige unter „Anwendungs- und Dienstprotokolle → Microsoft → Windows → DeviceManagement“ nach Fehlern der MDM-Agent-Synchronisierung suchen, danach manuellen Sync im Company Portal erzwingen. Zusätzlich prüfen, ob das Gerät überhaupt sauber in Entra eingebunden ist:

dsregcmd /status

Die Felder „AzureAdJoined: YES“ und „MDM-URL vorhanden“ müssen gesetzt sein. Fehlt letzteres, hat das Gerät nie eine funktionierende Enrollment – dann hilft kein Sync, sondern nur ein Re-Onboarding.

2. Secure Boot noncompliant trotz korrekter Hardware

Klassiker auf Virtualisierung: Hyper-V-Generation-1-VMs und alte BIOS-Geräte unterstützen kein UEFI Secure Boot und können die Anforderung prinzipiell nie erfüllen. Vor dem Rollout klären, wie viele Geräte betroffen wären:

Confirm-SecureBootUEFI   # $true = Secure Boot aktiv

Für VMs: entweder auf Generation 2 migrieren (Secure Boot dort aktivierbar) oder eine separate Ausnahme-Policy ohne Secure-Boot-Anforderung für die VM-Farm – dokumentiert, nicht heimlich.

3. BitLocker noncompliant, obwohl „irgendwie“ verschlüsselt

Die Compliance prüft den aktiven Schutz des Betriebssystem-Datenträgers. Typische Fallen: Die Verschlüsselung läuft noch (Stunden nach der Aktivierung), der Schutz wurde administrativ suspended, oder es handelt sich um ein Self-Encrypting-Drive, das Intune nicht als BitLocker erkennt. Direkt am Gerät verifizieren:

Get-BitLockerVolume -MountPoint $env:SystemDrive | `
  Select-Object VolumeStatus, ProtectionStatus, EncryptionPercentage

„ProtectionStatus: On“ ist der Wert, den Compliance sehen will. Steht „Off“, liegt der Fall beim Verschlüsselungs-Konfigurationsprofil (Sektion 14), nicht bei der Compliance-Policy.

4. Code Integrity noncompliant – HVCI blockt

HVCI (Memory Integrity) setzt Virtualization-Based Security voraus, und alte Kernel-Treiber blockieren sie. Check am Gerät:

Get-CimInstance -Namespace root\Microsoft\Windows\DeviceGuard `
  -ClassName Win32_DeviceGuard | `
  Select-Object VirtualizationBasedSecurityStatus, `
    SecurityServicesRunning

„SecurityServicesRunning“ muss eine 1 enthalten (HVCI läuft). Wenn nicht: Device Guard-Hardware-Bereitschaft prüfen und Treiber-Leichen ausmerzen – das ist eine Fleet-Aufgabe, keine Compliance-Aufgabe.

5. Firewall-Noncompliance bei Third-Party-Security-Tools

Manche Security-Suiten deaktivieren die Windows-Firewall-Dienste und ersetzen sie durch eigene Filter. Die Compliance-Policy sieht nur den Windows-Dienst – und schlägt dauerhaft Alarm. Entscheidung nötig: entweder Windows-Firewall als Pflicht beibehalten und Suite umkonfigurieren, oder das Setting aus der Baseline entfernen. Halbe Lösungen (Grace Period von 30 Tagen) verstecken nur das Problem.

Get-NetFirewallProfile | Select-Object Name, Enabled

6. Conditional Access sperrt mehr als der Compliance-Report zeigt

Wenn CA Geräte blockiert, die im Report „compliant“ sind: an Grace Period und Gültigkeitsdauer denken. Ein Gerät kann im Report noch „in grace period“ stehen, während eine zweite CA-Policy (z. B. für Admin-Zugriffe) bereits strengere Regeln ohne Grace interpretiert. Im Device-Blade unter „Geräte → Compliance“ den Detail-Status je Regel ansehen – dort steht pro Einstellung der exakte Prüfpunkt und Zeitstempel der letzten Evaluierung.

Fazit

Die Compliance-Policy ist die Antwort auf die einzige Frage, die Conditional Access nicht selbst beantworten kann: Ist diese Maschine in einem Zustand, dem Unternehmensdaten anvertraut werden können? Du hast jetzt das vollständige Werkzeug: die Zustandslogik (fünf States, 8-Stunden-Evaluationszyklus, DHA-gestützte Health-Checks), die Architektur (Baseline plus Schichten plus dokumentierte Ausnahmen), die Eskalationsmechanik (Grace Period, Aktionen, personalisierte Benachrichtigungen) und den operativen Unterbau (Graph-Automatisierung, Reporting, systematische Fehlersuche am Gerät selbst).

Der Reifeprozess ist immer derselbe: erst messen, dann melden, dann durchsetzen. Wer die Reihenfolge umdreht, baut kein Zero-Trust-Konstrukt, sondern einen denial-of-service-Angriff auf die eigene Belegschaft. Wenn im nächsten Schritt Conditional Access die Compliance-Ergebnisse in echte Zugriffskontrolle übersetzt, hast du das Fundament dafür bereits im engeren Sinne „vertraglich“ gemacht: Das Gerät weiß, was von ihm erwartet wird, Intune weiß, ob es liefert, und Entra ID weiß, was zu tun ist, wenn nicht.