App-Login. Kein User.
MFA für alle Menschen beantwortet noch nicht, wer sich als Anwendung anmeldet. Gültige App-Zugangsdaten können eigene Zugriffswege öffnen – bis zu weiteren Secrets und Kundenmandanten.
Die Anwendung hat eine eigene Identität
Eine erfolgreiche Anmeldung ist zunächst ein technischer Vorgang. Ob dahinter ein berechtigter Zugriff steht, ist eine weitere Frage. Im Betrieb würde ich deshalb getrennt erfassen, welche Menschen und welche Anwendungen sich anmelden dürfen.
Todyl beschreibt unter dem Namen Key Eater den Missbrauch gestohlener, weiterhin gültiger App-Zugangsdaten gegen MSPs und deren Kunden. Der Bericht nennt keine neue Microsoft-Schwachstelle. Eine auf Nutzer begrenzte Conditional-Access-Regel stoppt solche App-Anmeldungen laut Todyl nicht.
Ein App-Schlüssel kann weitere Geheimnisse öffnen
Microsoft berichtet seit mindestens dem 28. Oktober 2026 über erfolgreiche Service-Principal-Anmeldungen mit kompromittierten App-Zugangsdaten. Darunter waren Herstelleranwendungen, deren Zugangsmittel Zugriff auf mehrere Kundenmandanten ermöglichten. Beobachtet wurden unter anderem Zugriffe auf Azure Key Vault und weitere Cloud-Ressourcen.
Für die eigene Bestandsaufnahme würde ich aus jeder App einen konkreten Prüfpunkt machen: Wer verantwortet sie, welche Zugangsmittel besitzt sie und welche Ressourcen darf sie lesen? Eine pauschale Kategorie wie „Integration“ sagt über die tatsächliche Reichweite wenig aus.
App-Logs und Nutzer-Tokens gemeinsam betrachten
Todyl meldet inzwischen auch die Wiederverwendung von Nutzer-Refresh-Tokens sowie gefälschte Browser-Kennungen. Der Anbieter empfiehlt, Service-Principal- und nicht-interaktive Anmeldungen mindestens ab dem 28. Oktober zu untersuchen, soweit die Aufbewahrung reicht. Fehlversuche gehören dazu; auf einen Fehler folgender Erfolg verdient besondere Aufmerksamkeit.
Ich würde diese Suche mit einer Zeitleiste verbinden: Anmeldung, angeforderte Ressource und anschließender Datenzugriff. Eine unauffällige Browser-Kennung wäre dabei kein Abschlusskriterium. Fehlen Protokolle für einen Zeitraum, bleibt das eine dokumentierte Erkenntnisgrenze.
Eindämmung umfasst auch Folgeschlüssel
Microsoft empfiehlt bei betroffenen Anwendungen, Secrets, Zertifikate und föderierte Zugangsmittel zu entfernen und den Service Principal bei Bedarf zu deaktivieren. Geheimnisse aus lesbaren Key Vaults sowie Zugangsdaten aus eingesehenen Dokumenten sollen rotiert werden. Bereits ausgestellte Tokens können bis zu ihrem Ablauf gültig bleiben.
Todyl warnt entsprechend davor, allein auf einen Schlüsseltausch zu vertrauen, und nennt für MSPs ausdrücklich die Prüfung der Partner- und Kundenzugriffe. Welche Maßnahmen im eigenen Mandanten nötig sind, würde ich aus den bestätigten Zugriffen und der Reichweite der betroffenen Identität ableiten.
Den Abschluss über Reichweite nachweisen
Microsoft empfiehlt Managed Identities, wo unterstützt, und möglichst geringe Rechte für Workload-Identitäten. Damit sinkt die Abhängigkeit von langfristig abgelegten Secrets; eine Prüfung der tatsächlich eingeräumten Berechtigungen bleibt erforderlich.
Mein Abschlusskriterium wäre eine nachvollziehbare Liste: betroffene Identitäten, erreichbare Ressourcen, gesicherte Befunde, bereinigte Zugangsmittel und überprüfte Folgezugriffe. Ein Eintrag „Secret rotiert“ ist dafür zu knapp. Die App kann mehr erreicht haben als ihren eigenen Login.