← Microsoft Entra ID & Microsoft 365 Administration

Geräteidentität als Zugriffssignal

Die Zugriffsregel verlangt ein verwaltetes Gerät, alle Notebooks sind verwaltet — und am Montagmorgen kann ein Drittel der Abteilung nicht arbeiten, weil die gewählte Steuerung ausschließlich domänenbeigetretene Windows-Geräte kennt und die Macs sie strukturell nicht erfüllen können. Dieses Modul behandelt die Identitätsseite des Geräts: welche drei Zustände es gibt, warum die Konformitätsangabe eine Behauptung mit Ablaufdatum ist statt einer Messung, und bei welchem Anmeldeweg der Gerätezustand gar nicht erst ankommt. Aufnahme und Richtlinienpflege stehen im Track endpoint-management.

Lehrtext · 12 Abschnitte · zuletzt geprüft: 2026-09-12

Ein Gerät ist im Verzeichnis ein Objekt wie jedes andere

Benutzer, Gruppen und Anwendungen kennst du aus den ersten Modulen. Geräte sind die vierte Objektart, und sie sind die einzige, die etwas über die Umgebung einer Anmeldung aussagt. Genau deshalb sind sie als Signal für Zugriffsentscheidungen so attraktiv — und genau deshalb lohnt es, genau zu wissen, was das Signal trägt.

Geräteidentität — Ein Objekt in Microsoft Entra ID, das ein konkretes Gerät vertritt. Es entsteht bei der Registrierung, trägt eine vom Registrierungsdienst vergebene deviceId und kann in Zugriffsregeln ausgewertet werden.

Die deviceId ist ein eigener Schlüssel neben der Objekt-ID und der stabile Bezug, wenn man ein Gerät über Systemgrenzen hinweg wiederfinden will. Sie wird bei der Registrierung vergeben und ändert sich nicht, solange die Registrierung besteht.

LernzielDu kannst die drei Gerätezustände am Attribut trustType unterscheiden, benennen wer isCompliant setzt, und begründen, in welchen Fällen eine gerätebasierte Zugriffsregel nicht greift.

Registrierung ist nicht Verwaltung

Die wichtigste Abgrenzung dieses Moduls steht so in der Dokumentation: Die Registrierung in Microsoft Entra ist nicht dasselbe wie die Geräteregistrierung in einer Verwaltungslösung. Es sind zwei Vorgänge mit zwei Zwecken, und sie werden ständig verwechselt.

Registrierung in Entra ID: Das Gerät bekommt eine Identität. Danach ist es als Objekt bekannt und kann in Zugriffsregeln vorkommen.
Aufnahme in die Geräteverwaltung: Das Gerät bekommt Vorgaben — Verschlüsselung, Kennwortkomplexität, aktuelle Schutzsoftware. Das erledigt eine Verwaltungslösung wie Microsoft Intune.

Beides kann zusammenfallen, muss aber nicht. Ein Gerät kann registriert und unverwaltet sein; es hat dann eine Identität, über die keine Vorgabe durchgesetzt wird. Die Reihenfolge ist dabei festgelegt: Ein Gerät muss laut Dokumentation in Entra ID registriert sein, bevor es als konform gekennzeichnet werden kann.

Wo dieses Modul aufhörtWie Geräte aufgenommen, mit Richtlinien versorgt und im Bestand gehalten werden, steht im Track endpoint-management. Hier geht es ausschließlich um die Identitätsseite: welches Objekt entsteht, was es behauptet und wie eine Zugriffsentscheidung darauf zugreift.

Drei Zustände, ein Attribut

Für den Betrieb genügt es, die drei Zustände am Attribut trustType auseinanderzuhalten. Es ist schreibgeschützt und hat genau drei dokumentierte Werte.

Workplace: In Entra registriert — der Fall für private Geräte. Die Anmeldung am Gerät selbst erfolgt mit einem lokalen Konto, das Organisationskonto kommt erst beim Zugriff auf Ressourcen ins Spiel.
AzureAd: In Entra eingebunden — reine Cloud-Bindung. Das Organisationskonto ist die Anmeldung am Gerät.
ServerAd: Hybrid eingebunden — das Gerät ist einer lokalen Domäne beigetreten und zusätzlich in Entra ID bekannt.

Die Dokumentation bezeichnet die hybride Einbindung ausdrücklich als Zwischenschritt auf dem Weg zur reinen Entra-Einbindung. Alle drei Formen dürfen in einer Organisation nebeneinander bestehen — was sie in der Praxis auch tun, weshalb eine Regel, die nur einen Zustand kennt, regelmäßig jemanden aussperrt.

Der Unterschied, den Anwender merkenBei Workplace bleibt das Gerät der Person. Bei AzureAd und ServerAd meldet man sich mit dem Organisationskonto am Gerät selbst an. Das ist keine technische Feinheit, sondern die Grenze zwischen „mein Gerät, an dem ich arbeite“ und „ein Arbeitsgerät“ — und sie bestimmt, was man einer Person überhaupt zumuten darf.

Der Primary Refresh Token: was das Gerät zur Anmeldung beiträgt

Damit ein Gerätezustand bei einer Anmeldung überhaupt ankommt, braucht es einen Träger. Das ist der Primary Refresh Token, kurz PRT — laut Dokumentation ein zentrales Artefakt der Anmeldung unter Windows, iOS, macOS, Android und Linux.

Primary Refresh Token — Ein besonders ausgestelltes Artefakt für die Token-Vermittler des Herstellers. Es ermöglicht einmalige Anmeldung über die Anwendungen eines Geräts hinweg und trägt Geräte- und Benutzeransprüche, die Entra ID bei Zugriffsregeln auswertet.

Zwei Eigenschaften sind für den Betrieb wichtig. Erstens ist der PRT ein undurchsichtiges Datenpaket: Sein Inhalt ist keinem Client bekannt, man kann nicht hineinsehen. Wer bei der Fehlersuche hofft, im Token nachzulesen, warum eine Regel greift, sucht an der falschen Stelle — die Antwort steht in den Anmeldeprotokollen, nicht im Artefakt.

Zweitens gibt es ihn in zwei Ausführungen: für registrierte Geräte, die an eine Entra-Identität gebunden sind, und für nicht registrierte Geräte, die an ein auf dem Gerät erzeugtes Schlüsselpaar gebunden sind. Clients versuchen laut Dokumentation immer zuerst die erste Variante. Entscheidend ist der Nachsatz: Nur PRTs für registrierte Geräte erfüllen Richtlinien, die eine Geräteregistrierung verlangen.

Warum der zweite Fall existiertEr deckt die Wirklichkeit ab — jemand meldet sich im Browser auf einem privaten Gerät an, oder eine Anwendung unterstützt Geräteregistrierung gar nicht. Es gibt also regulär Anmeldungen ohne verwertbaren Gerätezustand, und eine Regel muss entscheiden, wie sie damit umgeht.

`isCompliant` ist eine Behauptung, keine Messung

Hier liegt der Befund, den man aus diesem Modul mitnehmen sollte. Das Attribut isCompliant sagt, ob ein Gerät den Vorgaben der Geräteverwaltung entspricht. Es ist schreibgeschützt — und laut Dokumentation kann es nur von Intune gesetzt werden, für Windows-Geräte alternativ von einer zugelassenen Verwaltungsanwendung.

Das heißt: Entra ID misst nichts. Es liest einen Wert, den ein anderes System hineingeschrieben hat, und dieser Wert stammt aus dem letzten Kontakt zwischen Gerät und Verwaltung. Zwischen dem Zeitpunkt der Bewertung und dem Zeitpunkt der Zugriffsentscheidung liegt Zeit, in der sich am Gerät alles Mögliche geändert haben kann.

isManaged: Das Gerät wird von einer Verwaltungslösung verwaltet. Sagt nichts über die Einhaltung von Vorgaben.
isCompliant: Das Gerät entsprach bei der letzten Bewertung den Vorgaben.
complianceExpirationDateTime: Zeitpunkt, an dem diese Aussage ihre Gültigkeit verliert.
accountEnabled: Ob das Geräteobjekt aktiv ist. Setzen darf das laut Dokumentation nur, wer mindestens die Rolle Cloud Device Administrator hat.

Der ehrliche Satz dazuEine Konformitätsprüfung ist eine Momentaufnahme mit Verfallsdatum, kein Livesignal. Sie ist trotzdem eines der besten verfügbaren Signale — man darf ihr nur nicht mehr zutrauen, als sie behauptet.

Die Unterscheidung zwischen isManaged und isCompliant ist dabei die, die im Alltag am häufigsten untergeht. Ein Gerät kann verwaltet und nicht konform sein — das ist sogar der Normalfall, sobald eine Vorgabe verschärft wird und der Bestand nachzieht. Umgekehrt sagt ein fehlendes isManaged, dass niemand Vorgaben durchsetzt; dann ist isCompliant gar nicht erst zu erwarten. Wer bei der Fehlersuche nur auf die Konformität schaut, verwechselt regelmäßig „hat die Prüfung nicht bestanden“ mit „wird von niemandem geprüft“.

Praktisch heißt das für jede Auswertung: beide Felder zusammen lesen. Die Kombination aus isManaged false und einer Zugriffsregel, die Konformität verlangt, ist kein Sicherheitsbefund über das Gerät, sondern ein Befund über die Geräteverwaltung — und sie gehört an ein anderes Team.

Die zwei Gerätesteuerungen in Zugriffsregeln

In einer Zugriffsregel gibt es zwei Steuerungen, die auf das Gerät zeigen. Sie sehen ähnlich aus und haben verschiedene Voraussetzungen.

Require device to be marked as compliant: Verlangt die von der Verwaltung gesetzte Konformität. Unterstützt Windows 10 und neuer, iOS, Android, macOS und Linux Ubuntu — jeweils in Entra registriert und in Intune aufgenommen.
Require Microsoft Entra hybrid joined device: Verlangt die hybride Einbindung. Unterstützt ausschließlich domänenbeigetretene Windows-Geräte, auch ältere vor Windows 10.

Die Plattformgrenze der zweiten Steuerung ist der häufigste Entwurfsfehler. Wer sie auf eine Gruppe anwendet, in der Menschen mit macOS, iOS oder Android arbeiten, hat für diese Menschen keine strengere Regel gebaut, sondern eine Sperre — ihr Gerät kann die Bedingung nicht erfüllen, unabhängig davon, wie gut es verwaltet ist.

Eine Kleinigkeit mit großer WirkungMicrosoft Edge im privaten Modus gilt unter Windows ausdrücklich weder als konformes noch als hybrid eingebundenes Gerät. Ein Anwender, der ein privates Fenster öffnet, um „kurz etwas anderes auszuprobieren“, verliert damit sein Gerätesignal — und meldet einen Fehler.

Wo das Gerätesignal gar nicht ankommt

Es gibt einen dokumentierten Fall, in dem eine gerätebasierte Regel nicht greifen kann, und den sollte man kennen, bevor man sich auf sie verlässt.

Beim Anmeldeverfahren über einen Gerätecode — jenem Ablauf, bei dem ein Gerät ohne Tastatur einen Code anzeigt, den man an einem zweiten Gerät eingibt — wird die Anforderung eines verwalteten Geräts und die Bedingung auf den Gerätezustand laut Dokumentation nicht unterstützt. Der Grund ist strukturell: Das Gerät, das die Anmeldung durchführt, kann seinen Zustand nicht an das Gerät übermitteln, das den Code anzeigt, und der Gerätezustand im Token gehört dem anmeldenden Gerät.

Die Dokumentation nennt auch den Ausweg: In diesem Fall auf die Anforderung einer mehrstufigen Authentifizierung ausweichen. Das ist eine andere Zusicherung — sie sagt etwas über die Person, nicht über die Umgebung — aber sie ist verfügbar, während die Geräteanforderung es nicht ist.

Der allgemeine SchlussJede Bedingung, die auf einem Signal beruht, braucht eine Antwort auf die Frage, was gilt, wenn das Signal fehlt. Wer das offenlässt, hat nicht entschieden, sondern die Entscheidung dem Zufall des Anmeldewegs überlassen.

Was das Gerät belegt — und was nicht

Damit lässt sich präzise sagen, welche Aussage ein Gerätesignal trägt.

Belegt: Dieses Gerät ist als Objekt bekannt und hat eine Registrierung, die zum Zeitpunkt der Anmeldung gültig war.
Belegt: Die Verwaltungslösung hat es bei ihrer letzten Bewertung als den Vorgaben entsprechend gekennzeichnet.
Nicht belegt: Dass es in diesem Augenblick den Vorgaben entspricht.
Nicht belegt: Dass die Person, die es benutzt, die berechtigte ist — das ist die Aufgabe der Anmeldeverfahren aus dem vorigen Modul.
Nicht belegt: Dass das Gerät frei von Schadsoftware ist. Vorgaben prüfen Einstellungen, nicht Zustände.

Daraus folgt die richtige Rolle des Signals: Es ist ein zusätzlicher Faktor in einer Entscheidung, kein Ersatz für die anderen. Eine Regel, die ein konformes Gerät verlangt und dafür auf die Prüfung der Person verzichtet, hat einen starken Faktor gegen einen mittleren getauscht.

Das ist keine theoretische Sorge, sondern eine wiederkehrende Entwurfsentscheidung. Die Versuchung ist groß, Beschäftigten auf verwalteten Geräten die zusätzliche Bestätigung zu ersparen — sie sitzen ja am Firmennotebook. Das Gerät belegt aber nur, dass der Zugriff von diesem Blech kommt, nicht wer davorsitzt. Wer den Faktor streicht, hat für den Fall des entwendeten, angemeldeten Notebooks keine Antwort mehr.

Die brauchbare KombinationGerätesignal und Personenprüfung ergänzen sich, weil sie Verschiedenes belegen: das eine die Umgebung, das andere die Person. Sinnvoll ist deshalb, das Gerätesignal zu nutzen, um die Häufigkeit der Nachfrage zu senken — nicht, um sie abzuschaffen.

Veraltete Geräteobjekte

Geräteobjekte verschwinden nicht, wenn ein Gerät verschrottet wird. Sie bleiben stehen, und mit ihnen ihre Registrierung. Über die Zeit sammelt jeder Tenant Objekte an, die kein Gerät mehr vertreten.

Der Anhaltspunkt dafür ist approximateLastSignInDateTime. Der Name ist ernst zu nehmen: Der Wert ist ausdrücklich als ungefähr bezeichnet und schreibgeschützt. Er taugt gut, um Objekte zu finden, die seit Monaten nichts getan haben — und nicht dafür, auf den Tag genau zu argumentieren.

Warum das mehr ist als OrdnungsliebeJedes überflüssige Geräteobjekt ist eine gültige Registrierung. Solange sie besteht, kann sie in einer Regel als bekanntes Gerät zählen. Aufräumen ist hier deshalb keine Kosmetik, sondern das Schließen von Zugängen, an die niemand mehr denkt.

Der Weg dorthin führt über zwei Schritte statt einem, und die Reihenfolge lohnt sich. Zuerst wird das Objekt über accountEnabled deaktiviert und eine Weile beobachtet — meldet sich niemand, war die Annahme richtig. Erst danach wird gelöscht. Wer sofort löscht, nimmt einer Person im Zweifel das Arbeitsgerät und muss die Registrierung neu aufbauen, was auf einem Gerät im Außendienst unangenehm werden kann.

Der Preis dieses Vorgehens ist, dass der Bestand länger unaufgeräumt bleibt und jemand die Beobachtungsphase nachhalten muss. Ohne diese Nachverfolgung entsteht die schlechteste aller Varianten: ein Berg deaktivierter Objekte, den niemand mehr zu löschen traut, weil unklar ist, welche davon noch gebraucht werden.

Durchgerechnet: eine Geräteanforderung einführen

Konforme Geräte für eine Fachanwendung

Szenario

Der Zugriff auf eine Fachanwendung soll künftig ein konformes Gerät verlangen. Die Nutzergruppe umfasst 300 Personen: überwiegend Windows-Notebooks, dazu etwa 40 macOS-Geräte und eine Handvoll Menschen, die die Anwendung gelegentlich vom Telefon aus öffnen.

Anforderungen

Niemand soll durch die Einführung unangekündigt ausgesperrt werden.
Am Ende gilt die Anforderung für die ganze Gruppe.
Der Weg soll auch beantworten, was bei fehlendem Gerätesignal gilt.

Schritte

Steuerung wählen: Require device to be marked as compliant, nicht die hybride Variante — sonst fallen die macOS- und Telefonnutzer heraus, weil ihre Plattform die Bedingung nicht erfüllen kann.
Voraussetzung prüfen: Alle betroffenen Geräte müssen in Entra registriert und in Intune aufgenommen sein. Ohne beides gibt es kein isCompliant, das gesetzt werden könnte.
Bestand messen: Über trustType und isCompliant auszählen, wie viele Geräte die Bedingung heute erfüllen würden — vor der Regel, nicht danach.
Ausnahmen benennen: Notfallzugangskonten aus dem ersten Modul ausschließen, und für Anmeldewege ohne Gerätesignal — etwa den Gerätecode — die Anforderung einer mehrstufigen Authentifizierung als Ersatz festlegen.
Erst beobachtend einschalten und die Betroffenen anhand der Anmeldeprotokolle finden, dann durchsetzen.

Merksatz: Die Reihenfolge dreht die übliche um: Erst messen, wen die Regel treffen würde, dann die Regel scharf stellen. Wer zuerst durchsetzt, misst am Servicedesk.

Der Preis dieser Sorgfalt ist Zeit — die Einführung dauert Wochen statt Minuten, und die Bestandsmessung ist Arbeit, die im Ergebnis niemand sieht. Dafür entfällt der Vorfall, bei dem 40 Menschen an einem Montagmorgen nicht arbeiten können und niemand sofort weiß, warum.

Wer Geräteobjekte ändern darf

Geräteobjekte sind größtenteils schreibgeschützt, und das ist Absicht: Ihre Aussagekraft hängt daran, dass sie nicht von Hand gesetzt werden können. trustType, isCompliant und approximateLastSignInDateTime sind für Verwaltende nicht änderbar — isCompliant und isManaged schreibt ausschließlich die Verwaltungslösung.

Was bleibt, ist im Wesentlichen das Aktivieren und Deaktivieren des Objekts über accountEnabled, und auch das ist an eine Rolle gebunden: Mindestens Cloud Device Administrator muss es sein. Das ist die richtige Stelle, um ein verlorenes Gerät aus dem Verkehr zu ziehen, ohne gleich das Objekt zu löschen.

Der Zusammenhang mit dem ersten ModulAuch hier gilt die kleinste passende Rolle: Wer Geräte sperren können soll, braucht Cloud Device Administrator — nicht Global Administrator. Die Rolle ist genau für diesen Zuschnitt vorhanden.

Die Reihenfolge, die alles zusammenhält

Zustand am trustType bestimmen, nicht am Bauchgefühl→Prüfen, ob Registrierung und Aufnahme in die Verwaltung vorliegen→Steuerung nach der Plattform der Betroffenen wählen→Festlegen, was bei fehlendem Gerätesignal gilt→Beobachtend einschalten, Betroffene finden, dann durchsetzen

Erst messen, dann durchsetzen

Das Gerätesignal ist eines der nützlichsten in Entra ID, weil es etwas über die Umgebung sagt, das keine Anmeldung über die Person hergibt. Es ist zugleich das Signal, dessen Grenzen am häufigsten übersehen werden — weil ein grünes Häkchen im Portal so aussieht, als wäre es gerade eben geprüft worden.

Gleich im CheckDie Übungen prüfen die Zuordnung der Gerätezustände, die Herkunft der Konformitätsangabe, die Plattformgrenzen der beiden Steuerungen und den Umgang mit Anmeldewegen, bei denen kein Gerätezustand ankommt.

Jetzt anwenden

Diesen Stoff gibt es als Modul mit bewerteten Entscheidungs-Checks — dieselbe Einführung, danach die Übungen.

Zum Modul →

Quellen & Aktualität6 Primärquellen · zuletzt geprüft: 2026-09-12