KB5077181: Unable to switch between logged-in users when using UPN

Question

Background

We are experiencing problems when end users try to switch between logged-in users on computers shared by multiple people. This issue started after KB5077181 was automatically installed.

This document describes a lab configuration and test where the issue has been reproduced.

Note: KB5077181 has since been superseded by the March update, however the issue persists.
Note: By uninstalling KB5077181 the issue was resolved, but not possible after March update.

---

Lab Setup and Configuration

Infrastructure

• Created a dedicated VLAN on the firewall with internet access only
• Installed Windows Server 2019 from the latest Microsoft ISO
• Applied all available security and feature updates
• Installed and configured DHCP and DNS services
• Promoted the server to a domain controller and created a new forest: lab.company.no
• Added company.no as an alternative UPN suffix in Active Directory Domains and Trusts
• No GPO modifications — all settings left at defaults

Client Machines

• CLIENT1: Windows 11 25H2, all updates applied
• CLIENT2: Windows 11 24H1, updated to 25H2 via Windows Update
• Both clients joined to the domain

Test Accounts

User	UPN	Password
USER1	******@company.no	Ends with 1
USER2	******@company.no	Ends with 2
USER3	******@company.no	Ends with 3

---

Login Sequence

1. Logged in as ******@company.no → locked the computer
2. Selected Other User, logged in as ******@company.no → locked the computer
3. Selected Other User, logged in as ******@company.no → locked the computer

---

Reproducing the Issue

******@company.no is the last logged-in user. Attempting to switch to another logged-in user via the lock screen:

1. Selected ******@company.no from the user list
2. Entered the correct password for user1

Result: Authentication fails with "Incorrect password"

Entering the password for ******@company.no instead succeeds, regardless of which user is selected from the list.

---

Additional Findings

When the same test is repeated using sAMAccountName for all three logins, switching between users works as expected. The issue is specific to UPN-based logins.

---

Visual Confirmation

By setting the following registry value:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\DontDisplayLockedUserId = 1

The UPN is displayed beneath each user on the lock screen. As shown in the screenshot below, the UPN is incorrect for all users — every account shows the UPN of the last signed-in user.

In this example, both Kari Båts and Eirik Cor* are displaying each other's UPN, confirming that the system has overwritten the UPN reference for all sessions with that of the most recently logged-in user.*

Answer 1

Hi Stian Kvia,

From what you’ve described, the problem started after KB5077181 and persists even with the March update, specifically when using UPN logins on shared computers. The key detail is that the lock screen is incorrectly displaying the UPN of the last signed‑in user for all accounts, which explains why authentication fails unless you enter the last user’s password. This is a bug in how Windows is handling cached UPN references during fast user switching.

You’ve already confirmed that using sAMAccountName works as expected, which means the underlying domain authentication is fine. The issue is isolated to UPN display and mapping logic introduced in recent updates. At this point, the recommended workaround is either to continue using sAMAccountName for logins or to enforce the registry setting that hides locked user IDs, so users always select “Other User” and type their full UPN manually. This avoids the incorrect cached UPN being reused.

Fixes are typically rolled into cumulative updates once validated. Keeping your domain controllers and clients fully patched is important, but until a fix is released, the safest approach is to avoid relying on cached UPNs at the lock screen. For environments where UPN logins are mandatory, you may want to open a formal support case so the product team can track your scenario.

I hope the response provided some helpful insight. If it addressed your issue, please consider marking it as Accept Answer so others facing the same problem can easily find the solution. If you need any further assistance, feel free to leave a comment.

Jason.

Answer 2

We are also running into this same issue and are also able to reproduce it. We are able to verify that it only started happening after we mass updated our computers to 25H2. We are debating hiding the last logged in user via registry/gpo, however, fixing this would be most ideal.

Answer 3

Hi Stian Kvia,

I’m following up to check whether the issue has been resolved. Feel free to reply if you need further information. If the information provided was helpful, please click "Accept Answer" to help others in the community. Thank you!