Azure AD Graph API retirement: action required for older versions of Azure CLI and Azure PowerShell

Summary

Azure AD Graph API (the legacy graph.windows.net API, not to be confused with Microsoft Graph) entered its retirement process in September 2024, with the general shutdown completed on July 1, 2025. Azure CLI and Azure PowerShell completed their migration away from Azure AD Graph well ahead of that deadline. az ad and the Az module’s Microsoft Entra ID (Azure AD) cmdlets have been backed by Microsoft Graph for some time now. If you’re running a current version of Azure CLI or Azure PowerShell, no action is required on your part for this specific retirement.

Because Azure CLI and Azure PowerShell are Microsoft first-party clients, their Azure AD Graph application identities have remained available temporarily to provide a transition path for legacy releases that still call Azure AD Graph. However, those legacy releases have long been out of maintenance and are no longer supported; the temporary availability of the application identities does not mean the old releases remain supported.

Beginning after October 6, 2026, the Microsoft Entra team will progressively disable this remaining legacy access over a two-month buffer period. Users of current versions are not affected, but anyone still running an old release should upgrade now. This post explains what changed, why, and how to confirm you’re unaffected.

Terminology

This post uses the following terms:

Azure AD Graph API (https://graph.windows.net) — the legacy, now-retired API for reading and writing Microsoft Entra ID (formerly Azure Active Directory) objects: users, groups, applications, service principals, and directory roles.

Microsoft Graph (https://graph.microsoft.com) — Microsoft’s current, unified API surface for Entra ID and the broader Microsoft 365 ecosystem, and the only supported path going forward for any identity/directory operation.

If your Azure CLI or Azure PowerShell still uses legacy Azure AD Graph, migrate as soon as possible

Azure CLI has used Microsoft Graph for az ad commands since version 2.37.0, and the identity-related cmdlets in Azure PowerShell have used Microsoft Graph since Az.Resources version 5.1.0. These migrations were completed years before the Azure AD Graph retirement.

Azure CLI releases earlier than 2.37.0 and Az.Resources releases earlier than 5.1.0 have long been out of maintenance and are no longer supported. The temporary availability of the tools’ first-party Azure AD Graph application identities was retained only to provide a transition path for those legacy releases; it does not mean that the releases are maintained or supported.

We are notifying users who still use legacy Azure AD Graph versions

We are sending notifications in phases to tenants where telemetry indicates that calls may still be reaching Azure AD Graph endpoints. Some of this traffic comes from legacy Azure CLI or Azure PowerShell releases using the tools’ temporarily retained first-party Azure AD Graph identities; other cases typically trace back to one of the following:

An old, unsupported version of Azure CLI or the Az/AzureAD/MSOnline PowerShell modules still in use (for example, pinned in a long-lived CI/CD image or automation runbook that hadn’t been updated).

Custom scripts or tooling calling the legacy graph.windows.net endpoint directly via Invoke-RestMethod/curl/a hand-rolled SDK client, independent of az/Az entirely.

The standalone legacy AzureAD or MSOnline PowerShell modules (distinct from the Az module), which were already deprecated separately from this effort and have their own migration path to Microsoft.Graph PowerShell cmdlets.

These notifications are intended to help close out any remaining migration gaps and continue the original retirement communication. Beginning after October 6, 2026, the Microsoft Entra team will progressively disable the remaining legacy first-party access over a two-month buffer period. Old Azure CLI or Azure PowerShell releases that still depend on Azure AD Graph may stop working at any point during this phased shutdown.

How to check whether your automation still uses Azure AD Graph

Checking the version actually running in each environment is the most reliable way to identify legacy Azure CLI or Azure PowerShell usage. Check developer machines as well as CI/CD agents, automation runbooks, scheduled jobs, and container images, which often remain pinned to an older version after interactive environments have been updated.

You may need to work with your tenant, subscription, infrastructure, or automation administrators to locate the system that is generating the legacy traffic. The source may be a developer machine, VM, self-hosted build agent, automation worker, scheduled task, or container host that you do not manage directly. Use the tenant information from any targeted notification together with your organization’s sign-in logs, automation inventory, pipeline logs, and VM or container inventory to identify the execution environment, then upgrade it or stop the obsolete job.

Azure CLI

Run the following command in the same environment and execution account used by your automation:

az version

Azure CLI 2.37.0 replaced the Azure AD Graph implementation used by az ad with Microsoft Graph. If the reported version is lower than 2.37.0, upgrade to the latest Azure CLI release and test your scripts before the phased shutdown begins. Also check pipeline definitions, package installation steps, and container image tags for an explicitly pinned Azure CLI version; checking only the version on your local workstation does not verify the version used by automation.

For installations that support the built-in updater, run:

az upgrade

Otherwise, update Azure CLI through the same package manager or installation method originally used, then run the version check again.

After upgrading, review the documented Microsoft Graph migration changes because some command arguments, behavior, and output properties changed. For example, Microsoft Graph directory object output uses id, while the corresponding Azure AD Graph property was objectId. This can affect scripts that parse command output. If you encounter a problem after upgrading, report it in the Azure CLI GitHub repository and include the output of az version, the affected command, and a minimal reproduction with secrets removed.

Azure PowerShell

The Entra ID cmdlets discussed in this post are provided by Az.Resources, so check that module’s version rather than relying only on the version of PowerShell itself:

Get-Module Az.Resources -ListAvailable | Sort-Object Version -Descending | Select-Object -First 1 Name, Version, Path

Az.Resources 5.1.0 introduced the Microsoft Graph implementation for the identity-related cmdlets. If the reported version is lower than 5.1.0, update to the latest Az module, restart the PowerShell session, and test your scripts. Check automation accounts, hosted agents, module caches, and container images separately. Also look for scripts that load a specific old version with Import-Module Az.Resources -RequiredVersion or declare a fixed module version in #Requires.

If Az was installed from the PowerShell Gallery, update it with:

Update-Module -Name Az -Force

Restart PowerShell after the update so that the session does not continue using an older module already loaded in memory.

To confirm which module version provides a cmdlet in the current session, run:

(Get-Command Get-AzADUser).Module | Select-Object Name, Version, Path

After upgrading, review the documented Azure PowerShell migration changes because parameter names, input and output types, and object properties changed. If you encounter a problem after upgrading, report it in the Azure PowerShell GitHub repository and include the Az.Resources version, PowerShell version, affected cmdlet, and a minimal reproduction with secrets removed.

Check for direct endpoint calls

Tool versions do not identify custom code that bypasses az ad or the Az cmdlets. Search your repositories, pipeline definitions, runbooks, and configuration files for graph.windows.net. Pay particular attention to calls made through az rest, curl, Invoke-RestMethod, or custom HTTP and SDK clients. Any direct call to that host must be migrated to Microsoft Graph regardless of the installed Azure CLI or Azure PowerShell version.

If you need help upgrading, locating the source of Azure AD Graph traffic, or troubleshooting an issue related to the retirement, you can ask a question in the Azure CLI GitHub repository or the Azure PowerShell GitHub repository, as appropriate. Include the available version information, affected command or cmdlet, execution environment, error message, and a minimal reproduction or relevant logs with all secrets and personal or tenant-sensitive information removed. The Azure CLI and Azure PowerShell teams can then help you investigate and provide guidance.

What you should do

Make sure you’re on a current, supported version of Azure CLI or Azure PowerShell. Run the checks above and update if you’re on an old release. Do not rely on the two-month buffer period: legacy access will be progressively disabled after October 6, 2026, so an old release may stop working before the end of that period.

If you use the standalone legacy AzureAD or MSOnline PowerShell modules, these are a separate deprecation track from Az and need their own migration to the Microsoft.Graph PowerShell SDK. This is not something updating the Az module alone resolves — see the dedicated migration guidance referenced below.

If you have custom code or scripts calling graph.windows.net directly, those calls will fail outright post-retirement regardless of what version of Azure CLI/PowerShell you run, since this isn’t a CLI/PowerShell-specific concern — it’s any direct caller of the retired endpoint. Migrate those calls to the Microsoft Graph SDK/API directly.

If you received a targeted notification referencing a specific tenant ID, that means telemetry showed residual traffic from that tenant specifically — check any automation, scheduled scripts, or older images/containers associated with that tenant for one of the causes above.