Azure ACS Is Retiring April 2, 2026: What Every SharePoint Admin Needs to Do Now

Introduction

In less than 30 days, Microsoft will permanently shut down Azure Access Control Service (ACS) for SharePoint Online. On April 2, 2026, the authentication endpoint goes dark — and every application, integration, and add-in that relies on it will stop working immediately. No grace period. No degraded mode. No option to extend.

If you're a SharePoint administrator, IT manager, or MSP responsible for Microsoft 365 tenants, this is the article you need to read right now. The Azure ACS retirement announcement on Microsoft Learn has been live since November 2023, but based on what I'm seeing in the field, a significant number of organizations — especially small and medium businesses — haven't started their migration yet.

This guide covers exactly what's happening, what breaks, how to check if your tenant is affected, and what to do about it before the deadline.

What Is Azure ACS?

Azure Access Control Service (ACS) is a legacy authentication and authorization service that Microsoft introduced for SharePoint around 2013. It served as a trust broker — issuing security tokens that allowed external applications to authenticate with and access SharePoint Online.

For nearly a decade, ACS was the way developers built SharePoint integrations. It powered two critical patterns:

• Provider-Hosted SharePoint Add-Ins: Externally hosted applications (running on Azure, AWS, or private servers) that used ACS tokens to connect back to SharePoint on behalf of a user or as an app-only principal.
• SharePoint App-Only Service Principals: Custom applications registered via the /_layouts/15/AppRegNew.aspx and /_layouts/15/AppInv.aspx pages, using ACS as the trust broker for background/service access without a user present.

This model worked, but it predates modern identity standards. ACS uses its own token format rather than the current OAuth 2.0 / Microsoft Entra ID standard. According to Microsoft's official retirement documentation, Entra ID provides more secure, compliant, and auditable authentication — including granular permissions via Sites.Selected (scoping access to specific sites instead of tenant-wide), support for conditional access policies, and MFA enforcement.

One important clarification: Azure ACS (Access Control Service) is not the same as Azure Communication Services, which also uses the abbreviation "ACS." As noted in a widely-discussed r/sysadmin thread, this confusion is common among IT admins. Azure Communication Services is not affected by this retirement.

The Retirement Timeline

Microsoft first announced the deprecation in November 2023 via Message Center announcement MC693863. Since then, the rollout has followed a phased approach with several milestones already passed:

Date	Milestone
November 27, 2023	Official deprecation announced (MC693863). SharePoint Add-In model formally deprecated.
March 1, 2024	No new SharePoint Add-Ins accepted for public marketplace listing.
July 1, 2024	End-users can no longer acquire or install SharePoint Add-Ins from the store.
November 1, 2024	Azure ACS stops working for new tenants. Add-Ins not activated for new tenants.
January 5, 2026	Microsoft issues 3-month reminder (MC693863 updated).
April 2, 2026	HARD STOP. Azure ACS fully retired. SharePoint Add-Ins fully retired. No extensions.
July 1, 2027	Remote Event Receivers registered via Entra ID (not ACS) continue to work until this date.

"This isn't like typical end-of-life scenarios where unsupported software keeps running but stops getting updates. Azure ACS is a cloud service. When Microsoft flips the switch, any app trying to authenticate gets an error." — Ryan Clark, MBA on LinkedIn

This applies to all environments including Government Clouds and U.S. DoD, as confirmed in the SharePoint Add-Ins and Azure ACS retirement FAQ.

What Breaks and What Doesn't

What Stops Working on April 2, 2026

• SharePoint-Hosted Add-Ins: These run entirely within SharePoint in an "app web" sub-site. The app web data is not automatically deleted on the retirement date — but when the add-in is eventually uninstalled, the app web and all its data are permanently destroyed.
• Provider-Hosted Add-Ins: External code that uses ACS tokens to authenticate back to SharePoint. These require a complete authentication overhaul — replacing TokenHelper.cs with MSAL.NET and implementing Entra ID app registrations.
• Remote Event Receivers (ACS-registered): Server-side events that fire when SharePoint actions occur. They stop silently — no errors thrown, events just stop being delivered.
• App Parts (Client Web Parts in Add-Ins): Stop rendering on SharePoint pages.
• ACS app-only authentication: Any custom app registered via AppRegNew.aspx / AppInv.aspx that authenticates using ACS tokens.
• SharePoint Store Add-In acquisition: Already blocked since July 2024.

What Is NOT Affected

• SharePoint Framework (SPFx): Not affected — SPFx is the recommended replacement.
• App Catalogs: Continue to work for SPFx solutions.
• CSOM (Client-Side Object Model): Not retired, continues to work.
• JSOM (JavaScript Object Model): Not retired, continues to work.
• SharePoint Server on-premises: Not affected. As clarified in a recent r/sharepoint discussion, the retirement only impacts SharePoint Online / Microsoft 365.
• Remote Event Receivers registered via Entra ID: Continue to work until July 1, 2027.

How to Check If You're Affected

Even if you believe your organization doesn't use SharePoint Add-Ins, you should verify. Shadow IT is common — apps may have been installed years ago by people no longer with the company. Here are the methods, from most comprehensive to quickest.

Method 1: PnP Microsoft 365 Assessment Tool (Recommended)

The PnP Microsoft 365 Assessment Tool (version 1.10.0+) is the primary tool for scanning ACS usage across your entire tenant. It generates detailed CSV reports you can analyze in Power BI or Excel.

# Set your tenant details
$tenantDomain = "contoso.sharepoint.com"
$clientid = "<your-app-client-id>"
$certThumbprint = "<your-cert-thumbprint>"
$certPath = "My|CurrentUser|" + $certThumbprint

# Start the scan in AddInsACS mode
./microsoft365-assessment.exe start `
  --mode AddInsACS `
  --authmode application `
  --tenant $tenantDomain `
  --applicationid $clientid `
  --certpath $certPath

# Check scan progress
./microsoft365-assessment.exe status

# Export reports to CSV
./microsoft365-assessment.exe report `
  --id <report-id> `
  --mode CsvOnly `
  --path ".\ACS-reports"

As explained on Vlad's SharePoint Blog, the key output files are:

• classicacsprincipals.csv — Lists all apps with SharePoint access. The AllowAppOnly column (TRUE = uses ACS) and ValidUntil column (a real date = registered via AppRegNew; zeroed date = registered in Entra ID) tell you exactly what you're dealing with.
• classicacsprincipalsites.csv — Maps each app to the sites it can access.
• classicacsprincipalsitescopedpermissions.csv — Site-level permission details.
• classicacsprincipaltenantcopedpermissions.csv — Tenant-wide permission grants.

Method 2: Check the App Principals Page

For a quick site-level check, navigate to any SharePoint site and append /_layouts/15/appprincipals.aspx to the URL. This shows all app principals registered to that site collection — both ACS and Entra-registered apps.

Method 3: Temporarily Disable ACS (PowerShell)

If you want to proactively identify hidden dependencies, you can temporarily disable ACS app-only access at the tenant level:

# Connect to SharePoint Online Management Shell
Connect-SPOService -Url https://<tenant>-admin.sharepoint.com

# Disable ACS app-only access tenant-wide
# WARNING: This will break any active ACS-dependent apps
Set-SPOTenant -DisableCustomAppAuthentication $true

# Re-enable if something breaks
Set-SPOTenant -DisableCustomAppAuthentication $false

Important: This disables ACS app-only access only. It does not impact provider-hosted add-ins (which also use ACS but through a different authentication flow). Use this approach only in test environments or after confirming no ACS usage remains.

Method 4: Audit Log Analysis

Check Microsoft Purview Audit logs for SharePointAppPermissionOperation events (RecordType 205). Events with UserType 0 and AuthenticationType FormsCookieAuth indicate ACS permissions were granted. Also search for events containing the keyword appinv to find when ACS permissions were provisioned.

Migration Paths

SharePoint-Hosted Add-Ins to SPFx

The migration path for SharePoint-hosted add-ins is straightforward but requires careful data handling:

1. Extract data from the app web before uninstalling. When a SharePoint Add-In is uninstalled, the app web and all its data are permanently deleted. Use the SharePoint REST API or Microsoft Graph to copy list data to a new location first.
2. Build replacement SPFx web parts that replicate the functionality.
3. Deploy to the SharePoint app catalog and add to relevant pages.
4. Migrate app web data to a standard SharePoint list within the target site.

As Voitanos explains in their migration FAQ, SPFx is a significant upgrade over the add-in model: no iframe overhead (faster load times), mobile-compatible by design, and native integration with Microsoft Teams and Viva Connections.

Provider-Hosted Add-Ins to Entra ID + Modern Auth

This is the most complex migration path. The core steps are:

1. Register an app in Microsoft Entra ID (Azure Portal → App Registrations).
2. Configure permissions using Microsoft Graph or SharePoint API permissions. Use Sites.Selected to scope access to specific sites — dramatically more secure than ACS's broad tenant-wide access.
3. Replace ACS token code with MSAL.NET authentication. Remove TokenHelper.cs dependencies and implement ConfidentialClientApplication.
4. Grant admin consent for the app permissions.
5. Test thoroughly before the April 2 deadline.

If the provider-hosted app included UI rendered in SharePoint pages (app parts), migrate the UI portion to SPFx while keeping the backend as a separate service authenticated via Entra ID.

Remote Event Receivers to Webhooks

For Remote Event Receivers (RERs) registered via ACS, the replacement is SharePoint Online Webhooks or Microsoft Graph Change Notifications. Both are asynchronous, as detailed in the official retirement FAQ on Microsoft Learn.

Critical limitation: Webhooks are asynchronous only. You cannot block or cancel SharePoint actions the way synchronous RERs could. If your RERs relied on synchronous blocking (for example, preventing unauthorized updates), you'll need alternative approaches: item-level permissions, hidden libraries for protected data, or custom list forms via SPFx List Form Customizers.

The Key Advantage: Sites.Selected

One of the most compelling reasons to migrate — beyond compliance — is the Sites.Selected permission model. Under ACS, apps often had broad tenant-wide access. With Entra ID, apps can be scoped to specific SharePoint sites only. This dramatically reduces the blast radius if app credentials are compromised and makes it far easier to demonstrate least-privilege compliance to auditors.

Action Plan for SMBs

Small and medium businesses are disproportionately at risk, according to IncWorx Consulting. Many SMBs have had SharePoint environments for 10+ years with apps installed by people who are no longer with the company. Orphaned ACS principals remain active. The "IT person" is often a generalist with limited SharePoint development knowledge. And many SMBs rely on ISVs whose HR, project management, or intranet tools may still be built on the add-in model.

Here's a concrete checklist to work through before April 2:

As Bridgeall's analysis highlights, budget constraints are a real concern for SMBs. Provider-hosted add-in migrations require developer time that can be significant if the original add-in was complex. If your organization doesn't have in-house developers, plan for consulting fees — but the cost of not migrating (broken integrations, data access loss, business disruption) is far higher.

One additional concern for organizations already dealing with ACS migration: Project Online is also being retired on September 30, 2026. If your organization uses both ACS-dependent integrations and Project Online, plan for both migrations simultaneously to avoid compounding disruptions. As highlighted in a widely-upvoted r/sysadmin thread with 188 votes, 2026 is shaping up to be an unusually dense year for Microsoft 365 retirements.

How Clear365 Can Help

At Clear365, we specialize in exactly this kind of Microsoft 365 transition work. If you're reading this article and realizing you need help — whether it's running the assessment, planning the migration, or executing the technical work — we're here for it.

Our approach is hands-on and practical:

• Tenant assessment: We run the full ACS and Add-In discovery scan, analyze the results, and deliver a clear report of what's affected and what's at risk.
• Migration planning: We map each affected app to its migration path — Entra ID registration, SPFx rebuild, webhook replacement — with estimated effort and priority.
• Vendor coordination: We contact your third-party vendors on your behalf to verify their migration status and timelines.
• Technical execution: We handle the Entra ID app registrations, MSAL.NET integration, SPFx development, and webhook configuration.
• Post-migration validation: We verify everything works correctly and document the new architecture for your team.

Frequently Asked Questions

What is Azure ACS in the context of SharePoint?

Azure Access Control Service (ACS) is a legacy authentication service that Microsoft introduced around 2013 for SharePoint Online. It acted as a trust broker, issuing security tokens that allowed external applications, provider-hosted add-ins, and app-only service principals to authenticate with and access SharePoint data. It is not the same as Azure Communication Services, which shares the ACS abbreviation.

When exactly does Azure ACS stop working?

April 2, 2026 is the hard stop. On that date, the ACS authentication endpoint is permanently shut down. Any application that attempts to authenticate via ACS after that date will receive an error. There is no grace period, no option to extend, and no degraded mode.

Does the Azure ACS retirement affect SharePoint Server on-premises?

No. The Azure ACS retirement only affects SharePoint Online (Microsoft 365). SharePoint Server on-premises environments (2016, 2019, Subscription Edition) are not affected by this change.

What is the recommended replacement for SharePoint Add-Ins?

Microsoft recommends migrating to the SharePoint Framework (SPFx). SPFx web parts run natively in SharePoint pages without iframes, are mobile-compatible, and integrate with Teams and Viva Connections. For backend/service applications, use Microsoft Entra ID app registrations with OAuth 2.0 authentication.

What happens to data in SharePoint Add-In app webs after April 2, 2026?

App web data is not automatically deleted on the retirement date. However, when the add-in is eventually uninstalled or removed, the app web and all its data are permanently deleted. Export any app web data before uninstalling. If accidentally uninstalled, the app web can be restored from the recycle bin.

How do I check if my Microsoft 365 tenant uses Azure ACS?

The recommended method is to run the PnP Microsoft 365 Assessment Tool in AddInsACS mode. It scans your entire tenant and generates reports identifying all ACS-registered app principals. You can also check individual sites at /_layouts/15/appprincipals.aspx, or use PowerShell to temporarily disable ACS and identify dependent applications.

Can Remote Event Receivers still work after April 2, 2026?

Remote Event Receivers registered via ACS stop working on April 2, 2026. However, Remote Event Receivers registered via Entra ID continue to work until July 1, 2027. The long-term replacement is SharePoint Online Webhooks (asynchronous) or Microsoft Graph Change Notifications.