Edge 157 Retires Direct WAM Sign-In: How to Test OneAuth Before the November Rollout

Microsoft's Beta Channel release notes put it plainly: Microsoft Edge plans to retire its legacy direct-WAM sign-in implementation on Windows in version 157, completing the transition to OneAuth. OneAuth continues to use Windows Web Account Manager (WAM) internally; WAM itself is not being deprecated. If a help desk ticket or vendor email claims "Microsoft is killing WAM," it has the story wrong.

What exactly is changing​

Until now, Edge on Windows could fetch identity tokens in two ways. It could call WAM directly, which is the legacy path, or it could go through OneAuth, Microsoft's shared authentication library, which then calls WAM itself. Edge 157 removes the first option.

According to Message Center notice MC1490911:

• Starting with Microsoft Edge version 157, all remaining profiles will transition directly to OneAuth authentication.
• The fallback legacy WAM path will default off under all circumstances.
• Most users will transition transparently. In rare cases, users may need to sign in to Microsoft Edge again.

The notice is tagged as a major change and a retirement with both user and admin impact, and it was published Oct 7, 2026 under the Microsoft 365 suite service.

Summary: the authentication library changes, Windows WAM stays, and the old fallback path is off with no exceptions.

Who is affected​

MC1490911 lists three groups:

• Organizations using Microsoft Edge on Windows.
• Users with Edge profiles that have not yet automatically migrated to OneAuth.
• Organizations that explicitly disabled OneAuth WAM using --disable-features=msOneAuthWAM.

The third group is the one to watch. If your organization launched Edge with --disable-features=msOneAuthWAM to work around an earlier sign-in problem, that workaround stops working in Edge 157. Any issue it was hiding will come back unless it has since been fixed. The other groups should see little change: Microsoft says the vast majority of users have already transitioned automatically with no interruption.

When it lands​

MC1490911 states that for General Availability (Worldwide, GCC): Rollout begins in early November 2026 and is expected to complete in early November 2026.

Microsoft's Edge release schedule gives more precise target dates for version 157:

Microsoft notes that these dates are approximate and depend on build status.

Extended Stable is worth a closer look. The same schedule has Edge 156 reaching Extended Stable in the week of October 22, 2026, and the next Extended Stable release is version 160, targeted for the week of January 7, 2027. My reading of the schedule, not anything Microsoft has stated: organizations on the 8-week Extended Stable cadence will probably meet this change when they move to 160 rather than in November. That gives them a little more time, but the remaining profiles still have to migrate.

The announcement has been in the Beta notes for a while. Microsoft added it under Version 155.0.4283.13: September 23, 2026 and repeated it under Version 156.0.4314.8: October 6, 2026.

Summary: Stable rollout targets early November, Beta testing can start around October 20, and Extended Stable shops probably meet the change at version 160.

Why Microsoft is doing this​

Microsoft says the move standardizes authentication flows across Microsoft 365 client applications, simplifies platform supportability, eliminates dual-stack authentication code paths, and provides improved diagnostic and recovery mechanisms.

Analysis: this is housekeeping, but useful housekeeping. Two token paths mean two sets of bugs, two sets of logs and plenty of "it works in Outlook but not in Edge" tickets. Moving Edge onto the same library as other Microsoft 365 clients should make sign-in behave more consistently across apps and give support teams one diagnostic path. The cost is the usual one for any consolidation: some environments that relied on the old path will need to be dealt with.

Microsoft hasn't given a figure for how many users will see a re-authentication prompt. "Rare" is its own description, so admins should treat it as an estimate.

How to find profiles still on the legacy path​

Microsoft recommends that admins identify unmigrated profiles and test the transition before Microsoft Edge version 157 reaches their environment. To check a single profile:

1. Open Edge and go to edge://signin-internals.
2. Find Edge Auth Library Information, then Library.
3. Read the value:
   • If OneAuth is displayed, the profile is already using the modern path and no action is required.
   • If WAM is displayed, the profile is still using the legacy path.

This is a per-profile check. Microsoft hasn't published a fleet-wide report or policy that shows this value centrally, so spot-check a representative sample: different hardware, different sign-in setups (Entra-joined, hybrid-joined, personal Microsoft accounts on work devices) and any machine where someone once applied the opt-out flag.

How to pilot the change early​

You can force the new behavior on test machines before Edge 157 arrives. On pilot test devices running Microsoft Edge version 155 or later, admins can test the transition before version 157 by launching Edge with this force flag:

msedge.exe --enable-features=msForceOneAuthWAM

Then:

1. Return to edge://signin-internals and confirm the Library value now reads OneAuth.
2. Check browser sign-in, Single Sign-On and account sync. MC1490911 says to confirm that all three work as expected.
3. Pay particular attention to profiles where the transition was previously disabled. The Beta notes say organizations wishing to validate early or test profiles that previously disabled the transition can test with --enable-features=msForceOneAuthWAM.
4. Report problems before the cutover. Microsoft advises admins to report any sign-in issues to Microsoft Support prior to the Microsoft Edge 157 release.

The force flag is for testing only. In production, the switch should happen on its own as devices update to 157.

Summary: check the Library value, force OneAuth on a pilot group running Edge 155 or later, confirm sign-in, SSO and sync, and report issues before November.

What to tell the help desk​

Warn your support staff now. MC1490911 says to tell support teams that a small number of users may see a sign-in action on the Edge profile menu after updating to version 157. In most cases the fix is simply to sign in again.

If signing in again doesn't work, Microsoft gives this command for collecting OneAuth diagnostic logs:

msedge.exe --enable-features=msForceOneAuthWAM --enable-logging -v=1 --oneauth-log-level=5

The log file goes to:

%LOCALAPPDATA%\Microsoft\Edge\User Data\chrome_debug.log

A practical triage sequence:

1. Ask whether the user sees a sign-in prompt on the profile menu. If so, have them sign in again.
2. If that fails, check edge://signin-internals to see which library is in use.
3. Reproduce the problem with the logging command above and collect chrome_debug.log.
4. Escalate to Microsoft Support with the log attached.

Review your sign-in policies​

Admins should also look at the Group Policy objects that control Edge sign-in. Microsoft's current Edge policy documentation lists OneAuthAuthenticationEnforced | OneAuth Authentication Flow Enforced for signin (deprecated) as a deprecated policy. Historically, when that policy was disabled or not configured, the sign-in process uses Windows Account Manager.

My inference, which Microsoft hasn't spelled out for this retirement: that "disabled" setting chose a sign-in path that Edge 157 no longer offers, so don't expect it to keep anyone on the old behavior. Remove it during your next policy cleanup, both to keep your baseline tidy and so nobody later assumes it still does something.

The policy page reports no new policies for Edge 157 itself: There are no new policies in Microsoft Edge version 157. Asked whether the change can be controlled through admin settings or Entra ID group membership, MC1490911 says only that admins can validate and manage the transition through Microsoft Edge configuration and feature flags. Review your Microsoft Edge deployment and policy management practices for group-based rollout controls. In other words, there's no dedicated policy to keep the legacy path. Your control is the pilot testing you do before the update lands.

The bottom line​

Most Windows users won't notice anything, because their profiles moved to OneAuth some time ago. The admins who need to act are the ones whose environments still have WAM profiles, and above all those who once switched off OneAuth WAM with a command-line flag. For them, the remaining weeks before Stable are the time to test.

A short checklist before early November:

• Spot-check edge://signin-internals across representative devices.
• Find and retire any --disable-features=msOneAuthWAM workarounds.
• Pilot --enable-features=msForceOneAuthWAM on Edge 155 or later and confirm sign-in, SSO and sync.
• Brief the help desk on possible re-authentication prompts and the logging command.
• Review leftover sign-in policies such as OneAuthAuthenticationEnforced.
• If you're on Extended Stable, schedule the same checks ahead of your move to version 160.

WAM stays, the legacy direct-WAM path goes, and organizations that test now should avoid a rush of sign-in tickets in November.