VPN Sign-In Rejected: Check the Build Before the Registry
A missing registry value can be enforcing its own default after an update. Read the build level, the effective policy and one matching event first.
Sign-in is rejected on a machine where nobody edited the registry, and the forum answer says to add a value that is not there. Absence is not the finding. Windows applies defaults, a default can change with an installed update, and the effective policy on the device can therefore be stricter than the registry suggests.
Start With the Error the Client Actually Showed
Read the message rather than the summary that reached you second-hand. A prompt that returns immediately, a timeout after the tunnel forms, and a failure that appears only when the connection tries to reuse the logged-on account are three different situations. Only the third one involves single sign-on at all, and the first two will not be fixed by anything in this article.
The layer that made the decision decides which log answers it. These four observations point at four different owners:
| What you observe | Where the decision was made | Who owns the fix |
|---|---|---|
| The prompt returns before the tunnel forms | Local credential handling on the client | Device policy or the installed build |
| Authentication succeeds, no internal site loads | Routing or access control after login | The gateway or network owner |
| Fails only when the logged-on account is reused | SSO credential generation | The policy boundary this page covers |
| Every user on one build fails | Update level or vendor regression | Patch management |
Write the exact text, the minute and the account context into the ticket. Whether the attempt was interactive or automatic decides which Windows component made the call, and a report that says the VPN is broken often turns out to describe a missing internal website rather than a rejected credential.
Read the Effective Policy, Not the Missing Value
Establish the build and update level first, because the default for NTLMv1-derived credential generation changed in the listed Windows 11 and Windows Server 2025 releases. With Credential Guard off and BlockNtlmv1SSO unset, an update released on or after 13 October 2026 moves the behaviour from Audit to Enforce without ever creating that value. Nothing appears in the registry, and the device becomes stricter than the last administrator intended. That is the whole reason a registry search proves so little here.
Keep the boundaries apart while you read the output. LmCompatibilityLevel is the network-authentication response level, which decides what challenge and response the machine will send to a server; it is not the control that governs SSO credential generation, so lowering it does not restore sign-in. Whether the device will speak NTLMv1 as a network protocol at all is a third boundary, and the current Windows 11 and Server 2025 releases have already dropped it. Credential Guard, the fourth, protects secrets on the device.
Correlate One Attempt With One Event
Reproduce the failure once, note the minute, then pull the local evidence in a single sitting. Three commands cover the build, the effective value and the NTLM operational log where a blocked SSO credential generation is recorded:
Get-ComputerInfo | Select-Object WindowsProductName, OsBuildNumber, OsVersion
reg query "HKLM\SYSTEM\CurrentControlSet\Control\Lsa" /v LmCompatibilityLevel
Get-WinEvent -LogName "Microsoft-Windows-NTLM/Operational" -MaxEvents 30 | Select-Object TimeCreated, Id, MessageAn event at the same moment as the failure is evidence. An event from yesterday, from another account, or a log with no entry at all is not, and the empty case is worth recording as empty rather than as absent proof. The Microsoft guidance for the NTLMv1 changes names the event identifier for blocked SSO credential generation, so compare the Id against it instead of guessing from the message text.
Keep the client's own message and the gateway's view of the same attempt together. A local credential-generation block, a remote account rejection and a missing private route after a successful login have three different owners, and only the first is a Windows policy question. Sanitise the event before it leaves the team: a timestamp and an event Id usually answer the question without the account details.
Move to a Supported Sign-In Method
If the effective policy is the block, the answer is a supported authentication path rather than a quiet reversal of the default. Certificate-based authentication is the usual destination where the deployment supports it, and it needs enrolment, trust distribution and a gateway that accepts the certificates. The Microsoft guidance on the upcoming NTLMv1 changes is the document to quote when the case is reviewed.
Disabling Credential Guard as an experiment removes protection without supplying a replacement login, and the documented restrictions on reusable credentials are the reason that is a design decision rather than a diagnostic step. If a temporary exception is authorised, give it a scope, an owner and a retirement date, and keep an independent administration route to the machine in case the change locks you out of the connection you need. The acceptance test is the intended authentication plus the resource behind it, not the disappearance of one local error code.