Same error message, two completely different worlds. A domain PC has Kerberos to fall back on; a workgroup PC never did. Troubleshooting that ignores which world you are in will chase the wrong cause all day.
Here is the fact that untangles most home and small-office NTLM confusion: Kerberos requires a domain. On a workgroup PC, every sign-in to another PC uses a local account, and local accounts authenticate with NTLM - that is the design, not a leftover. Microsoft's phase-out targets NTLM in domain network authentication; it does not remove the mechanism your two workgroup PCs use to talk to each other. So when a workgroup login fails with an authentication error, 'Microsoft disabled NTLM' is almost never the explanation. This page separates the two worlds and the fix shape each one needs.
Why the same-looking error needs a different checklist depending on how the PC is joined.
With no domain in the picture, a blocked or looping workgroup logon comes down to three ordinary things:
Network security: LAN Manager authentication level refuses what the other PC offers. Align them, preferring the higher (NTLMv2) sideHOSTPC\username with that host account's password, not the password of the same-named account on your own PCOn a domain PC, an NTLM-blocked error means the Kerberos path failed first and the fallback was refused. Work the Kerberos list instead:
Notice there is no overlap worth speaking of: not one item on the domain list is fixed by the workgroup list, and the reverse is equally true.
Small offices often have one: a standalone PC that must reach a domain file server. The server treats the connection as an outside logon, so the workgroup PC must present a domain account explicitly - type DOMAIN\username at the prompt rather than letting Windows offer the local account. If the server has begun denying NTLM, that standalone PC has no Kerberos path at all (it is not domain-joined, so it holds no machine trust) - the honest options are joining it to the domain, giving it a named exception, or accepting it as a known legacy corner with the least rights possible.
systeminfo or Settings will tell you in seconds whether the PC is domain-joined or in a workgroup - and only then pick a checklist.The full process with live demonstration - every setting shown on screen, step by step.
Watch Full VideoNot in the way people fear. Workgroup and local-account logons use NTLM by design and in-market Windows versions continue to support NTLM. The phase-out is aimed at domain network authentication, with NTLMv1 - the ancient flavour removed from Windows 11 24H2 and Windows Server 2025 - going first.
Usually because the password is correct for the wrong account. The host PC checks the account that exists on the host. Sign in explicitly as HOSTPC\username with that account's password, and clear any stale saved credential in Credential Manager.
No. Kerberos needs a Key Distribution Center, which means a domain controller. A workgroup PC has nothing to request tickets from - NTLM with local accounts is its only built-in option.