Azure Access Control Service retires on April 2, 2026, and that change can directly impact Microsoft 365 backup jobs that still rely on legacy authentication. If your Cohesity configuration for SharePoint, OneDrive, Teams, or Groups predates late 2024, now is the time to confirm upgrade readiness and complete migration to certificate-based authentication.
Microsoft is retiring Azure Access Control Service, or ACS, for Microsoft 365 on April 2, 2026. For many organizations, the risk is easy to miss because the issue is not limited to custom applications or older SharePoint add-ins. It also affects third-party platforms that are integrated with Microsoft 365 workloads using ACS as their authentication method.
That includes some backup and data protection solutions.
Cohesity is one of the Microsoft 365 data protection solutions we recommend and work with at eGroup, and it is among the platforms directly impacted by this retirement. If your organization is running Cohesity to protect Microsoft 365 workloads like SharePoint, OneDrive, Teams, or Groups, and those jobs were configured prior to 2024, this deadline warrants immediate attention.
Quick Takeaways
- Azure Access Control Service (ACS) retires April 2, 2026, and legacy authentication flows will stop working across Microsoft 365.
- Organizations with integrations configured before November 1, 2024 are most at risk, since ACS was already disabled for new tenants after that date.
- Backup platforms that relied on ACS may fail silently when the retirement occurs, stopping protection for workloads like SharePoint, OneDrive, Teams, and Groups.
- Cohesity customers should migrate to Certificate-Based Authentication (CBA) to maintain Microsoft 365 backup operations.
- Older Cohesity releases must upgrade first. Supported versions for migration include 7.1.2_u4+ and the 7.3 release family.
- Microsoft’s M365 Assessment Tool can identify ACS application principals and help determine whether your tenant still relies on ACS.
What Is Azure ACS, and Why Is Microsoft Retiring It?
Azure ACS is an older authentication framework that allowed third-party applications to access SharePoint Online data through application permissions and granular scopes. Over time, Microsoft has pushed organizations toward modern authentication through Microsoft Entra ID, and ACS has increasingly become a legacy dependency that does not align with that direction.
The retirement applies to all Microsoft 365 environments, including Government Clouds and Department of Defense tenants. Microsoft has been explicit that there will be no extension beyond April 2, 2026.
It is worth understanding who is at risk. ACS was already disabled for new tenants as of November 1, 2024, which means any solution configured after that point could not have used ACS-based authentication to begin with. The exposure sits with organizations that had ACS-dependent integrations in place before that date, where those configurations may still be active today. If your M365 protection jobs or third-party integrations were set up prior to 2024, this is the scenario to evaluate.
If you want to understand the full scope of ACS usage across your tenant, Microsoft provides a Microsoft 365 Assessment Tool that can scan your environment and identify all Azure ACS application principals, their permission scopes, and the sites they have access to. This is a practical starting point before addressing any specific integration or vendor remediation.


The Impact on Third-Party Solutions, Including Backup Platforms
Any solution that is integrated with Microsoft 365 using ACS for authentication will be affected when ACS is retired. This is not a flaw in those products. It is a byproduct of how they were designed to work within the authentication model Microsoft supported at the time. The responsibility for remediation now falls on both vendors and customers to complete the transition to modern authentication methods before the deadline.
Data protection platforms are a notable category here, since a disrupted authentication flow does not just mean a feature stops working. It means backups stop running entirely, without advance warning, once the cutoff hits.
Any backup or third-party platform that leveraged ACS for M365 integration faces the same requirement, and customers should confirm readiness with any vendor whose M365 integration predates 2024.
Cohesity and the Path to Certificate-Based Authentication
As a solution eGroup actively recommends for M365 data protection, Cohesity is one of the platforms we want to make sure our customers have a clear picture of. Cohesity has proactively published guidance and migration tooling to help customers move from ACS to Certificate-Based Authentication (CBA), which is the required replacement authentication method for M365 protection jobs covering SharePoint, OneDrive, Teams, and Groups.
The migration applies to both on-premises Cohesity environments and their cloud-based offering, Cloud Protect Service (CPS, also referred to as CCS).
On-Premises Cohesity Requirements
For on-premises environments, completing the migration to CBA requires running a supported software version. Customers on older releases, specifically 6.x, 7.1.2_u3 and earlier, or the 7.2.x branch will need to upgrade before CBA migration is possible. The minimum supported versions are 7.1.2_u4 and later within the 7.1.2 series, as well as the 7.3 release family. Cohesity’s latest GA release, 7.3.2, simplifies the process further since it does not require manual flag configuration before migration can begin. For customers already on a supported version, the migration path is well documented, and tooling is available through both CLI and a guided UI-based approach.
Cloud Protect Service (CPS/CCS) Migration Options
For Cloud Protect Service (CPS/CCS) customers, Cohesity offers two migration paths. An Express GUI method automates much of the process but requires global administrator credentials. For organizations that prefer not to grant that level of access, a Manual API method is also available. Cohesity has published documentation covering both approaches, and customers with an active support account can find version-specific KB articles, step-by-step video guides, and toolbox package update instructions directly within the Cohesity Support Portal.


What This Means If You Have Not Started Yet
With less than a month until the April 2 deadline, the window to act comfortably is narrow. For organizations that need both a software upgrade and a migration to CBA, that is a two-step process that requires planning, testing, and often change management approvals. None of those steps happens instantly, particularly in environments with complex protection policies, large data sets, or strict operational controls.
The risk of waiting is straightforward: on April 3rd, M365 backup jobs that rely on ACS-based authentication will begin failing silently, with no data being captured until the issue is resolved.
How eGroup Can Help
As a Cohesity partner, eGroup can help you quickly determine whether your Microsoft 365 backup environment is exposed to the ACS retirement timeline.
We can support teams that need to:
- Confirm whether existing Cohesity jobs are affected
- Review the current software version and upgrade readiness
- Plan and execute migration to certificate-based authentication
- Assess broader Microsoft 365 integration risk beyond the backup platform
- Prioritize remediation before the April 2 deadline
This is also a good opportunity to take a wider look across your tenant. Backup software may be the most urgent concern, but it is not necessarily the only one. Older third-party Microsoft 365 integrations can still carry hidden ACS dependencies that need attention before retirement day.
If you have not already validated your environment, now is the time.


Make Sure Your Microsoft 365 Backups Stay Protected
If your Cohesity or third-party Microsoft 365 integrations were configured before late 2024, now is the time to assess exposure, validate authentication, and plan remediation before ACS retirement.