Microsoft has announced the retirement of Azure ACS, and as SharePoint administrators, we must take action. The retirement of ACS is a significant change – an entire era of SharePoint app‑only service principals will come to an end. SharePoint developers have relied on ACS‑based applications since 2013 to build custom solutions, and in software development, change always takes time. Code originally designed around ACS must now be reviewed and refactored to accommodate new authentication models, then recompiled, retested, and redeployed. Because of this, it is critical that organizations begin remediation efforts now to reduce risk and avoid major operational issues leading up to April 2026.
Another at‑risk group is data analysts. During an earlier phase of Azure Data Factory (ADF) adoption, ACS‑based applications were required, which means a significant number of long‑running data pipelines may still rely on ACS for authentication.
3 weeks before ACS EOL
If you have only recently learned that Microsoft’s Azure ACS–based (classic) app connections to SharePoint will stop working in a matter of weeks, and you are trying to determine whether you or your clients will be impacted, you may not have time to follow a detailed, step‑by‑step remediation guide below I shared ~ year ago. In that situation, one practical option is to conduct a controlled “scream test.”
I have been working with ACS for many years and have been preparing a large tenant for ACS retirement since 2024. Based on that experience, the following are the essential lessons and recommendations that matter most when time is limited.
The PnP team has done excellent work with the Microsoft 365 Assessment Tool. It provides visibility into applications with ACS enabled at both the site and tenant levels, including details about which sites an application has permissions to.
However, the raw output is only the starting point. Administrators still need to analyze audit and sign‑in logs and correlate the data to determine which ACS applications are actually active. In practice, this often reveals two additional layers of complexity: not all ACS‑enabled applications are currently in use, and not all active applications necessarily rely on ACS for authentication.
The next challenge is identifying the appropriate application and site owners and communicating the required remediation steps. At this stage, communication is frequently ignored or overlooked. This highlights a critical gap—the operational distance between the M365 Assessment Tool output and an application owner taking concrete action. Bridging that gap requires time, coordination, and sustained follow‑up.
An alternative approach is a “scream test”—a controlled, temporary disablement of ACS at the tenant level. This is a significantly faster way to surface unresponsive, unknown, or otherwise disengaged application owners whose solutions are still affected by ACS retirement. In many cases, only an actual service disruption creates sufficient urgency for owners to prioritize migration to modern authentication.
This approach does involve risk, as it may temporarily impact existing workloads or data pipelines. However, that risk is justified and, in practice, necessary to identify applications that still rely on ACS—even though they should have already been migrated. Without this step, such dependencies often remain hidden until Microsoft enforces the change, at which point remediation becomes reactive rather than controlled.
Recommended transition tactics: for developers
- Get a new App Registration in Azure (Entra Id) with Sites.Selected permissions, ensure no ACS permissions provided to the app (see details on Sites.Selected) and use it
- Prioritize using Microsoft Graph API
- If Graph API does not provide required functionality – it’s ok to use SharePoint API, but keep in mind in this case certificate should be used (not secret) for authentication
Recommended transition tactics: for SharePoint admins
High-level recommended steps are:
- Keep saving audit logs
- Encourage users and developers to register applications in Azure (not in SharePoint)
- Start providing Sites.Selected permissions
- Disable ability for site owners to use AppRegNew and AppInv
Stop registering service principals via AppRegNew and providing ACS permissions via AppInv - Pull report on existing Apps that use ACS permissions
- Notify developers and users of the ACS apps
- Switch ACS off earlier than Microsoft
Thinkin on devs – keep in mind:
– ACS apps have a huge legacy – tons of articles and code examples and so on…
– Switching to a modern authentication method would require changes in code (though minor, but still), so developers must be engaged
– Any change in code would require another round of code compilation, testing, deploying etc.
That means it is not easy (sometimes it is not even possible) to adopt a new modern authentication method. It requires efforts and time, so you need to notify dev as earlier as possible. So it is crucial to complete steps above and start communicating to users as earlier as possible.
Detailed steps for SharePoint administrators:
Keep audit logs
This should be done in advance, but if you did not – starting today and until it’s over you’d get audit logs from Microsoft 365 purview center – consider selecting all events with record type SharePointAppPermissionOperation. Also might be helpful to keep events anyone visited appinv.aspx or appregnew.aspx page. Pull logs now starting with earliest available event (usually 90 days). Some audit logs are available only through Microsoft Graph API. See more details regarding audit logs for ACS tracking KBA.
Encourage users registering applications in Azure (not in SharePoint)
Creating App Registrations in Azure is usually not what SharePoint admins do. Sometimes users are allowed to register apps, sometimes it is blocked for a regular user and done by identity management (or so) but the main idea – users and developers should be able to get service principals (App Registrations) in Azure. Users would need Sites.Selected permissions consented (see more about Sites.Selected) or granular permissions consented (more on granular permissions to SharePoint).
Some pro’s of App Registered in Entra Id (vs SharePoint App-only service principals):
– It supports authentication with client secret and/or certificate, custom expiration time
– It supports both APIs – Microsoft Graph API and classic SharePoint REST API
Be prepared to instruct users how to get and use certificates in their app registrations.
Provide Sites.Selected permissions
99% of requests for application permissions to SharePoint would require access to a specific site (sites), or to a specific list/library/folder/file (but not to entire tenant). So consider providing Sites.Selected permissions by default (or granular permissions when they are in GA). Create a process so users can request permissions to SharePoint sites for their Azure-Registered Apps. Consider automation if you are a large company (here is one of the possible Sites.Selected automation solutions).
Inform user that ACS is deprecated and you do not provide any new ACS permissions.
Disable registering new service principals in SharePoint
Once you are good in providing non-ACS permissions, it’s time to disable registering service principals in SharePoint. Users should not be able to get a new SharePoint App-only service principals (apps that they used to get from SharePoint sites just going to AppRegNew.aspx).
Disable ability for site owners register service principals in SharePoint via appregnew.aspx is done via Set-SPOTenant PowerShell cmdlet:
Set-SPOTenant -SiteOwnerManageLegacyServicePrincipalEnabled $false
When the value is set to false, the service principal can only be created or updated by the SharePoint tenant admin. Using AppInv.aspx page will also be disabled for site owners. Your users will start seeing “Your SharePoint tenant admin doesn’t allow site collection admins…” message (see details), but that’s ok.
There might be rare cases when your in-house solutions or 3-rd party apps got their secrets expired and would require new legacy ACS-based permissions, it is tempting to allow ACS permissions as an exception (as technically it is possible for SharePoint service admin to provide ACS-based access to sites), but I would strictly discourage you to do so. If you decide to provide ACS – track this activity (so you know for whom this ACS-based permissions were provided).
Pull report on existing ACS Apps that use ACS permissions
You need to know who are your vulnerable clients – you should pull reports to get a list of existing Apps that use ACS permissions, apps owners, maybe sites these apps have access to and sites owners
You can get list of developers combining
– audit log data from Admin Center and Graph API
– report from Entra Id on apps and owners
– report from SharePoint sites on permissions provided for apps
– reports generated by PnP Microsoft 365 assessment tool
Here is the detailed KBA on inventory active legacy ACS service principals in tenant
Consider the following steps to get ACS apps owners
- get ACS apps with permissions using Microsoft 365 assessment tool
- pull these apps owners from Entra Id
- using Graph API audit logs data – mark apps active/inactive based on date of the latest login
Notify developers and users of the ACS apps
From the step above we can have a lost of legacy ACS apps and their owners, as well as apps activity (last login), so we can start communicating developers (app owners):
- As earlier as possible – e.g. in March-April 2025 (1 year before ACS EOL), notify all apps owners that they need to transition to Azure apps and Selected permissions
- Get ACS apps activity and repeat communication, including active app owners
- Get ACS apps activity and repeat communication, including owners of sites apps still have access to
- Communicate to all apps owners that there will be a temporary and permanent shut down of ACS (see below)
- I case you have ACS apps with tenant-level permissions – communicate to them separately
Switch ACS off earlier than Microsoft
You need to plan actual ACS apps disablement in tenant in advance – earlier than Microsoft will do it (though Microsoft can decide put it off). Also consider temporary switch off ACS (“scream test”) even earlier, let say, starting January 2026.
Temporary and permanent ACS disablements before official ACS EOL are needed as scream tests – in case there are irresponsive app owners who ignored all communications and still use ACS apps. Disabling ACS early may cause problems with existing applications, but it is necessary to avoid more serious consequences when the time comes for Microsoft to turn it off. So be prepared to handle tickets and communicate to apps owners in advance.
There are might be cases when software was developed by somebody else and current app owners simply does not know – if the app relies on ACS or not. So scream test – temporary switching off ACS might help owners to understand if the app uses ACS or not.
This might be your draft plan:
- schedule the first temporary 30 minutes ACS apps disablement ~3 months before EOL
- schedule the second temporary 2 hours ACS apps disablement ~2 months before EOL
- schedule the 3rd temporary 24 hours ACS apps disablement 6 weeks before EOL
- schedule the full (permanent) ACS apps disablement ~4 weeks before EOL
Be prepared to switch it back on if scream…
Amazing insights thanks so much