Exchange Apps ab Juni nur noch über Admin-Zustimmung

In vielen Entra ID-Umgebungen können Benutzer derzeit externen Anwendungen eigenständig Berechtigungen auf ihr Exchange-Postfach erteilen. Wenn eine App Zugriff auf Kontakte oder Aufgaben anfordert, genügt oft ein einfacher Klick des Anwenders auf die Schaltfläche für die Zustimmung. Dieser Mechanismus öffnet Angreifern den Weg für Consent Phishing.

Ein Angreifer muss keine Anmeldeinformationen stehlen, wenn der Benutzer einer bösartigen App selbst die Berechtigung zum Auslesen des Adressbuchs erteilt. Um diese Angriffsfläche auf Architektur-Ebene zu verkleinern, ändert Microsoft die von Microsoft verwaltete Standardrichtlinie für die Benutzerzustimmung (User Consent) in Microsoft Graph. 

Das Zielbild dieser Anpassung ist klar definiert. Microsoft setzt hier das „Secure by Default“-Prinzip als Teil der Microsoft Secure Future Initiative (SFI) um. Die Änderung erhöht die administrative Kontrolle über den Zugriff von Drittanbieter-Anwendungen auf Exchange-Daten. Das Standardverhalten für Zustimmungen wird somit an branchenübliche Best Practices zum Schutz von E-Mails und verwandten Inhalten angeglichen.

Ein OAuth-Token, das durch eine unbedachte Benutzerzustimmung generiert wird, gewährt einer App API-Zugriff im Namen des Benutzers über sogenannte Delegated Permissions. Da Kontakte und Aufgaben oftmals sensible Unternehmensdaten oder Beziehungsgeflechte für gezielte Social-Engineering-Angriffe enthalten, entzieht Microsoft diese spezifischen Scopes der direkten Benutzerkontrolle. Die technische Notwendigkeit für diesen Eingriff ergibt sich aus der Tatsache, dass ein kompromittiertes Adressbuch die exakte Kommunikationsstruktur eines Unternehmens offenlegt. Angreifer nutzen diese Netzwerke, um hochgradig personalisierte Phishing-Kampagnen gegen Partner und Kunden zu generieren. Durch den Zwang zur administrativen Prüfung wird die Verifizierung der App-Vertrauenswürdigkeit in die IT-Sicherheitsabteilung verlagert.

Microsoft fügt acht delegierte Microsoft Graph-Berechtigungen (Delegated Permissions) der empfohlenen Benutzerzustimmungsrichtlinie hinzu. Technisch landen diese Scopes in der Policy microsoft-user-default-recommended, der im August 2025 eingeführten, von Microsoft verwalteten Richtlinie.

Ab dem Zeitpunkt der Umstellung ist standardmäßig die Zustimmung eines Administrators erforderlich, wenn Drittanbieter-Apps diese Berechtigungen für den Zugriff auf Exchange-Daten anfordern. Die Anwender können diese Berechtigungen nicht mehr selbst erteilen.

Diese Umstellung steht nicht für sich allein, sie ist die Fortsetzung eines laufenden Secure-by-Default-Programms. Im August 2025 hat Microsoft zuerst die SharePoint- und OneDrive-Scopes (Files und Sites) der Benutzerzustimmung entzogen. Ende Oktober bis November 2025 folgte über MC1163922 die große Mail- und Teams-Welle mit rund zwanzig Scopes, darunter Mail.Read, Mail.ReadWrite, sämtliche Calendars-Berechtigungen, die Teams-Chat-Scopes sowie die Altprotokolle EAS, EWS, POP und IMAP. Mit den jetzt ergänzten Kontakte-, Aufgaben- und People-Berechtigungen schließt Microsoft die letzte größere Lücke im Exchange-Datenzugriff, die nach der ersten Welle noch über reine Benutzerzustimmung offenstand.

Eine wichtige architektonische Ausnahme greift bei der Mail-Client-Richtlinie. Diese zweite, von Microsoft verwaltete Policy trägt die ID microsoft-user-default-allow-consent-apps. Wenn eine App in der Mail-Client-Richtlinie als genehmigt hinterlegt ist, können Benutzer dieser Anwendung weiterhin zustimmen. Die Mail-Client-Richtlinie erlaubt Benutzern die Zustimmung zu genehmigten, beliebten E-Mail-Anwendungen für die Berechtigungen, die in der empfohlenen Benutzerzustimmungsrichtlinie enthalten sind.

Welche der beiden Policies in Deinem Tenant greift, entscheidet eine einzige Option. Ist in den Benutzerzustimmungseinstellungen „Enable user consent for popular Mail clients" aktiv, nutzt Dein Tenant die Mail-Client-Policy microsoft-user-default-allow-consent-apps, und Benutzer dürfen anerkannten Mail-Anwendungen weiterhin zustimmen. Ist die Option deaktiviert, greift ausschließlich microsoft-user-default-recommended, und alle acht Scopes laufen in die Adminzustimmung.

Die weltweite allgemeine Verfügbarkeit (General Availability) und der damit verbundene Rollout beginnen Anfang Juni 2026. Der Abschluss der Verteilung wird für Anfang Juli 2026 erwartet. Alle Microsoft 365-Tenants, die die von Microsoft verwaltete Standardrichtlinie für die Benutzerzustimmung verwenden, sind von dieser Änderung betroffen. Dies betrifft ebenso Administratoren, die Exchange Online und den App-Zugriff über Microsoft Graph verwalten, sowie Organisationen, die Drittanbieter-Anwendungen den Zugriff auf Exchange-Daten über delegierte Berechtigungen erlauben.

Die Anpassung der Richtlinien wirkt sich ausschließlich auf zukünftige Zustimmungsanfragen aus. Bereits bestehende genehmigte Apps und existierende Benutzerzustimmungen (User Consents) sind nicht betroffen und funktionieren weiterhin. Der Geschäftsbetrieb bestehender Schnittstellen wird durch das Update nicht unterbrochen. Für Tenants, die benutzerdefinierte Zustimmungsrichtlinien (Custom User Consent Policies) verwenden, ändert sich nichts. Zudem erfordert die Umsetzung dieser Sicherheitsmaßnahme keine zusätzlichen Lizenzen.

Da Benutzer den Zugriff nicht mehr selbst freigeben können, laufen App-Anforderungen ohne saubere Konfiguration in einen Fehler. Um operative Blockaden zu vermeiden, musst Du den Admin Consent Workflow konfigurieren. Dieser Workflow ermöglicht es den Benutzern, eine formelle Genehmigung für Apps anzufordern, die nun administrative Rechte benötigen.

Der Prozess funktioniert wie folgt: Ein Benutzer versucht eine Drittanbieter-App zu nutzen, die beispielsweise auf Contacts.ReadWrite zugreifen möchte. Der Entra ID Login-Screen blockiert die direkte Zustimmung und bietet dem Benutzer stattdessen ein Textfeld an, um eine Begründung für die Nutzung der App einzugeben.

Diese Anfrage wird an ein dediziertes Admin-Team weitergeleitet. Das Admin-Team prüft die Anfrage im Entra Admin Center unter den Admin-Zustimmungsanforderungen. Die IT-Abteilung bewertet den Herausgeber der App (Publisher Verification) und prüft, ob die angeforderten Berechtigungen dem Least-Privilege-Prinzip entsprechen. Nach der Freigabe durch den Administrator kann die App mandantenweit oder für ausgewählte Benutzer verwendet werden.

Der Rollout startet im Juni 2026, deshalb prüfst Du Deine App-Landschaft am besten jetzt, solange Du Zeit für eine saubere Vorbereitung hast. Im ersten Schritt identifizierst Du alle Drittanbieter-Anwendungen, die über Microsoft Graph auf Exchange-Daten zugreifen, und analysierst, welche Berechtigungen diesen Enterprise-Anwendungen bereits gewährt wurden.

Achte dabei gezielt auf delegierte Berechtigungen wie Contacts.ReadWrite, bei denen in der Spalte Administratoreinwilligung ein „Nein" steht. Genau diese Kombination, delegierter Zugriff ohne Adminzustimmung, fällt ab Juni 2026 unter die neue Sperre.

Für Anwendungen, die Deine Nutzer weiterhin ohne Unterbrechung brauchen, legst Du vorab granulare App-Zustimmungsrichtlinien an und passt die Benutzerzustimmung an die neuen Sicherheitsanforderungen an. Damit verhinderst Du, dass eine geschäftskritische App nach der Umstellung in eine Fehlermeldung läuft.

Genauso wichtig wie die Technik ist die Kommunikation. Aktualisiere Deine internen Wissensdatenbanken, damit das neue Standardverhalten für Zustimmungen dokumentiert ist, und informiere Helpdesk, Sicherheitsteam und App-Verantwortliche rechtzeitig. Nur so vermeidest Du Support-Eskalationen, wenn externe Mail-Clients oder CRM-Erweiterungen plötzlich eine administrative Freigabe fordern.

In größeren Tenants nervt das manuelle Klicken im Entra Admin Center. Wenn Du hunderte Enterprise-Anwendungen gegen die kommenden Restriktionen prüfen willst, automatisierst Du das über das Microsoft Graph PowerShell Modul. Für ein reines Audit genügen Lese-Scopes, damit liest Du die Richtlinien und löst die real vergebenen Berechtigungen samt zugehöriger Anwendung auf, ohne versehentlich etwas zu verändern.

Der Scope Directory.Read.All deckt zwei Dinge ab: das Auslesen der vergebenen OAuth2-Grants und das Auflösen der Service Principals zu lesbaren App-Namen. Policy.Read.All brauchst Du, um die Richtlinien-Definitionen einzusehen.

Lies zuerst beide relevanten, von Microsoft verwalteten Policies aus. Die Mail-Client-Richtlinie zeigt Dir, welche Anwendungen weiterhin per Benutzerzustimmung erlaubt bleiben. Die empfohlene Richtlinie zeigt Dir den tatsächlichen Sperrumfang, in den die acht neuen Exchange-Scopes wandern.

Der wichtigste Schritt im Vorfeld des Rollouts ist die Identifikation aller Enterprise-Anwendungen, denen Benutzer bereits delegierte Rechte für die bald eingeschränkten Scopes erteilt haben. Das folgende Skript ruft mit Get-MgOauth2PermissionGrant -All sämtliche Berechtigungsgewährungen im Tenant ab und filtert sie gegen die betroffenen Exchange- und Personen-Scopes. Damit kein gleichnamiger Scope einer anderen Ressource fälschlich anschlägt, prüft das Skript zusätzlich, ob die Gewährung wirklich gegen Microsoft Graph läuft.

Über die Eigenschaft ConsentType trennt das Skript sauber, ob eine Berechtigung mandantenweit durch einen Administrator (AllPrincipals) oder individuell durch einen Endanwender (Principal) erteilt wurde. Bestehende Zustimmungen laufen für die jeweiligen Nutzer zunächst weiter. Kritisch sind die Einträge vom Typ Principal mit einem Scope aus der Verbotsliste. Genau hier greift ab Juni 2026 die Sperre, sobald sich ein neuer Benutzer anmeldet oder eine App erweiterte Rechte anfordert, und der Admin-Consent-Workflow wird ausgelöst.

Mit diesen Daten bestimmst Du vorab, welche Anwendungen Du in die Mail-Client-Richtlinie oder in eine benutzerdefinierte App-Zustimmungsrichtlinie überführen musst, damit der Betrieb ohne Unterbrechung weiterläuft.

Die Umstellung auf administrative Zustimmungspflichten für Exchange-bezogene Graph-Berechtigungen ist ein überfälliger Architekturwechsel. Der Endanwender darf nicht die letzte Instanz für die Vergabe von API-Zugriffsrechten sein. Illicit Consent Grants sind zu einem primären Angriffsvektor geworden: Angreifer umgehen MFA und Geräte-Compliance vollständig, indem sie sich über eine gefälschte App ein legitimes OAuth-Token für dauerhaften Datenzugriff ausstellen lassen.

Mit dem Entzug der User-Consent-Fähigkeit für Kontakte und Aufgaben schließt Microsoft ein kritisches Leck im Standard-Setup von Microsoft 365. Ein kompromittiertes Adressbuch legt die exakte Kommunikationsstruktur eines Unternehmens offen, und diese Daten fließen direkt in personalisierte Phishing-Kampagnen gegen Geschäftspartner. Die Administratorzustimmung verlagert die Prüfung der App-Vertrauenswürdigkeit zurück in die IT-Sicherheit, die nun Publisher-Verifizierung und Least-Privilege bei den Scopes durchsetzt.

Für IT-Abteilungen bedeutet das anfangs etwas mehr Support-Tickets, weil Anwender legitime Apps nicht mehr ad hoc einbinden können. Ein sauber implementierter Admin-Consent-Workflow federt das ab und etabliert einen nachvollziehbaren Freigabeprozess. Der Aufwand zahlt sich über eine messbar kleinere Angriffsfläche aus. Die Änderung zwingt Unternehmen, sich aktiv mit ihrem App-Inventar zu befassen, und genau das sichert die Integrität der Exchange-Daten dauerhaft ab.

Microsoft stellt zusätzliche Informationen sowie weitere  Neuigkeiten im Microsoft 365 Admin Center im Nachrichtencenter unter der ID "MC1304287" bereit.