SharePoint Online – Impact of ACS Policy Deprecation on Logic Apps using Username/Password Authentication

Hi Monika V

The Azure Access Control Services (ACS) retirement only impacts solutions that rely on ACS‑based authentication, such as classic SharePoint Add‑Ins or custom applications using Client ID / Client Secret (ACS app principals).

The built‑in SharePoint Online connector in Azure Logic Apps that authenticates using a username and password does not use ACS for authentication. Therefore, the ACS retirement does not directly affect this setup.

Because this integration is not using ACS‑based app‑only authentication, it should continue to function without changes after the ACS retirement.

While no immediate action is required, Microsoft’s long‑term recommendation is to avoid username/password authentication for unattended automation. For future‑proofing and improved security, consider migrating to:

• Managed Identity, where supported by the connector or scenario (Authenticate Connections with Managed Identities - Azure Logic Apps | Microsoft Learn), or
• Microsoft Entra ID App Registration with Microsoft Graph permissions for app‑based access

These approaches align with Microsoft’s modern authentication guidance and reduce reliance on user credentials.

I hope this information helps!

Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

ACS retirement only affects solutions that rely on Azure Access Control Services–based auth (classic SharePoint Add-Ins, low-trust provider-hosted add-ins, and custom apps using ACS-issued OAuth tokens).

The built-in SharePoint Online connector in Logic Apps that uses username/password does not use Azure ACS. It authenticates via modern Microsoft Entra ID–backed mechanisms, not via the SharePoint Online ACS trust that is being retired. Therefore:

• The ACS retirement does not directly impact a Logic App SharePoint connection configured with username/password.
• The fact that no Client ID/Client Secret (ACS add-in principal) is used is a strong indicator that this integration is not ACS-based and will continue to work beyond the ACS retirement timelines.

For future-proofing and alignment with current guidance:

1. Avoid any new dependencies on ACS or SharePoint Add-Ins
   • SharePoint Add-Ins and ACS are both retired in Microsoft 365 as of April 2nd, 2026.
   • Primary replacement for SharePoint extensibility is SharePoint Framework (SPFx), which is explicitly not impacted by these retirements.
2. Prefer Microsoft Entra ID–based app registrations for automation
   • Where possible, move away from username/password connections toward app-based auth (for example, Microsoft Entra applications with appropriate SharePoint permissions), as this is the recommended pattern for unattended access.
3. Validate that no hidden ACS dependencies exist
   • Ensure there are no SharePoint Add-Ins, provider-hosted add-ins, or custom apps in the solution that use ACS-issued tokens for SharePoint Online access. Those must be migrated to Microsoft Entra ID–based auth before April 2nd, 2026.
4. Follow the official ACS/Add-In retirement and migration guidance
   • Use the ACS retirement and SharePoint Add-In modernization guidance to assess any other integrations that might still be using ACS and plan their migration to Microsoft Entra ID and/or SPFx.

References:

• Azure ACS retirement in Microsoft 365
• FAQ - SharePoint Add-In and Azure ACS retirement in Microsoft 365
• Modernization guidance for existing SharePoint Add-In model implementations in Microsoft 365
• Access SharePoint from mobile and native device apps
• Creating SharePoint Add-ins that use low-trust authorization