Wie binde ich Drittanbieter-Apps und Automatisierungen nach einer Microsoft-365-Migration sicher an?

Zugriffsmodelle in Microsoft 365: Benutzerkonto, Servicekonto und App-Identität über Entra ID

Nach einer Tenant-Migration laufen Integrationen oft unverändert weiter, obwohl sich Identitäten, Rollen und Sicherheitsrichtlinien geändert haben. In Microsoft 365 ist deshalb entscheidend, welches Zugriffsmodell eine Integration verwendet: ein menschliches Benutzerkonto, ein technisches (nicht-interaktives) Konto oder eine echte App-Identität über Entra ID. Jedes Modell erzeugt eine andere Sicherheits- und Governance-Signatur, insbesondere bei Nachvollziehbarkeit, Token-Ausstellung und dem Umgang mit Berechtigungen.

Benutzerbasierter Zugriff: Interaktiv, aber für Automatisierung riskant

Benutzerbasierte Zugriffe entstehen, wenn eine Integration im Namen eines angemeldeten Benutzers arbeitet. Typisch sind Add-ins, lokale Tools oder Skripte, die über OAuth einen Delegated Token erhalten. Das Modell passt zu Tätigkeiten, die an eine Person, deren MFA-Status und deren Conditional-Access-Kontext gebunden sein sollen. In der Praxis wird es jedoch häufig missbraucht: Automatisierungen laufen unter einem „Dauer-Login“, gespeicherten Kennwörtern oder App-Passwörtern. Das schwächt die Wirksamkeit von MFA, erschwert das Offboarding und führt zu schwer erklärbaren Zugriffsmustern (z. B. Logins aus Rechenzentren, die wie ein Benutzer erscheinen).

Hinzu kommt, dass Delegated Tokens inhaltlich den Benutzerkontext transportieren. Wird der Benutzer deaktiviert, sein Passwort zurückgesetzt oder sein Zugriff durch Richtlinien eingeschränkt, kann die Automatisierung brechen. Aus Betriebssicht wirkt das zunächst wie „Sicherheit als Störung“, in Wahrheit sind es korrekt greifende Kontrollen, die bei technischen Workloads an der falschen Stelle ansetzen.

Servicekonto: Technisch naheliegend, governance-seitig ein Sonderfall

Ein Servicekonto ist formal ein Benutzerobjekt, das faktisch für nicht-interaktive Nutzung vorgesehen wird. In Entra ID ist das kein eigener Kontotyp; es handelt sich um ein normales Konto mit abweichendem Lebenszyklus (Passwortverwaltung, Einschränkung interaktiver Nutzung, besonders strenge Protokollierung). Dieses Modell entsteht häufig aus Legacy-Integrationen, die nur Basic Auth oder „Username/Password“-Flows kennen. Seit der Deaktivierung von Basic Auth in Exchange Online (für die meisten Szenarien) und der allgemeinen Abkehr von Kennwortflüssen ist die langfristige Nutzung von Servicekonten für API-Zugriffe jedoch eine problematische Ausnahme.

Technisch lassen sich Servicekonten zwar stark einschränken (z. B. interaktive Anmeldung blockieren, Rollen minimieren, Conditional Access gezielt anwenden), doch bleibt der Kernkonflikt bestehen: Ein Kennwort oder ein statisches Geheimnis wird zur primären Kontrolle. Damit steigen Risiken durch Credential-Leaks, unklare Rotationsprozesse und mangelnde Bindung an eine konkrete Applikation. Zudem verwischen Verantwortlichkeiten: Im Audit-Log erscheint ein Benutzername, obwohl tatsächlich eine externe Plattform oder ein Workflow-Engine gehandelt hat.

App-Identität über Entra ID: Eigener Sicherheitskontext für Workloads

Das moderne Modell verwendet eine App-Identität, umgesetzt über App-Registrierungen in Entra ID. Die Applikation authentifiziert sich gegenüber dem Microsoft Identity Platform-Endpunkt und erhält Tokens für definierte Ressourcen, etwa Microsoft Graph. Der Zugriff ist damit an eine eindeutig identifizierbare Anwendung gebunden (Client-ID), mit klaren Authentisierungsnachweisen (Zertifikat oder Secret) und einem separaten Berechtigungsmodell. Das ermöglicht ein präziseres Least-Privilege-Design und eine belastbarere Trennung zwischen interaktiven Benutzern und technischen Workloads.

App-Zugriffe treten in zwei grundlegenden Varianten auf: Delegated Permissions (im Auftrag eines Benutzers) und Application Permissions (ohne Benutzer, im eigenen App-Kontext). Für Hintergrundprozesse, Synchronisationsdienste oder Ticket-Connectoren ist der Application-Kontext häufig die korrekte Wahl, weil er keine Benutzeranmeldung voraussetzt und sich sauber in Verantwortlichkeiten, Monitoring und Secret-/Zertifikatsmanagement einfügt.

Präzise Abgrenzung in der Praxis: Erkennungsmerkmale und schnelle Checks

In Logs und Konfigurationen lässt sich das verwendete Modell meist eindeutig erkennen. Bei App-Identitäten tauchen typischerweise eine Application (Client) ID, ein Service Principal im Tenant und eine Consent-Historie auf. Bei benutzerbasierten Flows dominieren Nutzeranmeldungen, häufig mit wiederkehrenden Token-Erneuerungen. Servicekonten fallen durch „menschlich aussehende“ Kontonamen auf, die jedoch aus Automationsnetzen anmelden oder dauerhaft von wenigen Quell-IP-Ranges kommen.

• App-Identität identifizieren: In Entra ID unter App registrations und Enterprise applications nach einer übereinstimmenden Application (client) ID und einem Service Principal suchen.
• Delegated vs. Application prüfen: In der App-Konfiguration unter API permissions unterscheiden, ob Berechtigungen als Delegated permissions oder Application permissions erteilt wurden; bei Graph sind dies unterschiedliche Scope-/Role-Typen.
• Consent-Spuren nachvollziehen: In Audit-Daten und App-Details auf Admin-Consent achten; für Graph-Berechtigungen ist häufig Grant admin consent relevant, wenn tenantweite Rechte erteilt wurden.
• Servicekonto-Indikator: Wiederkehrende Anmeldeereignisse eines Benutzerobjekts ohne plausible Nutzeraktivität, oft gekoppelt mit dokumentierten Ausnahmen bei Conditional Access oder fehlender interaktiver Nutzung.
• Token-Quelle erkennen: Bei Workloads wird häufig der Client-Credentials-Flow über den Endpunkt https://login.microsoftonline.com/{tenant-id}/oauth2/v2.0/token genutzt; bei Benutzerflüssen steht ein Authorization-Code-Flow mit interaktiver Anmeldung im Vordergrund.

Für eine sichere Betriebsführung ist die saubere Zuordnung der Identität wichtiger als das konkrete Tool. Ein Workload, der Postfächer ausliest oder SharePoint-Dateien verarbeitet, benötigt eine eigene App-Identität mit nachvollziehbarem Owner, definiertem Berechtigungsumfang und kontrollierbarer Credential-Lebensdauer. Benutzerkonten und Servicekonten bleiben damit auf ihren sachlich passenden Zweck begrenzt: menschliche Interaktion beziehungsweise eng begründete Übergangs- oder Sonderfälle.

App-Registrierungen und OAuth in der Praxis: Delegated vs. Application Permissions, Consent, Scopes und Token-Lebenszyklen

Delegated vs. Application Permissions: Sicherheits- und Betriebsfolgen

Die Entscheidung zwischen Delegated und Application Permissions definiert das Bedrohungsmodell einer Integration. Bei Delegated Permissions handelt eine App „im Kontext“ einer angemeldeten Person; die resultierenden Token tragen Benutzer- und App-Identität. Damit lassen sich typische interaktive Szenarien abbilden, bei denen Richtlinien wie bedingter Zugriff, MFA-Anforderungen oder benutzerbezogene Zugriffsbeschränkungen wirken können. Gleichzeitig hängt die Verfügbarkeit von einem erfolgreichen Benutzer-Login ab und Prozesse brechen, sobald Konten deaktiviert oder Anmeldewege geändert werden.

Application Permissions (App-only) trennen die Ausführung von einzelnen Benutzerkonten. Der Token repräsentiert ausschließlich die App (Service Principal) und wird in der Regel für Hintergrunddienste, Daemons, Integrationsplattformen oder Batch-Jobs verwendet. Dadurch entsteht ein klarer Vorteil in Stabilität und Nachvollziehbarkeit technischer Zugriffe, allerdings entfällt der Schutz durch benutzerzentrierte Kontrollpunkte. Der Schutz muss stattdessen über Entra-Richtlinien für Workload-Identitäten (sofern im Tenant verfügbar), restriktive Berechtigungen, starke Credentials (Zertifikate) und konsequentes Token- und Secret-Management erfolgen.

Scopes, Rollen und Ressourcen: Berechtigungen präzise modellieren

In Microsoft 365 werden Berechtigungen über Ressource und Berechtigungstyp ausgedrückt. Bei Microsoft Graph heißen Delegated-Berechtigungen „Scopes“, während App-only-Berechtigungen als „App Roles“ (Application Permissions) vergeben werden. Entscheidend ist die saubere Trennung von „was“ (Ressource wie https://graph.microsoft.com) und „wie“ (Delegated oder Application). Eine robuste App-Registrierung vermeidet breite Berechtigungen wie das pauschale Lesen aller Postfächer, wenn nur ein einzelnes Shared Mailbox-Postfach verarbeitet werden soll. Wo möglich, reduzieren ressourcenspezifische Einschränkungen den Blast Radius, etwa über Application Access Policies bei Exchange Online.

Ein häufiges Missverständnis betrifft „Read“-Berechtigungen. Schon lesender Zugriff auf Teams-Chats, SharePoint-Inhalte oder Mail kann sensible Daten offenlegen, insbesondere wenn der Zugriff app-only und tenantweit wirkt. Minimalprinzip bedeutet daher nicht nur „weniger Berechtigungen“, sondern auch „kleinere Zielmenge“. Für Mail-Szenarien ist eine Kombination aus Graph-Berechtigung und Exchange-Scoping üblich; für SharePoint ist die Trennung zwischen tenantweiten Graph-Rechten und site-spezifischen Berechtigungen relevant, wenn die Integration nur ausgewählte Sites benötigt.

• Ressource eindeutig halten: Für Graph muss die Ressource https://graph.microsoft.com konsistent verwendet werden; Mischformen mit anderen Ressourcen sollten begründet und dokumentiert werden.
• Delegated nur bei echtem Benutzerfluss: Delegated-Berechtigungen passen zu interaktiven Flows wie authorization_code; sie sollten vermieden werden, wenn ein Prozess ohne Benutzer laufen muss.
• App-only nur mit Scoping: Bei Mailzugriff sollte Exchange Online über Application Access Policies eingeschränkt werden, z. B. mit New-ApplicationAccessPolicy und einem definierten Mail-enabled Security Group Scope.
• „.default“ bewusst einsetzen: Bei Client-Credentials wird häufig scope=https://graph.microsoft.com/.default genutzt; dann entscheidet ausschließlich die am Service Principal zugewiesene App-only-Berechtigung über die tatsächlichen Rechte.

Consent und Governance: Wer darf was freigeben?

Consent ist kein Formalakt, sondern eine sicherheitsrelevante Zustandsänderung: Er legt fest, welche Berechtigungen eine App im Tenant wirksam nutzen darf. Delegated Permissions können – abhängig von Tenant-Policies – durch Benutzer freigegeben werden, was in der Praxis zu unkontrollierten Drittanbieter-Integrationen führt. App-only-Berechtigungen erfordern Admin-Consent und sollten als Change mit Prüfpfad behandelt werden: Antrag, Risikoabwägung, technische Validierung und nachvollziehbare Freigabe.

Technisch lässt sich Consent über Entra-Einstellungen einschränken, etwa indem User-Consent auf verifizierte Publisher oder auf risikoarme Berechtigungen begrenzt wird. Für produktive Tenants gilt: Ohne klare Zuständigkeiten für App-Owner, Genehmiger und Betrieb entstehen „Waisen“-Service-Principals, deren Berechtigungen niemand mehr fachlich vertreten kann. Zusätzlich sollten Publisher Verification und, wo verfügbar, Conditional Access für Workload-Identitäten berücksichtigt werden, um riskante Token-Ausstellungen zu begrenzen.

Token-Lebenszyklen: Access Tokens, Refresh Tokens und Rotation der Credentials

OAuth in Entra ID basiert in der Praxis auf kurzlebigen Access Tokens und – je nach Flow – Refresh Tokens oder auf wiederholter Token-Anforderung per Client Credentials. Access Tokens sind typischerweise kurz gültig; ihre exakte Laufzeit ist abhängig von Ressource, Client-Typ und Tenant-Policies und sollte nicht als verlässliche „Sessiondauer“ interpretiert werden. Für interaktive Delegated-Szenarien erneuern Refresh Tokens die Sitzung, bis Richtlinien, Benutzerstatus oder Token-Revocation dies verhindern. Für app-only Szenarien existieren keine Refresh Tokens; die App fordert regelmäßig neue Access Tokens an und muss dabei die Credential-Sicherheit (Secret/Zertifikat) garantieren.

Die zentrale Betriebsfrage lautet daher nicht „Wie lange lebt das Token?“, sondern „Wie wird die Berechtigung zur Token-Ausstellung geschützt und rotiert?“. Client Secrets sind schnell eingerichtet, aber schwer sicher zu betreiben: Sie werden kopiert, verteilt und oft in Automationssystemen persistiert. Zertifikate sind in der Handhabung anspruchsvoller, reduzieren aber bei korrekter Schlüsselablage das Risiko und unterstützen planbare Rotation. In beiden Fällen sollte die App Telemetrie erzeugen, um Token-Anforderungen, Fehlerquoten und ungewöhnliche Zielressourcen zu erkennen.

• Client Credentials Flow: Token-Anforderung gegen https://login.microsoftonline.com/{tenant-id}/oauth2/v2.0/token mit grant_type=client_credentials und scope=https://graph.microsoft.com/.default.
• Authorization Code Flow: Interaktiv mit response_type=code, anschließend Token-Tausch am v2.0-Endpoint; nur hier entstehen typischerweise Refresh Tokens für Delegated-Zugriffe (abhängig vom Client und den angeforderten Offline-Rechten).
• Rotation operationalisieren: Secrets mit kurzer Laufzeit und geplanter Erneuerung; bei Zertifikaten frühzeitige Erneuerung vor Ablauf und Rückbau alter Schlüssel nach erfolgreicher Umstellung.
• Revocation einkalkulieren: Deaktivieren des Service Principals oder Entfernen der App-Rollen wirkt auf neue Token-Ausstellungen; bereits ausgegebene Access Tokens bleiben bis zum Ablauf gültig.

Typische Fehlkonfigurationen rund um OAuth und konkrete Korrekturen

Die häufigsten Probleme entstehen an Schnittstellen zwischen Entwicklung, Betrieb und Sicherheit. Überprivilegierte Apps bleiben unauffällig, bis ein Audit oder ein Incident die tatsächliche Reichweite offenlegt. Ebenso kritisch sind vergessene Secrets: Ein ablaufendes Secret führt zu Ausfällen; ein nie rotierendes Secret erhöht das Missbrauchsrisiko. Daneben treten Fehlannahmen über Consent auf, etwa wenn Delegated-Berechtigungen vergeben werden, obwohl eine Integration technisch app-only arbeitet, oder wenn Admin-Consent „einmalig“ erteilt und anschließend nicht mehr gegen Permission-Änderungen geprüft wird.

• Überprivilegierung: Entfernen nicht benötigter Graph-App-Rollen und Neubeantragung mit minimalen Rechten; Validierung über Get-MgServicePrincipalAppRoleAssignment und Abgleich mit dem tatsächlichen API-Call-Set.
• Unklare Verantwortlichkeit: Setzen eines fachlichen Owners (App-Owner) und technischem Betreiber; Pflege der Metadaten am Service Principal, z. B. über Update-MgServicePrincipal -ServicePrincipalId ... -Tags und ein eindeutiges Naming.
• Secret-Drift und Ablauf: Umstellung auf Zertifikatsauthentifizierung oder konsequente Secret-Rotation; Prüfung vorhandener Credentials über Get-MgApplication -ApplicationId ... sowie Get-MgServicePrincipal -ServicePrincipalId ....
• Falscher Permission-Typ: Wechsel von Delegated auf Application Permissions (oder umgekehrt) erfordert ein klares Redesign des Auth-Flows; Anpassung der App-Konfiguration und erneuter Admin-Consent, z. B. über az ad app permission admin-consent --id <appId> (nur wenn Azure CLI/Entra-Module im Einsatz und der Befehl in der Umgebung unterstützt wird).

Sicherer Betrieb nach der Migration: Minimalrechte, Secrets/Zertifikate, Rotation, typische Fehlerbilder und kontrollierte Außerbetriebnahme

Nach einer Tenant-Migration laufen Integrationen oft „wie zuvor“ weiter, obwohl sich Identitäten, Ressourcen-IDs, Conditional-Access-Rahmenbedingungen und Berechtigungsmodelle verändert haben. Für den sicheren Betrieb zählt weniger, ob ein Workflow technisch funktioniert, sondern ob Rechteumfang, Authentifizierungsfaktor und Lebenszyklus der Anmeldeinformationen kontrolliert sind. App-Registrierungen müssen daher wie produktive Komponenten behandelt werden: mit Minimalrechten, klaren Besitzverhältnissen, geplanter Rotation und einem Abschaltpfad.

Minimalrechte konsequent umsetzen: Scopes, Rollen und Admin-Consent

Das Prinzip der geringsten Rechte beginnt bei der Wahl des Berechtigungstyps. Delegated Permissions bilden Benutzerkontext ab und eignen sich für interaktive Szenarien oder Services, die bewusst im Auftrag eines angemeldeten Kontos arbeiten. Application Permissions wirken mandantenweit ohne Benutzerkontext und sind für Automatisierungen üblich, aber riskanter: Jede zu breit vergebene Rolle kann im Missbrauchsfall große Datenräume öffnen.

Minimalrechte bedeuten außerdem, die „bequemen“ Sammelberechtigungen zu vermeiden. Bei Microsoft Graph ist beispielsweise zwischen Lese- und Schreibrechten sowie zwischen „All“ und granulareren Varianten zu unterscheiden, sofern verfügbar. Für Exchange Online sollten moderne, eng begrenzte Zugriffsmodelle bevorzugt werden (z. B. Application Access Policies zur Einschränkung von App-only-Zugriffen auf Mailboxen), statt applikationsweit alles zuzulassen. Admin-Consent gehört in einen kontrollierten Prozess: Jede neue oder geänderte Berechtigung ist eine Sicherheitsänderung und benötigt einen prüfbaren Anlass, eine Ticketreferenz und einen Verantwortlichen.

Secrets und Zertifikate: Auswahl, Härtung und Betriebsmodell

Für App-basierte Authentifizierung sind Client Secrets zwar schnell eingerichtet, aber betrieblich fehleranfällig: Sie werden in Skripten „mitkopiert“, landen in Logs oder bleiben über Jahre unverändert. Zertifikate (Client Certificate Credentials) reduzieren typischerweise das Risiko von Leaks, weil private Schlüssel besser in geschützten Speichern gehalten werden können. Unabhängig von der Wahl gilt: Anmeldeinformationen gehören nicht in Quellcode oder Konfigurationsdateien im Klartext, sondern in einen Secret Store mit Zugriffskontrolle und Audit (z. B. Azure Key Vault) und mit automatisierbarer Rotation.

Operativ bewährt sich ein Modell mit mindestens zwei parallel gültigen Credentials (A/B), damit Rotation ohne Downtime möglich bleibt. Zusätzlich sollte die App so gebaut oder konfiguriert sein, dass sie bei Credential-Fehlern deterministisch reagiert (saubere Fehlermeldungen, Alarmierung, keine „Silent Retries“ über Stunden ohne Sichtbarkeit). Für besonders kritische Integrationen kann eine Bindung an Netzwerk- oder Workload-Kontexte relevant sein, etwa über Conditional Access für Workloads (sofern lizenziert/verfügbar) und strikte Einschränkungen, welche Identitäten Token erhalten dürfen.

• Credential-Typ festlegen: Wo möglich Zertifikat statt Secret; bei Secrets kurze Laufzeiten und Ablage ausschließlich in einem Secret Store, nicht in .ps1, .env oder CI-Variablen ohne Zugriffskontrolle.
• Parallelbetrieb für Rotation: Zwei gültige Nachweise (z. B. „Credential A/B“) konfigurieren und in der Applikation einen umschaltbaren Verweis pflegen, statt feste Werte zu „hardcoden“; in Entra ID unter App registrations > Certificates & secrets die Gültigkeit überlappend planen.
• Schlüsselmaterial schützen: Private Keys nicht exportierbar halten, wenn die Plattform das unterstützt; bei Nutzung von Key Vault Zugriffe über Managed Identity oder streng begrenzte Service Principals und Protokollierung aktivieren (z. B. Key-Vault-Diagnose über AzureDiagnostics).
• Besitz und Break-Glass klären: Mindestens zwei Owner in Entra ID dokumentieren; „Break-Glass“-Prozess definieren, wie bei abgelaufenem Credential kurzfristig reagiert wird, ohne ad-hoc Rechte auszuweiten.

Token-Lebenszyklen kontrollieren: Ablauf, Widerruf und Session-Risiken

OAuth-Token sind kurzlebige Nachweise, aber ihr Missbrauchsfenster hängt vom Typ ab: Access Tokens sind typischerweise relativ kurz gültig, Refresh Tokens können länger wirken und sind damit für Angreifer attraktiver. App-only Flows (Client Credentials) arbeiten ohne Refresh Token, erzeugen aber wiederholt neue Access Tokens; hier verschiebt sich der Schutzfokus auf Credential-Sicherheit und auf Monitoring, welche App wann Token anfordert. Bei delegated Flows können Refresh Tokens und Persistenzmechanismen (z. B. Token-Caches in Automatisierungsplattformen) zu „unsichtbaren“ Langzeit-Zugriffen führen, selbst wenn das Benutzerkennwort rotiert wurde.

Kontrolle entsteht durch einen Mix aus Richtlinien und Betriebsmaßnahmen: Token sollten bei Rollen- oder Berechtigungsänderungen nicht als „vertrauenswürdig bis zum Ablauf“ betrachtet werden. Wo verfügbar, müssen Sitzungen und Token gezielt widerrufbar sein, etwa über das Zurücksetzen von Benutzer-Sitzungen/Anmeldestatus oder das Entfernen/Deaktivieren des Service Principals. Zusätzlich hilft Telemetrie: Sign-in-Logs für Service Principals, ungewöhnliche Token-Anfragen (Häufigkeit, Quelle, Uhrzeit) sowie Consent-Änderungen sind zentrale Indikatoren für Fehlkonfiguration oder Kompromittierung.

• Missbrauchsfenster reduzieren: Bei delegated Szenarien Token-Caching nur kontrolliert zulassen und Persistenzorte prüfen; bei App-only Flows die Credential-Sicherheit priorisieren und Token-Anforderungsraten über Sign-in-Logs auswerten (z. B. Filter auf Sign-ins für Service principal).
• Widerruf technisch einplanen: Für akute Vorfälle Maßnahmen vorab testen: Deaktivierung des Service Principals, Entfernen von Credentials oder Entzug von App-Rollen; für Benutzerkontexte zusätzlich Sitzungsrücksetzung bzw. Token-Revoke-Mechanismen der Plattform nutzen.
• Gültigkeit nicht mit Autorisierung verwechseln: Nach Änderungen an Berechtigungen oder Zugriffspolicies muss geprüft werden, ob bereits ausgestellte Tokens noch wirken können; bei Unsicherheit Zugriff unterbrechen und Neu-Consent/Neu-Auth erzwingen.

Typische Fehlerbilder nach Migration und fachlich saubere Korrekturen

Viele Sicherheitsprobleme entstehen nicht aus komplexen Angriffen, sondern aus Betriebsblindheit: Apps werden mit zu breiten Rechten ausgestattet, Secrets laufen ab und werden im Incident „schnell“ verlängert, oder die Zuständigkeit ist unklar, sobald Dienstleister und interne Teams wechseln. Nach Migrationen kommt ein zusätzlicher Treiber hinzu: Integrationen erhalten häufig „temporäre“ Sonderrechte, um Störungen zu beheben, die später nicht zurückgebaut werden.

Kontrollierte Außerbetriebnahme: Deaktivieren, Beweise sammeln, sauber löschen

Stilllegung darf nicht mit „Löschen“ beginnen. Zuerst braucht es einen Nachweis, ob und wo die App noch genutzt wird: Sign-in-Logs des Service Principals, Abhängigkeiten in Automationsplattformen, verwendete Webhooks oder Zertifikatsbindungen. Danach empfiehlt sich ein gestuftes Vorgehen: zunächst Berechtigungen zurückfahren, dann die App deaktivieren (reversibel), anschließend Credentials entfernen und erst zuletzt App-Objekte löschen. So bleibt ein kontrollierbares Rollback-Fenster, ohne langfristige Schatten-Identitäten zu tolerieren.

• Nutzung verifizieren: Sign-in- und Audit-Logs aufrufen und Zeitraum festlegen; für Microsoft Graph und Entra ID Auswertung in Sign-ins (Typ Service principal) und Audit logs, ergänzt um Abgleich mit Automationsjobs und Secret Stores.
• Deaktivierung als erste Sperre: Service Principal deaktivieren, bevor Objekte gelöscht werden; parallel Stakeholder informieren und ein Rückbaufenster definieren, um unerwartete Abhängigkeiten sichtbar zu machen.
• Credentials und Berechtigungen entfernen: Nach stabiler Deaktivierungsphase Secrets/Zertifikate löschen und App-Rollen entziehen; in Key Vault Einträge widerrufen bzw. Versionen deaktivieren, statt nur neue Werte zu erzeugen.
• Dokumentation finalisieren: Stilllegungsdatum, verantwortliche Freigabe, entfernte Berechtigungen und referenzierte Systeme festhalten; verbleibende Artefakte (z. B. Webhook-Endpoints, Connector-Konfigurationen) ebenfalls bereinigen.