Wer in den letzten Wochen mit SharePoint Online zu tun hatte, dürfte es mitbekommen haben. Die SharePoint-Add-ins werden abgeschaltet, und auch App-only-Zugriffe über Azure ACS haben bald ausgedient. Am 2. April 2026 ist endgültig Schluss. Trotzdem laufen in vielen Tenants noch klassische Add-ins und Integrationen, um die sich dringend jemand kümmern muss. In meinen Projekten hat selten jemand einen vollständigen Überblick, von einem klaren Fahrplan für die Ablösung ganz zu schweigen. Kritisch wird es vor allem deshalb, weil diese Schnittstellen oft unbemerkt im Hintergrund arbeiten. Fallen sie aus, steht das Geschäft still.
Microsoft schaltet die Add-ins und den ACS-Zugriff gleichzeitig ab
Betroffen sind zwei Bereiche. Da sind einmal die klassischen SharePoint-Add-ins, die häufig über appregnew.aspx und appinv.aspx registriert wurden und mit ClientId/ClientSecret oder Zertifikat arbeiten. Dazu kommt der Azure Access Control Service (ACS), auf dem das klassische App-only-Zugriffsmodell für SharePoint Online beruht. Ab dem 2. April 2026 funktionieren solche Lösungen in SharePoint Online nicht mehr (Microsoft-Dokumentation zur Abschaltung der Add-ins, Ankündigung zur Einstellung von ACS App-only). Neue Add-ins lassen sich bereits heute nicht mehr bereitstellen, bestehende hören zum Stichtag auf zu arbeiten. Am härtesten trifft das Integrationen von Drittanbietern und Eigenentwicklungen, die tief in Geschäftsprozessen stecken.
Ein Scan mit dem Assessment Tool zeigt, was im Tenant noch läuft
Vor jeder Umstellung steht die Frage, was im Tenant überhaupt noch aktiv ist. Am zuverlässigsten finde ich das mit dem Microsoft 365 Assessment Tool (PnP) heraus, das ich von einer Admin-Workstation aus starte. Dafür braucht es in Entra ID eine App-Registrierung mit Sites.FullControl.All und Directory.Read.All, deren ClientId und Secret man beim Scan angibt. Gestartet wird der Scan über PowerShell:
# Voraussetzung: Entra App-Registrierung mit Sites.FullControl.All, Directory.Read.All
# Am Admin-PC mit PowerShell 7, Modul Microsoft365DSC installiert
Connect-M365Assessment -ClientId '<IhreClientId>' -TenantId '<IhrTenantId>'
Export-M365AssessmentReport -OutputFolder 'C:\Reports' -AssessmentType SharePointAddIns
Auf diese Weise erfasse ich alle verbliebenen SharePoint-Add-ins und ACS-Anwendungen mitsamt ihren Berechtigungen und ihrer Nutzung. Was dabei herauskommt, ist oft ernüchternd. Selbst in Tenants mit durchdachter Governance stoße ich regelmäßig auf vergessene Altlasten, meist aus früheren Migrationsprojekten oder aus Lösungen, die externe Dienstleister mitgebracht haben.
Über appregnew.aspx registrierte Add-ins fehlen in Entra ID
Viele klassische Add-ins wurden direkt über die SharePoint-Seiten /_layouts/15/appregnew.aspx und /_layouts/15/appinv.aspx registriert. In Entra ID (vormals Azure AD) erscheinen sie nicht. Wer nur die modernen App-Registrierungen prüft, übersieht sie deshalb leicht. Der Microsoft 365 Assessment Report listet diese Altanwendungen dagegen ausdrücklich auf, einschließlich der Sites, auf die sie zugreifen dürfen. Wer lieber in der Oberfläche sucht, wird im App-Katalog des SharePoint Admin Centers fündig oder in den Websiteeinstellungen unter „Websiteinhalte – Apps für SharePoint“. Genaues Hinsehen lohnt sich, denn auch Integrationen mit nichtssagenden Namen wie „MigrationTool“ oder „WorkflowApp“ können betroffen sein.
Praxis-Tipp: In meinen Auswertungen stoße ich häufig auf Add-ins, die noch Berechtigungen besitzen, aber seit Langem niemand mehr nutzt. Wer sie konsequent entfernt, baut technische Schulden ab und schließt gleichzeitig Sicherheitslücken.
Entra-App-Registrierungen mit Sites.Selected lösen das alte Modell ab
Die Zukunft liegt bei Entra-App-Registrierungen (vormals Azure AD App Registrations) mit zertifikatbasierter Authentifizierung und dem Berechtigungsmodell Sites.Selected. Eine App bekommt damit gezielt und ausdrücklich Zugriff auf einzelne Sites. Für die Sicherheit ist das ein deutlicher Fortschritt. Einfach ist die Migration allerdings selten:
- Die bestehende App-Logik muss auf die Graph API und moderne Authentifizierung umgestellt werden
- Statt Shared Secrets müssen Zertifikate eingerichtet werden
- Ein SharePoint-Admin muss die Sites.Selected-Rechte zuweisen (per PowerShell oder im Admin Center)
- Provider-hosted Add-ins müssen meist vollständig auf SPFx (SharePoint Framework) oder andere Integrationsmodelle umziehen
- Drittanbieter brauchen klare Fristen
Bei Eigenentwicklungen kommt man um eine Neuentwicklung kaum herum. Ein Provider-hosted Add-in lässt sich nicht einfach „umpatchen“, es braucht ein neues Fundament. SPFx ist mittlerweile ein ausgereiftes und unterstütztes Modell. Wer das Projekt aber erst jetzt anfängt, bekommt Zeitprobleme.
Das folgende vereinfachte Ablaufdiagramm zeigt, wie die Migration von ACS auf eine Entra-App-Registrierung mit Sites.Selected in der Praxis abläuft:
flowchart TD
Bestandsaufnahme["Bestandsaufnahme Add-ins/ACS"] --> Analyse["Analyse Nutzung/Berechtigung"]
Analyse --> Entscheiden["Abschalten oder Migrieren?"]
Entscheiden -->|"Abschalten"| Stilllegen["Stilllegen"]
Entscheiden -->|"Migrieren"| EntraApp["Entra App-Registrierung (Cert Auth)"]
EntraApp --> SitesSelected["Sites.Selected Berechtigung"]
SitesSelected --> SPFx["(Optional) Migration zu SPFx"]
Abbildung: Migrationspfad von SharePoint-Add-ins/ACS zur Entra-App-Registrierung mit Sites.Selected.
Anbieter und Entwickler brauchen jetzt eine klare Ansage
Ob die Umstellung gelingt, hängt stark davon ab, wie früh alle Beteiligten Bescheid wissen. Viele ISVs bieten inzwischen moderne, Entra-basierte Integrationen an. Ohne Nachfragen bleibt trotzdem oft die alte Variante im Einsatz. Ich rate deshalb, alle Anbieter mit Add-in- oder ACS-Anbindung zeitnah anzuschreiben und nach neuen Versionen oder Migrationswegen zu fragen. Manche Lösung wird dabei einfach ersetzt, manche braucht heute niemand mehr. Bei Eigenentwicklungen hilft nur eins: jetzt Entwicklungskapazität einplanen und nicht darauf hoffen, dass eine kleine Umstellung reicht.
Bis zur Abschaltung bleibt kein Tag zu verschenken
Zwei Monate bis zur Abschaltung sind bei SharePoint-Integrationen und Drittanbietern sehr knapp. Wer den Scan mit dem Microsoft 365 Assessment Tool noch nicht gemacht hat, sollte ihn spätestens jetzt angehen. Danach fängt die eigentliche Arbeit erst an, von der Bestandsaufnahme über die Gespräche mit den Anbietern und die Migrationsplanung bis zur schrittweisen Umsetzung. Immer wieder sehe ich, dass gerade die Rechtevergabe mit Sites.Selected und die Umstellung auf Zertifikate unterschätzt werden. Ohne offene Abstimmung mit den Anbietern und einen klaren Projektplan geht es jetzt nicht mehr. Wer das Thema weiter vor sich herschiebt, landet spätestens im April 2026 im Krisenmodus. Mehr zu den Hintergründen und den praktischen Folgen steht auch in meinem englischen Beitrag zum Thema.


