This page is for teams that still have something authenticating through Azure ACS. It is not an announcement. It sets out what changed, what did not, and what the work is.
What is being retired
Two separate things retired together, which is why they are read together here.
The SharePoint Add-in model was the SharePoint 2013 era extensibility model: a package installed from an app catalogue, either hosted inside SharePoint or hosted elsewhere and talking back to it. It was deprecated on 27 November 2023 and fully retired on 2 April 2026.
Azure Access Control Services (ACS) was the authorisation server those add-ins used, and it was also the mechanism behind a great deal of unattended automation that was never an add-in at all: scripts, integrations and background services holding a client ID and secret registered through appregnew.aspx. Its use with SharePoint Online stopped for new tenants on 1 November 2024 and stopped for existing tenants on 2 April 2026, across all environments including Government Clouds and Department of Defense. Microsoft states there is no option to extend beyond that date.
Azure ACS used outside the context of SharePoint was already retired on 7 November 2018 and is end of life.
What stops working
- ACS issued tokens are no longer valid. Anything that obtains an access token from ACS fails authentication rather than degrading. Code built on app only contexts acquired through ACS, including
GetACSAppOnlyContext, stops returning a usable context. appregnew.aspxandappinv.aspxstop being a valid path. Registering a principal there, or granting it SharePoint permissions there, is no longer a supported way to give an application access.- Add-ins can no longer be installed or deployed from tenant or site collection app catalogues.
The failure mode matters when you are planning. This is not a deprecation that degrades quietly over a quarter. On the retirement date, authentication that depended on ACS returns an error.
What is not affected
This is the half that is usually missed, and it is the reason a migration is smaller than it first looks.
- SharePoint Framework (SPFx) is not impacted. It is the recommended extensibility model and it does not use ACS.
- App catalogues stay. Both tenant and site collection app catalogues remain a fully supported part of the developer ecosystem. What ends is their use for add-ins; their use for SPFx solutions continues unchanged.
- SharePoint Server on premises is not affected. These retirements are SharePoint Online retirements. The add-in model's supportability inside on premises versions is unchanged.
What migration path exists
There is no in place upgrade. The technology changes, and so does the identity.
| The technology | Move to |
|---|---|
| SharePoint hosted add-in | SPFx web part or extension |
| Provider hosted add-in | An external application, on Azure for example, authenticated with Microsoft Entra ID, plus SPFx for anything inside the SharePoint interface |
| ACS app only authentication | A Microsoft Entra ID application registration, app only, authenticated with a certificate |
Two details decide how long the identity half takes.
Legacy ACS principals cannot be converted. They are visible in the Microsoft Entra admin centre under enterprise applications as read only entries. They are not upgradeable to full Entra ID application registrations. Each one becomes a new registration, with its permissions configured again and its consuming code updated.
Prefer Sites.Selected to tenant wide access. The supported direction is an Entra ID registration with application permissions granted per site, using Microsoft Graph or PnP tooling rather than the retired grant page. An application that previously held broad access through a legacy grant is an opportunity to narrow it, not a reason to reproduce it.
A mixed setup, meaning an Entra ID application registration whose SharePoint permissions were granted through appinv.aspx, is still an ACS dependency. It stops working with the rest.
What M365 Governance as Code can observe
Stated precisely, because a governance tool that implies coverage it does not have is worse than one that says nothing.
- It does not detect SharePoint Add-in authentication.
- It does not detect ACS principals.
- It does not detect
appregnew.aspxorappinv.aspxusage. - It may surface related modernisation work through its SharePoint customisation findings, where those apply.
- Detection of ACS dependencies is currently outside the product's scope.
Discovering what in your tenant still authenticates through ACS is, today, a manual exercise.
Primary Microsoft sources
- Azure ACS retirement in Microsoft 365
- SharePoint Add-In retirement in Microsoft 365
- SharePoint Add-In and Azure ACS retirement FAQ
- Modernisation guidance for existing SharePoint Add-In model implementations
Where this fits
The full picture of what ended and what to build on is in our guide to the state of SharePoint in 2026.