← Microsoft Entra ID & Microsoft 365 Administration

Risikosignale und Identitätsschutz

Die Regel gegen atypische Reisen ist scharf geschaltet, und trotzdem war die Person längst drin, als die Meldung kam. Kein Fehler — die Erkennung arbeitet nachträglich und kann die Anmeldung, die sie beschreibt, gar nicht verhindern. Dieses Modul trennt, was der Identitätsschutz abwehren kann von dem, was er nur aufklärt: die beiden Risikoarten und ihre Gegenmaßnahmen, den Unterschied zwischen Echtzeit und Nachlauf, und warum ein unbedachter Klick auf „sicher“ dem System beibringt, denselben Angriff künftig zu übersehen.

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

Zwei Risikoarten, die man nicht verwechseln darf

Der Identitätsschutz bewertet nicht „Sicherheit“ im Allgemeinen, sondern zwei genau umrissene Wahrscheinlichkeiten. Die Dokumentation formuliert sie knapp, und der Unterschied trägt das ganze Modul.

Benutzerrisiko: Die Wahrscheinlichkeit, dass eine Identität kompromittiert ist. Es haftet an der Person und bleibt bestehen, bis es behoben wird.
Anmelderisiko: Die Wahrscheinlichkeit, dass eine einzelne Anmeldung nicht von der berechtigten Person stammt. Es gilt für diesen einen Vorgang.

Aus dem Unterschied folgt die passende Reaktion. Ein erhöhtes Anmelderisiko fragt: Ist dieser Zugriff in Ordnung? Darauf antwortet eine zusätzliche Prüfung der Person. Ein erhöhtes Benutzerrisiko fragt: Ist dieses Konto noch in der richtigen Hand? Darauf antwortet nur ein Wechsel des Anmeldegeheimnisses.

LernzielDu kannst die beiden Risikoarten der passenden Gegenmaßnahme zuordnen, Echtzeit- von nachträglichen Erkennungen unterscheiden und die vier Rückmeldungen an den Identitätsschutz gezielt einsetzen.

Woher die Bewertung kommt — und was ohne Lizenz übrig bleibt

Die Erkennungen speisen sich laut Dokumentation aus drei Quellen: Heuristiken, maschinellem Lernen und Produkten von Partnern. Für den Betrieb heißt das, dass eine Bewertung eine Wahrscheinlichkeitsaussage ist und keine Feststellung — sie kann richtig sein und trotzdem einen harmlosen Vorgang beschreiben.

Die Lizenzgrenze ist an dieser Stelle ungewöhnlich spürbar. Vollständige Angaben zu den meisten Erkennungen setzen Microsoft Entra ID P2 voraus. Ohne P2 erscheinen sie als „Additional risk detected“ — ohne Einzelheiten. Man erfährt also, dass etwas war, aber nicht was.

Was das für die Untersuchung bedeutetOhne P2 lässt sich ein Vorfall nicht am Befund aufklären, sondern nur an den Anmeldeprotokollen. Das ist möglich, aber deutlich langsamer — und es ist der eigentliche Unterschied, den die Lizenz macht: nicht mehr Schutz, sondern mehr Sichtbarkeit.

Echtzeit oder nachträglich — der Unterschied, der alles entscheidet

Jede Erkennung ist entweder eine Echtzeit-Erkennung oder eine nachträgliche. Diese Eigenschaft steht in der Dokumentation bei jeder einzelnen Erkennung, und sie wird im Betrieb regelmäßig übersehen.

Eine Echtzeit-Erkennung liegt vor, während die Anmeldung läuft. Eine risikobasierte Regel kann sie auswerten und den Zugriff verweigern oder eine zusätzliche Prüfung verlangen. Eine nachträgliche Erkennung entsteht erst danach — sie beschreibt eine Anmeldung, die bereits stattgefunden hat.

Die Folge, die man aussprechen mussEine nachträgliche Erkennung kann die Anmeldung, die sie beschreibt, nicht verhindern. Sie wirkt erst auf künftige Anmeldungen, weil sie das Benutzerrisiko erhöht. Wer eine Regel gegen atypische Reisen baut und erwartet, dass sie den Zugriff im Moment des Ereignisses stoppt, hat die Wirkung falsch eingeschätzt — die Person war längst drin.

Daraus folgt die Arbeitsteilung: Echtzeit-Erkennungen tragen die Abwehr, nachträgliche tragen die Aufklärung und die Erhöhung des Benutzerrisikos. Beides ist nützlich, aber nur das eine verhindert etwas.

Erkennungen beim Namen nennen

Für die Untersuchung lohnt es, die Erkennungen bei ihrem technischen Namen zu kennen — er erscheint als riskEventType in Abfragen über Microsoft Graph und ist der stabile Bezug, wenn Berichte über Werkzeuggrenzen wandern.

anonymizedIPAddress: Anonyme IP-Adresse. Echtzeit, auch ohne P2 verfügbar.
unlikelyTravel: Atypische Reise. Nachträglich — die Anmeldung ist bereits geschehen.
anomalousToken: Auffälliges Token. In Echtzeit oder nachträglich, P2.
authenticatorPhishing: Verdächtige Bestätigung einer mehrstufigen Anmeldung. Echtzeit, P2.
riskyIPAddress: Auffällige IP-Adresse. Nachträglich, P2.
adminConfirmedUserCompromised: Verwaltend bestätigte Kompromittierung. Nachträglich, auch ohne P2.
generic: Der Sammelbefund ohne Einzelheiten — das, was ohne P2 übrig bleibt.

Bemerkenswert an dieser Liste ist, wie viele der aussagekräftigen Erkennungen nachträglich arbeiten. Wer seinen Schutz ausschließlich auf risikobasierte Sperren stützt, verlässt sich auf die kleinere Hälfte.

Auch die Lizenzspalte lohnt einen Blick. anonymizedIPAddress und adminConfirmedUserCompromised stehen ohne P2 zur Verfügung, die meisten anderen nicht. Eine Organisation ohne P2 hat also durchaus Erkennungen — sie sieht nur bei den interessanten Fällen generic statt eines Namens. Für die Planung heißt das: Die Frage ist nicht, ob überhaupt erkannt wird, sondern ob sich ein Befund ohne zusätzliche Recherche zuordnen lässt.

Warum der technische Name zähltIm Portal stehen übersetzte Bezeichnungen, in Graph-Abfragen und in Exportdateien der riskEventType. Wer einen Bericht über Werkzeuggrenzen hinweg verfolgt — Portal, Abfrage, Auswertung in einem anderen System — braucht den technischen Namen als gemeinsamen Bezug. Übersetzte Anzeigenamen ändern sich, riskEventType nicht.

Risikostufen sind Wahrscheinlichkeiten, keine Schweregrade

Jede Erkennung trägt eine Stufe — niedrig, mittel oder hoch. Der verbreitete Denkfehler ist, sie als Schadensausmaß zu lesen. Sie beschreibt die Zuversicht des Systems, dass etwas nicht stimmt, nicht die Folgen, wenn es stimmt.

Risikostufe — Ein Maß für die Sicherheit der Bewertung, nicht für ihre Tragweite. Eine Erkennung mit niedriger Stufe an einem hochprivilegierten Konto kann dringender sein als eine hohe Stufe an einem Konto ohne besondere Rechte.

Praktisch heißt das: Die Stufe gehört mit dem Wert des betroffenen Kontos verrechnet, bevor jemand reagiert. Eine Warteschlange, die streng nach Stufe sortiert ist, bearbeitet zuverlässig die falschen Fälle zuerst.

Ein einfaches Vorgehen genügt dafür. Zuerst wird gefragt, was das Konto darf — trägt es eine privilegierte Rolle aus dem ersten Modul, ist jeder Befund vorrangig, unabhängig von der Stufe. Erst danach entscheidet die Stufe die Reihenfolge innerhalb derselben Klasse. Das ist keine ausgefeilte Bewertung, aber es verhindert den häufigsten Fehler: dass ein niedriger Befund an einem Administratorkonto hinter zwanzig hohen Befunden an gewöhnlichen Konten wartet.

Woher die Stufen kommenSie stammen aus derselben Mischung wie die Erkennungen selbst — Heuristiken, maschinelles Lernen und Partnerprodukte. Damit sind sie zwar vergleichbar, aber nicht kalibriert auf die eigene Umgebung. Eine Organisation mit viel Außendienst wird bei ortsbezogenen Erkennungen dauerhaft mehr Befunde sehen als eine mit festen Arbeitsplätzen, ohne dass sie unsicherer wäre.

Risikobasierte Regeln und die Selbstheilung

Der Identitätsschutz greift über Zugriffsregeln in die Anmeldung ein — dieselbe Mechanik wie im Modul zu Conditional Access, nur mit dem Risiko als Bedingung. Zwei Regeln sind der Regelfall, und sie folgen genau der Unterscheidung aus dem ersten Abschnitt.

Regel auf das Anmelderisiko: Bei erhöhtem Risiko eine zusätzliche Prüfung der Person verlangen. Gelingt sie, ist der Vorgang bereinigt.
Regel auf das Benutzerrisiko: Bei erhöhtem Risiko einen sicheren Kennwortwechsel verlangen. Danach gilt das Konto als bereinigt.

Das Muster dahinter heißt Selbstheilung: Die betroffene Person behebt den Zustand selbst, ohne dass jemand eingreifen muss. Das ist der eigentliche Gewinn — nicht die Erkennung, sondern dass die häufigen Fälle ohne Ticket auskommen.

Der Preis der SelbstheilungSie verlangt, dass die Person überhaupt in der Lage ist, sich zu bestätigen oder das Kennwort zu wechseln. Wer kein registriertes Verfahren hat — der Fall aus dem Modul zu den Anmeldeverfahren — kann sich nicht selbst befreien und landet doch im Servicedesk. Eine Risikoregel ohne vorherige Registrierung erzeugt genau die Last, die sie vermeiden sollte.

Für die Regeln selbst gilt alles, was im Modul zu Conditional Access stand: Sie werden nach der ersten Anmeldestufe ausgewertet, alle zutreffenden Regeln müssen erfüllt sein, und die Notfallzugangskonten gehören in die Ausschlussliste. Der Berichtsmodus gilt hier ebenso — und er ist bei Risikoregeln besonders angebracht, weil sich der Umfang vorher schlecht schätzen lässt: Wie viele Personen im Monat ein erhöhtes Risiko auslösen, weiß niemand, bevor er es gemessen hat.

Zu beachten ist die Lizenzgrenze auch hier. Risikobasierte Regeln greifen auf den Identitätsschutz zu und setzen damit Microsoft Entra ID P2 voraus — anders als gewöhnliche Zugriffsregeln, für die P1 genügt.

Die vier Rückmeldungen und ihr feiner Unterschied

An einem bewerteten Vorgang lassen sich vier Rückmeldungen geben. Zwei davon werden ständig verwechselt, obwohl die Dokumentation sie sauber trennt.

Anmeldung als kompromittiert bestätigen — der Verdacht war richtig und bösartig.
Anmeldung als sicher bestätigen — ein Fehlalarm. Ähnliche Anmeldungen sollen künftig nicht mehr als riskant gelten.
Anmelderisiko verwerfen — ein zutreffender, aber harmloser Befund: ein bekannter Sicherheitstest, eine genehmigte Anwendung. Ähnliche Anmeldungen sollen weiterhin bewertet werden.
Benutzer sperren — verhindert die Anmeldung, wenn ein Angreifer das Kennwort hat oder die zusätzliche Prüfung bestehen kann.

Der Unterschied zwischen den mittleren beiden ist der wichtigste Satz dieses Abschnitts. „Sicher“ sagt: Das war nie ein Risiko, hör auf, so etwas zu melden. „Verwerfen“ sagt: Das war ein echtes Risiko, diesmal harmlos, melde es weiter. Wer jeden Fehlalarm als „sicher“ abhakt, trainiert dem System genau die Blindheit an, die später fehlt.

Zwei weitere Aktionen auf BenutzerebeneEin Kennwortwechsel durch Verwaltende beendet zugleich die laufenden Sitzungen der Person. Und das Verwerfen des Benutzerrisikos entspricht dem Verwerfen auf Anmeldeebene: Der Befund war echt, aber nicht bösartig.

Was eine Rückmeldung tatsächlich bewirkt

Rückmeldungen sind nicht nur Buchhaltung. Bestätigt jemand eine Anmeldung als kompromittiert, erhöht der Dienst laut Dokumentation sofort das Benutzerrisiko und das aggregierte Anmelderisiko auf hoch.

Eine Feinheit steht ausdrücklich dabei: erhöht wird das aggregierte Risiko, nicht das Echtzeitrisiko. Die Bestätigung wirkt also auf die Gesamtbewertung der Identität, nicht rückwirkend auf die Bewertung im Moment jener Anmeldung — was auch gar nicht möglich wäre.

Der praktische Nutzen ist eine Kette: Ist die Person von einer Regel auf hohes Benutzerrisiko erfasst, wird sie bei der nächsten Anmeldung zum sicheren Kennwortwechsel geführt und behebt den Zustand selbst. Aus einer verwaltenden Bestätigung wird so automatisch eine Bereinigung, ohne dass jemand ein Kennwort zurücksetzt.

Warum Rückmeldung überhaupt lohntDie Dokumentation nennt den Zweck offen: Die Rückmeldungen helfen, Erkennungen künftig zu verbessern, ihre Genauigkeit zu erhöhen und Fehlalarme zu senken. Wer sie unterlässt, behält dauerhaft die Fehlalarmquote, über die er sich beschwert.

Fehlalarme kosten, und die Dokumentation sagt es selbst

Ein Erkennungssystem ohne Fehlalarme gibt es nicht. Bemerkenswert ist, dass die Dokumentation an einer Stelle ausdrücklich davor warnt: Die Erkennung auffälliger Token war historisch geräuschintensiver als andere; die Genauigkeit wurde verbessert, aber es besteht weiterhin eine höhere als normale Wahrscheinlichkeit, dass Sitzungen bei niedriger und mittlerer Stufe Fehlalarme sind.

Das ist ein Geschenk für die Planung. Wer weiß, welche Erkennung bei welcher Stufe unzuverlässig ist, kann seine Regeln danach zuschneiden — etwa erst ab hoher Stufe sperren und bei niedriger und mittlerer lediglich eine zusätzliche Prüfung verlangen.

Die Kosten der falschen EinstellungEine zu scharfe Regel erzeugt Unterbrechungen bei Menschen, die nichts getan haben. Nach der dritten grundlosen Sperre lernt eine Organisation nicht, vorsichtiger zu sein, sondern die Meldungen zu ignorieren — und dann fehlt die Aufmerksamkeit beim echten Fall. Fehlalarme sind kein Schönheitsfehler, sie verbrauchen das knappste Gut im Betrieb.

Die abgestufte Antwort löst das meiste davon. Bei niedriger und mittlerer Stufe eine zusätzliche Prüfung der Person verlangen, bei hoher Stufe den Kennwortwechsel erzwingen — dann kostet ein Fehlalarm eine Bestätigung und nicht einen Arbeitstag. Der Unterschied zwischen beiden Reaktionen ist für die Betroffenen enorm, für die Sicherheitslage aber gering, weil beide den Fall bereinigen.

Wichtig dabei: Eine zusätzliche Prüfung wirkt nur, wenn der Nachweis nicht weiterleitbar ist. Wer bei erhöhtem Risiko eine Bestätigung per Benachrichtigung verlangt, prüft ausgerechnet in dem Moment mit einem Verfahren nach, das sich erschleichen lässt — genau der Fall aus dem Modul zu den Anmeldeverfahren. Bei Risikoregeln lohnt es deshalb besonders, eine phishing-resistente Anmeldestärke zu fordern statt nur „mehrstufig“.

Was das Risiko nicht weiß

Zum ehrlichen Bild gehört, wo die Bewertung nichts sagen kann.

Sie kennt den Wert des betroffenen Kontos nicht. Ein hochprivilegiertes Konto und ein Praktikantenkonto bekommen dieselbe Stufe für dasselbe Verhalten.
Sie kennt den Anlass nicht. Eine Dienstreise, ein neues Netz oder ein Sicherheitstest sehen aus wie ein Angriff — deshalb gibt es die Rückmeldung „verwerfen“.
Sie ersetzt kein phishing-resistentes Anmeldeverfahren. Sie erkennt Muster, nachdem ein Nachweis verwendet wurde; das Modul zu den Anmeldeverfahren verhindert, dass er überhaupt weitergereicht werden kann.
Sie ist bei nachträglichen Erkennungen keine Abwehr, sondern Aufklärung.

Richtig eingeordnet ist der Identitätsschutz die dritte Schicht: Anmeldeverfahren machen den Nachweis schwer stehlbar, Zugriffsregeln begrenzen, was ein Nachweis wert ist, und der Identitätsschutz bemerkt, wenn trotzdem etwas nicht stimmt.

Die Reihenfolge der InvestitionenAus dieser Schichtung folgt eine unbequeme Empfehlung. Wer vor der Wahl steht, zuerst phishing-resistente Anmeldeverfahren einzuführen oder zuerst den Identitätsschutz auszubauen, sollte mit den Verfahren beginnen. Erkennung ohne Abwehr erzeugt Befunde, die jemand bearbeiten muss; Abwehr ohne Erkennung verhindert Vorfälle, von denen niemand erfährt. Das zweite ist der bessere Zustand, wenn man nur eines haben kann.

Durchgerechnet: eine atypische Reise untersuchen

Zwei Anmeldungen, zwei Kontinente, elf Minuten

Szenario

Für ein Konto liegt eine Erkennung unlikelyTravel vor: zwei Anmeldungen aus weit entfernten Ländern innerhalb weniger Minuten. Die betroffene Person bestreitet jede ungewöhnliche Aktivität und arbeitet an ihrem gewohnten Ort.

Anforderungen

Der Befund soll aufgeklärt und richtig zurückgemeldet werden.
Falls es echt war, soll das Konto bereinigt sein.
Die Rückmeldung soll die künftige Erkennungsgüte nicht verschlechtern.

Schritte

Erkennungsart bestimmen: unlikelyTravel ist nachträglich. Beide Anmeldungen sind bereits erfolgt — es geht um Aufklärung, nicht um Verhinderung.
Die harmlose Erklärung zuerst prüfen: ein Unternehmens-VPN, ein Dienst mit ausländischem Ausgangspunkt oder eine Anwendung, die im Namen der Person zugreift, erzeugen genau dieses Bild.
Bestätigt sich eine harmlose, aber echte Ursache, ist die richtige Rückmeldung verwerfen — nicht „sicher“. Der Befund war zutreffend, und ähnliche Fälle sollen weiter bewertet werden.
Ergibt die Prüfung dagegen eine fremde Anmeldung: als kompromittiert bestätigen. Das hebt das Benutzerrisiko auf hoch.
Bereinigung folgen lassen — entweder über die Regel auf das Benutzerrisiko, die zum sicheren Kennwortwechsel führt, oder verwaltend, was zugleich die laufenden Sitzungen beendet.

Merksatz: Die Reihenfolge trennt zwei Fragen, die gern zusammenfallen: War der Befund richtig? Und war das Ereignis bösartig? Nur die zweite entscheidet über die Gegenmaßnahme, nur die erste über die Rückmeldung.

Der Preis dieser Sorgfalt ist Zeit — jede Untersuchung dauert länger als ein Klick auf „sicher“. Genau dieser Klick ist aber die teuerste Abkürzung im ganzen Bereich: Er nimmt dem System die Fähigkeit, denselben Fall künftig zu melden, und er kostet nichts, was heute sichtbar wäre.

Die Reihenfolge, die alles zusammenhält

Risikoart bestimmen: Anmeldung oder Identität→Erkennungsart prüfen: Echtzeit oder nachträglich→Stufe mit dem Wert des Kontos verrechnen, nicht allein sortieren→Harmlose Erklärung ausschließen, bevor eskaliert wird→Rückmeldung passend wählen — verwerfen und sicher sind nicht dasselbe

Erkennung ist nicht Abwehr

Der Identitätsschutz ist die Schicht, die zugibt, dass die anderen beiden versagen können. Sein Nutzen hängt weniger an den Erkennungen als daran, was eine Organisation mit ihnen tut — und die häufigste Fehlbedienung ist nicht eine falsche Regel, sondern eine unbedachte Rückmeldung.

Gleich im CheckDie Übungen prüfen die Zuordnung der Risikoarten zu ihren Gegenmaßnahmen, die Folgen nachträglicher Erkennung, die Wahl der richtigen Rückmeldung und den Zuschnitt einer Regel bei bekannter Fehlalarmneigung.

Jetzt anwenden

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

Zum Modul →

Quellen & Aktualität4 Primärquellen · zuletzt geprüft: 2026-09-13