I see the same thing in almost every Entra tenant I look at. There are ancient service principals in there, left behind by tools or integrations nobody remembers. The "Azure AD Graph retirement" has been hanging over us for years, but the updated deadline Microsoft published in August 2024 makes it feel real. There is now a concrete date, and critical apps can break if you do nothing.

The Azure AD Graph retirement follows two key dates in 2025

Since Microsoft's announcement in August 2024, the countdown has started. From 1 February 2025, an app can only call the Azure AD Graph API if it has been explicitly configured for extended access (authenticationBehaviors → blockAzureADGraphAccess = false). Calls from every other app will be blocked. Full retirement follows later in 2025 and cuts off all access, with no exceptions. This doesn't only affect old in-house scripts. Older third-party products are at risk too, and some of them are still in essential use. In my experience, these things tend to fail at exactly the wrong moment.

Affected apps show up in recommendations and API permissions

Start by getting visibility. Microsoft helps a little here: in the Entra admin center, under Overview → Recommendations, there is a recommendation that lists service principals still using the Azure AD Graph APIs. It's a good place to begin, but it doesn't replace a proper review. That applies especially to apps that sit idle most of the year and only run on specific, business-critical occasions.

Next, check the API permissions on your app registrations. If you find permissions for Azure Active Directory Graph (for example, "Directory.Read.All"), you have work ahead of you. Old automations, PowerShell modules and custom code can be affected as well, particularly anything that was never moved to Microsoft Graph.

Practical tip: In my projects I always filter app registrations for "Azure Active Directory Graph" permissions and don't rely on last sign-in time alone. That's how the obscure integrations turn up, the ones that only run during payroll or the annual audit.

PowerShell gives you a quick list (PowerShell 7 with the Microsoft.Graph module, Application Administrator role):

Get-MgApplication -All | Where-Object {
    $_.RequiredResourceAccess.ResourceAppId -contains '00000002-0000-0000-c000-000000000000'
} | Select-Object DisplayName, AppId

The output shows every app registration that references the old Azure AD Graph API (AppId: 00000002-0000-0000-c000-000000000000).

Migrating to Microsoft Graph takes more than swapping endpoints

Finding the legacy apps is only the start. For in-house solutions, the code has to be migrated to Microsoft Graph, and that is rarely a matter of replacing a URL. Microsoft Graph differs in structure and semantics. Endpoints have new names, return types often change, and authentication may need adjusting. Microsoft covers the details and the migration steps in the official migration guide, and the documentation on the Entra admin recommendation is useful as well.

Third-party apps are harder. If the vendor doesn't ship an update, or no longer exists, your options are to disable the integration or replace it. In rare cases you can buy some time by enabling extended access through the authenticationBehaviors property. Treat that as a stopgap, though, because nothing will work once full retirement arrives later in 2025.

One thing that trips people up regularly is that Microsoft Graph permissions are more granular than those of the old API. Many roles and scopes need a careful review, above all when legacy apps depended on broad "Directory" permissions. Microsoft has an overview of supported authentication and permission behaviors.

Extended access buys time but does not solve the problem

Then there's the new exception. From February 2025, apps with blockAzureADGraphAccess = false may keep calling Azure AD Graph for a while. You set this on the app registration, either in the Entra admin center or with PowerShell. It gives admins one last window to migrate, but it isn't a long-term fix. When full retirement comes, these apps will break too. If you set the flag just to make the warnings go away, you're setting yourself up for trouble.

The flowchart below shows how the phases fit together:

flowchart TD
    Start["From Feb 2025?"] --> CheckBehavior["blockAzureADGraphAccess = false?"]
    CheckBehavior -- "Yes" --> AllowAccess["Azure AD Graph access allowed"]
    CheckBehavior -- "No" --> BlockAccess["Azure AD Graph access blocked"]
    AllowAccess --> Shutdown["Full retirement later 2025"]
    BlockAccess --> Shutdown
    Shutdown --> End["All access permanently blocked"]

Figure: Access to Azure AD Graph after February 2025, by setting

I recommend investigating your tenant now instead of postponing

In most tenants, the Azure AD Graph retirement will be messier than management expects. I keep running into integrations that nobody has touched or documented in years, and nobody can say for sure what breaks when they stop working. Review your app registrations and plan the migrations now, and you'll spare yourself (and the business) a few frantic weekends. Microsoft isn't leaving much room for anyone who waits this time.

If you're already modernising other areas (moving to the new Teams client, for example, see /blog/new-microsoft-teams-client-migration), put this migration on the same project list. Dealing with dependencies together hurts a lot less than scrambling after an outage.