Microsoft To Enforce WAM for Delegated Interactive Graph Sessions

Change to Use WAM for Interactive Graph Sessions Might Impact Operational Procedures

I suspect that few Microsoft 365 tenant administrators take the time to browse the latest contents of the GitHub issues page for the Microsoft Graph PowerShell SDK GitHub. It’s an esoteric pursuit that can turn up interesting nuggets even when you don’t want to report a problem to Microsoft.

Such is the case with issue #3629 “Delegated Authentication changes.”  Leaving aside the question whether Microsoft should make important announcements about changes in a GitHub issue, let’s review what’s happening.

Many administrators use the Microsoft Graph Command Line Tools enterprise application to authenticate interactive sessions that use delegated permissions. Interactive sessions benefit from being able to use any delegated permission held by the Microsoft Graph Command Line Tools app. However, the sheer number of permissions that accumulate can be a problem. Even so, being able to sign in to run cmdlets to execute Graph requests and run scripts in an interactive session is very useful.

The Graph SDK and Web Account Manager

In December 2025, version 2.34 (quickly followed by V2.34.1) of the Microsoft Graph PowerShell SDK made the Web Account Manager (WAM) the default authentication mechanism for interactive accounts. At the time, the cited reason for the change was to achieve better security.

For much the same reason, recent updates for other Microsoft 365 PowerShell modules such as Microsoft Teams V7.9 and Exchange Online Management V3.10 also implement WAM as their authentication broker. Modules that support WAM use it to interact with MSAL, the Microsoft Identity Client, to acquire tokens from Entra ID. Using common components to perform tasks is a reasonable thing to do from a software engineering perspective, and it makes sense for the Microsoft 365 PowerShell modules to adopt the same approach to authentication and token acquisition.

Unhappily, the engineering groups chose different versions of MSAL for their implementations (issue #3576), which perpetuates an ongoing problem of assembly clashes that Microsoft 365 PowerShell modules have had for nearly two years. The problem means that it’s much harder to run the modules together in the same interactive session. To avoid problems, I now use app-only authentication when I need to use Exchange Online management alongside the Microsoft Graph PowerShell SDK.

The Effect of Enforcing WAM

Microsoft says that in an upcoming change to the way that interactive sessions using the Microsoft Graph Command Line Tools app work, SDK “versions prior to v2.36.1 will no longer be able to use delegated authentication except when using WAM. They also state that tenants should “upgrade to V2.37.0 or higher” (the current version is V2.39, released on 3 August 2026 – Figure 1).

Importantly, this appears to be a service-side enforcement rather than a change in SDK code. Simply remaining using an older SDK version on a workstation will not preserve browser-based authentication.

Microsoft acknowledges that some tenant administrators dislike the change to WAM and prefer to run older versions of the SDK to continue using the browser-based authentication mechanism. For example, they might use different administrative accounts for different tasks and dislike like the way that WAM can select an account used in a Windows session and use it to authenticate. The browser mechanism is clearer because it forces an explicit account selection and authentication.

With the upcoming change, administrators might have to change how they work. As noted above, I’ve moved to app-only authentication to allow me to run multiple Microsoft 365 modules in a session. App-only authentication is unaffected by the change.

Likewise, if you use a tenant-specific registered app to run interactive Graph SDK sessions, you’re unaffected by the change. Using one or more registered apps to allow different teams to run interactive Graph sessions with different sets of permissions is a good approach in many circumstances. Using registered apps for SDK sessions also solves the problem of permission creep.

Time to Prepare

Microsoft hasn’t said when the change will take effect, but the GitHub notice makes it clear that browser-based delegated authentication with the Microsoft Graph Command Line Tools application should be considered a temporary option. Organizations that still depend on that approach should review operational procedures now and determine whether WAM or tenant-specific app registrations are the better long-term solution.

---

Need help to write and manage PowerShell scripts for Microsoft 365, including Azure Automation runbooks? Get a copy of the Automating Microsoft 365 with PowerShell eBook, available standalone or as part of the Microsoft 365 for IT Pros eBook bundle.