Wenn Zugangsdaten nicht mehr ausreichen — was Device Trust bedeutet und was Administratoren jetzt tun sollten
Passwort plus Zwei-Faktor-Authentifizierung — das galt lange als solide Basis für den Zugang zu Unternehmensanwendungen. Beides bleibt wichtig, reicht aber als alleiniger Vertrauensanker nicht mehr. KI-gestützte Phishing-Kits können Einmalpasswörter in Echtzeit abgreifen und weiterspielen, überzeugend gefälschte Nachrichten und Anrufe lassen sich in Minuten statt Wochen erzeugen, und IP-Reputation sowie Geolokation sind mit handelsüblichen VPNs oder kompromittierten Zwischenstationen schnell ausgehebelt. Was als Sicherheitsnetz gedacht war, ist unter dem Druck moderner Angriffswerkzeuge systematisch löchrig geworden — und das verändert, worauf Unternehmen ihren Zugriffsschutz aufbauen sollten.
KI senkt die Hürde für glaubwürdige Angriffe
Bisher war Aufwand die unsichtbare Bremse für Angreifer. Eine glaubwürdige Phishing-Mail in der richtigen Sprache, mit dem richtigen Kontext und zum richtigen Zeitpunkt zu versenden, erforderte Recherche, Anpassung und manuelle Arbeit. Heute liefern generative Modelle diesen Kontext auf Knopfdruck — inklusive korrekter Anrede, passender Signatur und dem richtigen Ton für die jeweilige Branche. Social Engineering, das früher aufwändig war, wird zur Routine.
Das hat konkrete Folgen: Adversary-in-the-Middle-Phishing-Kits (AiTM), die MFA-Token in Echtzeit abfangen und weiterspielen, sind seit Längerem bekannt und zugänglich. Die Hürde, ein gültiges Sitzungstoken oder eine Kombination aus Nutzername, Passwort und Einmalpasswort zu ergaunern, ist nach derzeitigem Kenntnisstand gesunken.
Warum klassische Vertrauenssignale allein nicht mehr ausreichen
Sicherheitssysteme verlassen sich traditionell auf eine Handvoll Signale, um zu beurteilen, ob ein Login legitim ist: Kennt der Nutzer das Passwort? Hat er den zweiten Faktor? Kommt die Anfrage aus einer bekannten Region, von einer bekannten IP-Adresse?
Jedes dieser Signale lässt sich unter bestimmten Bedingungen kompromittieren oder imitieren:
- Passwort und OTP: Durch AiTM-Phishing in Echtzeit abgreifbar, ohne dass der Nutzer es bemerkt.
- IP-Reputation und Geolokation: Über Proxys, VPNs oder kompromittierte Endpunkte im selben Land umgehbar.
- Verhaltensmuster: Lernbar und imitierbar, sobald ein Angreifer Fuß gefasst hat.
MFA und Passwortrichtlinien sind deshalb nicht überflüssig — im Gegenteil. Als alleinigen Filter zu betreiben bedeutet aber, auf Signale zu vertrauen, die unter modernen Bedingungen zunehmend angreifbar sind.
Das Gerät als zusätzlicher Vertrauensanker
Device Trust verschiebt den Fokus: Nicht nur „Wer meldet sich an?“ ist die Frage, sondern auch „Von welchem Gerät?“ — und: „Ist dieses Gerät vertrauenswürdig?“
Ein verwaltetes, bekanntes Gerät bringt Eigenschaften mit, die sich schwer fälschen lassen: Es ist in der MDM-Lösung registriert, erfüllt Compliance-Richtlinien — aktuelles Betriebssystem, aktivierte Verschlüsselung, kein Jailbreak — und kann ein kryptografisches Gerätezertifikat vorweisen, das an die Hardware gebunden ist. Ein Angreifer, der ausschließlich Zugangsdaten ergaunert hat, besitzt dieses Gerät nicht. Er scheitert an der nächsten Prüfstufe.
In Microsoft-Umgebungen sind die Werkzeuge dafür bereits vorhanden, in vielen Fällen durch bestehende Lizenzen abgedeckt: Conditional Access in Entra ID (Bestandteil von Microsoft 365 Business Premium und Entra ID P1, kostenpflichtig) kann Anmeldungen auf compliant gemeldete Geräte beschränken — solche also, die Intune-Richtlinien erfüllen. FIDO2-Sicherheitsschlüssel (Hardware, kostenpflichtig) und Passkeys (plattformintegriert, in der Regel ohne Zusatzlizenz nutzbar) gehen weiter: Der private Schlüssel verlässt das Gerät nie, ein Replay-Angriff ist damit strukturell ausgeschlossen. Entra ID Protection (erfordert Entra ID P2, kostenpflichtig) und Continuous Access Evaluation (CAE) ergänzen das, indem sie Sitzungen auch nach dem Login laufend neu bewerten — nicht erst beim nächsten Einloggen.
Was Administratoren jetzt konkret prüfen sollten
Device Trust ist keine Einzellösung, sondern eine Architekturentscheidung. Ein sinnvoller Einstieg in mehreren Schritten:
- Gerätebestand inventarisieren. Welche Geräte greifen auf Unternehmensanwendungen zu? Verwaltete Geräte, BYOD, unbekannte Endpoints? Erst wer den Bestand kennt, kann sinnvoll segmentieren und priorisieren.
- Conditional Access schrittweise einführen. Für hochsensible Anwendungen zunächst eine Richtlinie im Monitoring-Modus aktivieren, die Anmeldungen von nicht verwalteten Geräten als risikoreich markiert. Blockierung erst nach Auswertung der Auswirkungen auf den Betrieb.
- Phishing-resistente Authentifizierung prüfen. FIDO2-Keys oder Passkeys schließen den AiTM-Angriffspfad strukturell aus. Wo klassisches TOTP oder SMS-OTP noch im Einsatz ist, lohnt eine Bewertung der Ablösung.
- Legacy-Authentifizierung identifizieren. Basic Auth und ältere Protokolle hebeln Device Trust faktisch aus. Diese Protokolle sollten inventarisiert und — wo möglich — abgelöst oder gesperrt werden.
In vielen Umgebungen ist die vollständige Umstellung nicht von heute auf morgen möglich, besonders dort, wo BYOD-Geräte oder externe Partner beteiligt sind. Schrittweises Vorgehen ist sinnvoller als Stillstand.
Die Richtung ist eindeutig
Device Trust ist keine neue Idee — Zero-Trust-Architekturen propagieren sie seit Jahren. Was sich geändert hat, ist die Dringlichkeit. Solange Angriffswerkzeuge aufwändig zu bedienen waren, gab es einen natürlichen Filter. Diesen Filter gibt es nicht mehr. Wer heute Zugangskontrollen ausschließlich auf Zugangsdaten und klassisches MFA stützt, vertraut auf Signale, die unter modernen Bedingungen zunehmend angreifbar sind.
Der Einstieg muss kein Großprojekt sein: eine Bestandsaufnahme der Geräte, eine erste Conditional-Access-Richtlinie für die kritischsten Anwendungen, eine ehrliche Analyse der Legacy-Protokolle — das ist ein realistischer und erreichbarer Anfang.
Quellen: Bleeping Computer — „When Credentials Are No Longer Enough: Device Trust in the AI Era“ (https://www.bleepingcomputer.com/news/security/when-credentials-are-no-longer-enough-device-trust-in-the-ai-era/)