# Eine Geräteanforderung einführen, ohne jemanden auszusperren
Typ: Checkliste
Herkunft: microsoft-entra-m365 / device-identity / microsoft-entra-device-rollout-sequence
Version: microsoft-entra-device-rollout-sequence-2026-09-12
Geprüft: 2026-09-12

ACHTUNG: Dieses Dokument ist ein Lernartefakt aus einer Schulungssequenz. Es ist kein produktives Runbook. Vor jeder Anwendung in einer realen Umgebung müssen die Schritte gegen lokale Dokumentation, Runbooks und Freigabestatus geprüft werden.

## Szenario
Der Zugriff auf ein Fachverfahren soll künftig ein konformes Gerät verlangen. Die Nutzergruppe ist gemischt: Windows-Notebooks, einige Macs, dazu vereinzelt Zugriffe vom Telefon. Der erste Entwurf besteht darin, die Regel einzuschalten und abzuwarten, wer sich meldet.

## Schritte
1. Die Steuerung nach den Plattformen der Nutzergruppe auswählen
2. Über `trustType` und `isCompliant` auszählen, wie viele Geräte die Bedingung heute erfüllen
3. Notfallzugangskonten von der Regel ausnehmen
4. Festlegen, was für Anmeldewege ohne Gerätezustand gelten soll
5. Die Regel im reinen Beobachtungsmodus einschalten und die Anmeldeprotokolle auswerten
6. Die verbliebenen Betroffenen versorgen und erst danach durchsetzen

## Begründung
Warum: Eine Regel, die auf einem Bestand wirkt, wird erst gemessen und dann scharf gestellt. Die Messung vorher kostet Tage, die Messung nachher kostet einen Arbeitstag der Betroffenen — und sie liefert dieselbe Erkenntnis.
Folgen: **+** Die Betroffenen sind bekannt, bevor die Regel sperrt, und die Ausnahmen sind bewusst gesetzt statt nachträglich erzwungen. **−** Die Einführung dauert Wochen, und der Beobachtungsmodus schützt in dieser Zeit nichts; wer eine akute Bedrohung abwehren muss, kann sich diese Reihenfolge nicht leisten.

## Quellen
1. https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-conditional-access-grant
2. https://learn.microsoft.com/en-us/graph/api/resources/device
3. https://learn.microsoft.com/en-us/entra/identity/users/directory-emergency-access