I built and maintain this module and this is the first time I am posting about it anywhere, so treat it as an introduction, not a changelog.

Why it exists

• Microsoft.Graph v2.34.0 (December 2025) made the WAM broker mandatory for interactive sign-in on Windows. It shipped with a single line in the release notes. The fallout is documented in msgraph-sdk-powershell #3481: separate admin accounts not signed into the device, run-as-other-user scenarios, and GDAP multi-tenant sign-ins all got worse or broke.
• The opt-out Microsoft added (Set-MgGraphOption -DisableLoginByWAM $true, v2.35.1+) only takes effect with your own app registration. With the built-in client ID, WAM stays mandatory; the official docs now state it cannot be disabled. The maintainers describe even that opt-out as temporary.
• More change is coming: in #3629 Microsoft announced it will modify the default application used for delegated auth, and that SDK versions before 2.36.1 "will no longer be able to use delegated authentication except when using WAM." So pinning 2.33.0, which many teams do today, is not a durable workaround.
• On top of that, the MSAL dependency now conflicts with ExchangeOnlineManagement in the same session on 2.36.0+ (#3576, still open).

I wanted interactive, browser-based, WAM-free sign-in on Windows that does not depend on what Microsoft does with their default app next. So I implemented the Connect-MgGraph sign-in flows as plain PowerShell against the identity platform v2 endpoints.

What it is

• A drop-in: Connect-MgGraphCommunity supports the same flows (interactive PKCE with loopback redirect, device code, client secret, certificate by object/thumbprint/name, access token, managed identity). The only SDK flow not implemented is -EnvironmentVariable.
• After sign-in it hands the token to Connect-MgGraph -AccessToken if Microsoft.Graph.Authentication is installed, so your existing Get-MgUser / Invoke-MgGraphRequest scripts keep working unchanged.
• It also calls Graph on its own (Invoke-MgGraphCommunityRequest, $batch helper, pagination, binary upload/download), so no Microsoft.Graph.* module is required at all if you do not want one.
• Because there is no MSAL assembly, it loads alongside ExchangeOnlineManagement without conflicts.
• For the #3629 situation specifically: New-MgGraphCommunityAppRegistration -SetAsDefault creates a public client app in your tenant (loopback redirect, no pre-configured permissions, dynamic consent) and persists it as your default, so your sign-ins stop depending on Microsoft's default app entirely.
• Recent additions for parity with the official SDK: Continuous Access Evaluation (CP1 capability, roughly 24h revocable tokens, automatic claims-challenge retry, verified against a real tenant) and the new sovereign cloud environments (Bleu, Delos, GovSG; endpoints mirrored from SDK source, not live-tested by me).

Trust questions, answered upfront

• MIT licensed, entirely open source: https://github.com/ugurkocde/MgGraphCommunity
• Pure PowerShell, no compiled code, no telemetry, no network calls except to Microsoft's identity and Graph endpoints. It is a few thousand lines you can actually read before pointing it at a tenant.
• Only the delegated scopes you pass are requested; nothing is pre-consented. The app-registration helper needs delegated Application.ReadWrite.All only when you run it.
• Tokens stay in memory by default. Disk persistence is opt-in (-PersistRefreshToken): DPAPI-encrypted on Windows, chmod 600 elsewhere, refresh token only, access tokens never touch disk.
• Windows PowerShell 5.1 and PowerShell 7+, tested in CI on Windows, macOS and Linux.

Current limitations

• No typed cmdlets per endpoint; you either use relative Graph URIs or keep the official SDK installed on top for those.
• -EnvironmentVariable flow is missing.
• CAE covers delegated flows only.
• It is a young community module. The official SDK has years of development behind it; this has months. Read the code, that is what it is there for.

Install: Install-Module MgGraphCommunity -Scope CurrentUser

If you run Intune automation day to day, the two places I would most value pushback are the sign-in scenarios that still hurt on the official SDK (run-as-other-account, GDAP, or something I have not covered) and any safeguard you would consider mandatory before trusting a community auth module with an admin account.