Azure ACS Is Retired: Fixing SharePoint Apps That Stopped Working

If a SharePoint integration in your tenant stopped working some time after 2 April 2026, and the failure looks like a sudden 401 Unauthorized from an application that had run untouched for years, the cause is almost certainly Azure Access Control Services (ACS). ACS was the authorization layer behind the SharePoint Add-in model, and Microsoft switched it off for SharePoint Online on that date.

This is not a deprecation notice you can defer. The service is gone for every existing tenant, including Government Community Cloud and Department of Defense environments. What follows is what actually broke, how to find the affected applications in your own tenant, and what the supported replacement looks like in practice.

What Azure ACS Actually Did

Azure Access Control Services issued and validated the access tokens used by the SharePoint Add-in model. When an application was registered through /_layouts/15/appregnew.aspx and granted permissions through /_layouts/15/appinv.aspx, the client ID and client secret it received were ACS credentials. Every call that application made to SharePoint exchanged those credentials for an ACS-issued token.

That model predates the modern Microsoft identity platform, and it carried a set of properties that are difficult to defend today:

• Shared secrets with long lifetimes. A client secret was typically valid for a year, and renewing it was a manual PowerShell exercise that teams routinely forgot until something broke.

• Coarse permission scopes. An add-in granted tenant-scoped FullControl had exactly that, everywhere, with no practical way to narrow it afterwards.

• No Conditional Access integration. ACS tokens sat outside the policy engine that governs the rest of Microsoft 365, so an ACS-authenticated application was unaffected by the controls applied to every human account.

• No unified audit story. Diagnosing what an add-in had done, and when, meant correlating across surfaces rather than reading one log.

Microsoft announced the retirement of both ACS for SharePoint Online and the SharePoint Add-in model on 27 November 2023. ACS stopped working for any tenant created after 1 November 2024, and it was retired for every remaining tenant on 2 April 2026 — with no option to extend it further.

What Broke, and What Did Not

The retirement is narrower than it first appears, and the distinction matters when you're triaging.

The pattern is consistent: anything that got its token from ACS stopped; anything that got its token from Microsoft Entra ID continued.

The pattern is consistent: anything that got its token from ACS stopped. Anything that got its token from Microsoft Entra ID kept working. One related but separate date is worth knowing too — new add-ins could no longer be acquired from the SharePoint Store after 1 July 2024, though add-ins already deployed from it kept running until the April 2026 cutoff.

Finding the Affected Applications

The hardest part of this migration is rarely the code — it's discovering what exists. ACS registrations accumulated over a decade, often created by people who have since left, for integrations nobody documented.

Run the Microsoft 365 Assessment Tool

Microsoft and the PnP team publish an assessment tool specifically for scanning a tenant for SharePoint Add-in and ACS usage. It's the right starting point because it reports on the whole tenant rather than only the sites you happen to remember.

Enumerate registered principals with PowerShell

PnP PowerShell can list the app principals registered against a site collection. The cmdlets below are the ones most documentation still refers to by their AzureAD names; recent versions of PnP PowerShell have renamed the underlying cmdlets to EntraID, keeping the older names as aliases, so either form works today:

Connect-PnPOnline -Url "https://contoso.sharepoint.com/sites/finance" -Interactive

# List app principals with permissions registered against this site
Get-PnPAzureADAppSitePermission | Format-Table Id, DisplayName, Roles

Run this against every site collection you can reach, not just the obvious ones. A registration on a small departmental site is exactly the kind that gets missed and then surfaces as an outage weeks later.

Search your own codebase

Anything in source control matching these markers is an ACS integration:

• appregnew.aspx or appinv.aspx in setup notes or documentation

• AuthenticationManager.GetACSAppOnlyContext or similar helper calls

• A ClientId paired with a ClientSecret used against a SharePoint URL

• References to accesscontrol.windows.net

The Supported Replacement

The replacement is an application registration in Microsoft Entra ID, authenticating with OAuth 2.0 and calling either Microsoft Graph or the SharePoint REST API. For front-end customization that previously shipped as an add-in, the replacement is the SharePoint Framework (SPFx).

Register the application and scope its permissions

In the Microsoft Entra admin center, create an app registration and grant it application permissions. For direct SharePoint access the two common choices are Sites.Selected and Sites.FullControl.All.

Prefer Sites.Selected. It grants no access on its own; an administrator then explicitly grants the application rights to individual site collections. This is the single most valuable improvement available in this migration, because it replaces the tenant-wide reach that ACS registrations typically had with a scope you can enumerate and defend.

# Grant a Sites.Selected application Write access to one site
Connect-PnPOnline -Url "https://contoso.sharepoint.com/sites/finance" -Interactive

Grant-PnPAzureADAppSitePermission `
  -AppId "00000000-0000-0000-0000-000000000000" `
  -DisplayName "Finance Reporting Service" `
  -Site "https://contoso.sharepoint.com/sites/finance" `
  -Permissions Write

Permissions accepts Read, Write, Manage, or FullControl — grant the narrowest one the application actually needs.

Authenticate with a certificate, not a secret

This is a requirement, not merely a preference. When an Entra ID app calls the SharePoint REST or CSOM API directly with app-only authentication — which is what Connect-PnPOnline does under the hood, and what most migrated ACS integrations will do — SharePoint Online requires a certificate. A client secret is rejected outright with an access-denied response; it isn't accepted as a fallback. If you instead call SharePoint data exclusively through Microsoft Graph, a client secret will authenticate, but a certificate is still the better choice: it keeps the private key out of configuration files, and it doesn't expire on the yearly cadence that made ACS secret rotation such a chore.

Connect-PnPOnline `
  -Url "https://contoso.sharepoint.com/sites/finance" `
  -ClientId "00000000-0000-0000-0000-000000000000" `
  -Tenant "contoso.onmicrosoft.com" `
  -CertificatePath "./service-auth.pfx" `
  -CertificatePassword (Read-Host -AsSecureString)

Where the platform offers a managed identity — an Azure Function or Logic App, for instance — use that instead. It removes the credential from your configuration entirely.

Common Mistakes and How to Avoid Them

• Granting Sites.FullControl.All because it's quicker. This reproduces the exact permission problem the migration is an opportunity to fix. Start with Sites.Selected and widen only when a genuine requirement forces it.

• Migrating the credential but not the code. The SharePoint Add-in model is retired as a model, not just as an authentication mechanism. Swapping the token source under an add-in's app web doesn't make it supported; front-end customization needs to move to SPFx.

• Forgetting scheduled jobs. Nightly scripts and monthly reports fail silently. They're frequently discovered weeks after the deadline, when someone notices a report that stopped arriving.

• Assuming Power Platform connectors are affected. Standard SharePoint connectors in Power Apps and Power Automate use the modern identity stack and are not part of this retirement.

• Leaving the old registrations in place. A dead ACS principal grants nothing now, but it's misleading inventory when you're trying to reconstruct what a tenant actually depends on. Remove it once the replacement is verified — ACS principals otherwise expire on their own after their two-year default lifetime, but don't wait on that.

Troubleshooting after the cutover

Where This Leaves You

None of this is optional cleanup — ACS for SharePoint Online is gone, and the SharePoint Add-in model retired alongside it. But the forced migration is also the first real opportunity most tenants have had in years to replace broad, silent, long-lived credentials with scoped, certificate-backed Entra ID registrations that sit inside the same Conditional Access and audit story as everything else in Microsoft 365. Treat the inventory step seriously, migrate deliberately to Sites.Selected, and you'll come out of this with a smaller, better-understood attack surface than you had going in.

Sources consulted:

• Azure ACS retirement in Microsoft 365 – Microsoft Learn

• SharePoint Add-Ins and Azure ACS retirement FAQ – Microsoft Learn

• SharePoint Add-In retirement in Microsoft 365 – Microsoft Learn

• Granting access via Entra ID App-Only – Microsoft Learn

• Microsoft 365 Assessment Tool – SharePoint Add-In and Azure ACS Assessment

• Grant-PnPEntraIDAppSitePermission – PnP PowerShell

• Get-PnPEntraIDAppSitePermission – PnP PowerShell