Repository navigation
WAM authentication issues with non-signed in windows account #3617
Description
Describe the bug
When running an iterative script, that runs cmdlets repeatedly against a large array of users/groups, I am repeatedly prompted to re-auth. The WAM window keeps appearing and asking which account I'm trying to sign in as.
Example Script:
Users = @(Array of 50 users)
ForEach (User in Users)
(
Get-MgUser -UserId $member -Property Id,UserPrincipalName,Department
)
Observations:
- repeat auth windows every 3/4 users iterated
- commands is noticeably slower to complete (3 seconds compared to .1 seconds in non-WAM authenticated session)
- I am signed into windows with a productivity account and authenticating to Graph with a separate administrative account
If I downgrade to Graph 2.33, it reverts back to Browser Signin and scripts run fine/normally with no re-auth/slowness
Expected behavior
Authenticate one time when connecting to Graph. Graph cmdlets run at normal, non-WAM authentication speed.
How to reproduce
update to 2.34+ Graph versions that enforce WAM authentication.
SDK Version
2.34+
Latest version known to work for scenario above?
2.33
Known Workarounds
No response
Debug output
Click to expand log
```</details>
### Configuration
_No response_
### Other information
_No response_
Activity
ramsessanchez commentedon May 18, 2026
insertacoolnamehere This is due to the security protocols implemented by WAM. At the moment there are no plans to remove WAM enablement, however, it is also possible this may be due to a token cache issue that was recently fixed in 2.37.0.
-DisableWAMForMSGraph $true -ClientId <id>This way you will be able to bypass the enforcement of WAM and continue as you were before. This is the recommended path moving forward. Downgrading to a previous version will not work moving forward as we expect versions <2.36.1 to break in the near future.insertacoolnamehere commentedon May 18, 2026
The same behaviour occurs with 2.37.0
For large organisations, creating an app for each tech is painful.
Why can't WAM be bypassed going forward?
We have 300k users in our tenant, large iterative scripts to traverse thousands of accounts are used every day - how is WAM able to be mandated when this is a known effect?
ramsessanchez commentedon May 19, 2026
For security purposes, WAM is mandated, in particular, for the public application that is used by default when using Connect-MgGraph as it is hosted on the Microsoft tenant. When using your own application you may chose to bypass WAM, hence the recommended path of creating a custom application within your tenant. While we cannot remove customers from the public application, we can add security checkpoints to ensure security. See docs/authentication.md for more information on steps to create a custom application.
microsoft-github-policy-service commentedon May 23, 2026
This issue has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for 4 days. It will be closed if no further activity occurs within 3 days of this comment.
nkasco commentedon Jul 27, 2026
This issue should definitely be reopened, this is a major pain point and I'm struggling to understand why the subsequent auth prompts with delegated permissions is continually ignored.
I've asked around the community, this is not unique to insertacoolnamehere environment. I can confirm we see the multiple auth prompts too in a large enterprise, and I've confirmed it in my own dev tenant. The double auth issue was going on even prior to making WAM the default UX, and is extremely painful. Many groups of users are using old module versions to workaround things, so if you're saying those versions will break at some point it needs to be strongly communicated and simultaneously this module requires various bug fixes to allow users to upgrade with confidence.
Slowness wise, if WAM is that much slower, offering an alternative in this module (i.e. using your own delegated App Registration) is an appreciated workaround from the Graph Module team, but really we need representation to get the feedback to the proper product team internally. It is far too painful to open standalone cases and get sent through the wringer.
Ramses Sanchez-Hernandez (@ramsessanchez) Gavin Barron (@gavinbarron)