Security update causes new problem for Windows Hello for Business authentication

A fix introduced into Windows last month to close a weakness in Kerberos authentication is causing logon failures for some Windows Hello for Business (WHfB) users, Microsoft has warned.

In theory, the monthly Windows patching cycle is about fixing vulnerabilities, of which CVE-2025-26647, the flaw addressed by the buggy fix, was serious enough to warrant immediate attention.

But Windows environments are varied, and exceptions arise, especially in relation to the complex subject of authentication. In some cases, the fix for a vulnerability can cause new problems that Microsoft only detects when customers shout about them.

The latter seems to have been the case with the latest issue, which affects all versions of Windows Server going back to Windows Server 2016 that were patched by the April 8, 2025 Windows security update (KB5055523).

“Active Directory Domain Controllers (DC) might experience issues when processing Kerberos logons or delegations using certificate-based credentials that rely on key trust via the Active Directory msds-KeyCredentialLink field,” said Microsoft.

“This can result in authentication issues in Windows Hello for Business (WHfB) Key Trust environments or environments that have deployed Device Public Key Authentication (also known as Machine PKINIT),” the alert added.

Home users won’t experience this issue, as DCs are only employed for authentication in business or enterprise environments, including their VPNs.

What this means

The issue the buggy patch was meant to address was an inconsistency in the way Windows was storing Kerberos certificates.

The patched version should only have trusted certificates stored in the Windows NTAuth store used specifically for security-critical certificates such as Windows Hello for Business biometrics, smart cards, or PKINIT used by machines or devices that don’t use conventional passwords.

Unfortunately, it still allowed authentication for privileged accounts in a separate space called the root store, normally used for more general authentication such as websites.

That was a bad idea, so the April update enforced use of certificates in the NTAuth store by Windows DCs.

However, this caused some WHfB or machine PKINIT logons still connected to the original root store either to fail or to generate excessive log traffic.

“It’s possible other products which rely on this feature are also affected, including smart card authentication products, third-party single sign-on (SSO) solutions, and identity management systems,” said Microsoft.

So, not every user is impacted by any means, but enough to generate time-consuming support calls in some organizations, and that’s on top of any problems created with machine-to-machine authentication.

Microsoft recommendations

“User impact only occurs when registry key AllowNtAuthPolicyBypass is set to a value of ‘2’. To prevent the resulting logon failures, temporarily revert AllowNtAuthPolicyBypass from ‘2’ to ‘1’ as documented in the Registry Settings section of KB5057784,” Microsoft’s advisory offered as a workaround.

Beyond that, “Microsoft is aware of this issue. We are working on a solution and will provide an update as soon as possible,” the company said.

Enough already

Unintended update problems are something Windows admins will be used to by now. Unfortunately, this time these also included a separate issue affecting some Windows Hello logins that was caused by the same April security update. And judging from the list on the current known issues and notifications page, these are not alone.

Does Microsoft test its patches before shipping them? Yes, of course it does. But the OS and its use cases are now sprawling, and testing for every environment has become more difficult over time. Occasional glitches now seem like the inevitable consequence of this complexity.