Active DirectoryAuthenticationCredential GuardHardeningKerberosNTLMSecurity

NTLMv1 and BlockNtlmv1SSO in October 2026: What to Audit, What Gets Blocked, and What Stops Working

Q: Can I leave BlockNtlmv1SSO=0 indefinitely?

The KB documents 0 as Audit and allows an explicit value. Govern it as a compatibility exception with an owner, accepted risk, monitoring, and review date; it is not the final remediation for a legacy dependency.

Published: 3 October 2026Updated: 3 October 2026

Topic

Do I need to change anything before October 2026? Yes: identify affected Windows 11 24H2 and Windows Server 2025 devices, collect events 4024 and enhanced NTLM audit events, check Credential Guard, and test Enforce with a pilot group. Microsoft announced that a future update will change the default for BlockNtlmv1SSO from Audit to Enforce only when the value has not been explicitly deployed. As of October 3, 2026, the KB reviewed still describes a future update. Check the applicable cumulative update release notes and Windows Message Center before saying the rollout is already in effect.

Quick answer

This is not NTLM being disabled. It blocks Single Sign-On (SSO) that requires NTLMv1-derived credentials.
BlockNtlmv1SSO=0 audits and allows; =1 blocks. An explicit 0 keeps Audit when the default changes.
4024 is the Audit warning; 4025 is the Enforce error. Use 4020-4023 to investigate NTLM more broadly.
When Credential Guard is running, BlockNtlmv1SSO has no effect; do not disable Credential Guard to test the key.
Plan auditing, a pilot, application ownership, and rollback before the update.

Scope: what changes and what does not

Microsoft-documented facts

Microsoft removed the NTLMv1 protocol from Windows 11, version 24H2, Windows Server 2025, and later versions. Some scenarios can still use NTLMv1-derived cryptographic primitives; Microsoft specifically cites MS-CHAPv2 in domain-joined environments. BlockNtlmv1SSO controls generating and using NTLMv1-derived credentials for Single Sign-On. It is not a general policy that disables NTLM. KB5066470

The registry setting is:

HKLM\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0
BlockNtlmv1SSO    REG_DWORD

Data	Mode	Documented effect
`0`	Audit	Records and allows the SSO request; generates a warning.
`1`	Enforce	Blocks the SSO request; generates an error.
Value absent	System default	Audit today; Microsoft plans to change the default to Enforce through a future update.

The October change applies only where the value has not been explicitly deployed. The KB does not name a single cumulative update, minimum build, or exact day. Its timeline is tentative and subject to change. Check the current KB5066470, the cumulative update release notes for the relevant product, and the Windows Message Center. Do not infer rollout from the calendar alone.

Newer and older systems

System	What can be concluded	What cannot be concluded
Windows 11 24H2 and later	NTLMv1 is removed; some derived primitives remain, and the new control applies when present in the relevant updates.	It does not mean every NTLM authentication fails.
Windows Server 2025	NTLMv1 is removed; auditing and control have a timeline separate from client rollout.	Do not assume every server received the feature on the same date.
Earlier Windows versions in the domain	They may still implement NTLMv1 depending on OS, patches, and configuration. Inventory them separately.	A key on a newer client does not make older domain systems behave the same way.
Appliances and non-Windows systems	Behavior depends on the client, protocol, and authentication mode.	A Windows registry key is not a global switch for every NAS, RADIUS server, or appliance.

For exact applicability by OS version and update, use the current matrix in KB5066470. If Microsoft does not specify the information, mark it as unconfirmed rather than extrapolating from the timeline.

NTLMv1 SSO is not NTLM disablement

NTLM includes multiple versions and paths. This change concerns SSO based on NTLMv1-derived credentials. It is not the end of NTLM, is not equivalent to Restrict NTLM policies, and does not generally block NTLMv2. Microsoft describes disabling network NTLM by default as a separate phase of its authentication modernization roadmap, associated with future major client/server releases. Versions already released continue to support NTLM; this change does not announce a general disablement date.

IAKerb and Local KDC are intended to address scenarios where Kerberos was previously impractical: Kerberos authentication mediated without direct line-of-sight to a domain controller, and Kerberos authentication with local accounts. They are roadmap elements, not automatic fixes for every NTLM dependency. As of October 3, 2026, I have not verified a Microsoft source confirming the H2 2026 Phase 2 rollout status. Check current documentation, release notes, and Message Center before adding dates to a plan. Windows authentication roadmap

For general NTLM auditing, Restrict NTLM, Kerberos fallback, SPNs, and trusts, use the NTLM audit-to-enforcement guide, the Active Directory SPN guide, and the guide to Kerberos-to-NTLM fallback. This guide does not repeat that runbook.

Events: which question each ID answers

The events below are in Microsoft-Windows-NTLM/Operational. Verify that the channel exists, is enabled, and is forwarded. Choose events based on the question you are investigating:

ID	Side and level	Correct use
`4020`	Client, Information	Standard NTLM attempt; general NTLM audit.
`4021`	Client, Warning	NTLM attempt with a downgrade/security condition to investigate; includes client context.
`4022`	Server, Information	Standard incoming NTLM attempt.
`4023`	Server, Warning	Incoming NTLM attempt with a security condition to investigate.
`4024`	Client, Warning	NTLMv1-derived SSO request in Audit; allowed.
`4025`	Client, Error	NTLMv1-derived SSO request blocked in Enforce.

Events 4020-4023 add information about the user/process, reason, and target for NTLM authentication. An Information event is not evidence of NTLMv1; it normally indicates NTLMv2 or other NTLM use without the downgrade described by auditing. Warning identifies a downgrade and can include NTLMv1 or other conditions. Existing Restrict NTLM policy events remain separate. KB5064479: enhanced NTLM auditing

4024/4025 are not counters for all NTLMv1 authentications and do not replace domain-wide or client/server auditing. Use them for the specific SSO request with NTLMv1-derived credentials. To answer “who uses NTLM in general?”, collect client and server events 4020-4023, applicable domain-wide events, and the existing logs already in use.

PowerShell query and name-based XML parsing

Run the query on an updated system and preserve raw XML during validation. EventData names can vary by event and build; do not rely on Properties[n].

# Read recent enhanced NTLM audit and NTLMv1 SSO control events
$eventIds = 4020, 4021, 4022, 4023, 4024, 4025
$events = Get-WinEvent -FilterHashtable @{
    LogName = 'Microsoft-Windows-NTLM/Operational'
    Id = $eventIds
    StartTime = (Get-Date).AddDays(-14)
} -ErrorAction SilentlyContinue

# Extract XML values by the Name attribute, not Properties index
$rows = foreach ($event in $events) {
    [xml]$xml = $event.ToXml()
    $namedData = [ordered]@{}
    foreach ($item in $xml.Event.EventData.Data) {
        $fieldName = [string]$item.Name
        if ($fieldName) {
            $namedData[$fieldName] = [string]$item.'#text'
        }
    }
    [pscustomobject]@{
        TimeCreated = $event.TimeCreated
        Computer = $event.MachineName
        EventId = $event.Id
        Level = $event.LevelDisplayName
        Provider = $event.ProviderName
        EventDataJson = ConvertTo-Json -InputObject $namedData -Compress
        Message = $event.Message
    }
}

# Keep data in a format that can be imported into a SIEM or Excel
$rows | Export-Csv -Path '.\ntlm-events.csv' -NoTypeInformation -Encoding utf8

Before using this at scale, validate the output against at least one real event for every relevant ID and inspect the provider XML on your build. Message is localized; use event ID, timestamp, host, and named XML fields for stable correlation. Do not export identities or host names outside approved channels.

For central collection, forward the channel through Windows Event Forwarding (WEF) to a collector or a SIEM connector. Verify subscriptions, latency, retention, event volume, read permissions, and preservation of the source host. Collect the event on the client or server that generates it; do not assume a domain controller sees a local client process event.

Inventory the key and Credential Guard

Before a pilot, identify OS/build and the key's presence/data on managed clients and servers. An explicit 0 is different from a missing value when the default changes.

# Inspect local configuration without making changes
$path = 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0'
$key = Get-ItemProperty -Path $path -Name BlockNtlmv1SSO -ErrorAction SilentlyContinue
[pscustomobject]@{
    Computer = $env:COMPUTERNAME
    OS = (Get-CimInstance Win32_OperatingSystem).Caption
    Version = (Get-CimInstance Win32_OperatingSystem).Version
    KeyExists = $null -ne $key
    BlockNtlmv1SSO = if ($null -ne $key) { $key.BlockNtlmv1SSO } else { $null }
}

# Check whether Credential Guard is actually running
$deviceGuard = Get-CimInstance -Namespace 'root\Microsoft\Windows\DeviceGuard' `
    -ClassName Win32_DeviceGuard -ErrorAction SilentlyContinue
[pscustomobject]@{
    Computer = $env:COMPUTERNAME
    CredentialGuardRunning = $deviceGuard.SecurityServicesRunning -contains 1
    SecurityServicesRunning = ($deviceGuard.SecurityServicesRunning -join ',')
}

For a fleet, perform the same read through authorized remote management, Configuration Manager, Intune, or EDR inventory. Record hostname, edition/version, build/UBR, key data and source, Credential Guard state, last-check date, and owner. CIM results depend on OS and permissions: validate against real systems and do not treat an empty field as proof that protection is disabled.

Remote PowerShell collection for an approved scope

This example reads a CSV list through PowerShell Remoting and makes no changes. Connection errors remain visible; an unreadable key is not converted to a false zero.

ComputerName,Owner
W11-PILOT-01,Workplace
APP-PILOT-02,Application Operations

# Use only an approved list and read-authorized credentials
$computers = Import-Csv '.\ntlm-pilot-computers.csv'
$results = foreach ($computer in $computers) {
    try {
        Invoke-Command -ComputerName $computer.ComputerName -ErrorAction Stop -ScriptBlock {
            $path = 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0'
            $setting = Get-ItemProperty -Path $path -Name BlockNtlmv1SSO `
                -ErrorAction SilentlyContinue
            $os = Get-CimInstance Win32_OperatingSystem -ErrorAction Stop
            $guard = Get-CimInstance -Namespace 'root\Microsoft\Windows\DeviceGuard' `
                -ClassName Win32_DeviceGuard -ErrorAction SilentlyContinue
            [pscustomobject]@{
                ComputerName = $env:COMPUTERNAME
                OS = $os.Caption
                Version = $os.Version
                Build = $os.BuildNumber
                KeyExists = $null -ne $setting
                BlockNtlmv1SSO = if ($setting) { $setting.BlockNtlmv1SSO } else { $null }
                CredentialGuardRunning = $guard.SecurityServicesRunning -contains 1
                QueryStatus = 'Success'
            }
        } | ForEach-Object {
            $_ | Add-Member Owner $computer.Owner -PassThru
        }
    }
    catch {
        [pscustomobject]@{
            ComputerName = $computer.ComputerName
            Owner = $computer.Owner
            OS = $null
            Version = $null
            Build = $null
            KeyExists = $null
            BlockNtlmv1SSO = $null
            CredentialGuardRunning = $null
            QueryStatus = $_.Exception.Message
        }
    }
}
$results | Export-Csv '.\ntlm-pilot-inventory.csv' -NoTypeInformation -Encoding utf8

Remoting must already be authorized by the baseline; do not enable it on production systems for convenience. Test one reachable and one unreachable device; the latter should return an explicit error rather than invented policy data. Repeat the read after GPO/MDM refresh. Endpoint configuration, not a policy assignment in a portal, is evidence of application.

Credential Guard must be checked as actually running, not inferred from the existence of a policy. Microsoft says that when Credential Guard is enabled, BlockNtlmv1SSO changes have no effect because Credential Guard already protects against NTLMv1 cryptography. Do not turn it off to make a key test work. Check application compatibility using the Credential Guard documentation.

What may stop working

Enforce blocks an SSO request that needs NTLMv1-derived credentials. Manual credential entry continues to work according to the KB; that does not guarantee the entire application or subsequent protocol is compatible. The decisive evidence is a 4025 correlated with the failing function. The table distinguishes Microsoft-documented scenarios from plausible dependencies that must not be claimed without an event or reproduction.

Scenario	Possible symptom	Expected log evidence	Evidence status	Remediation/mitigation
MS-CHAPv2 in a domain-joined environment	Network or remote-access authentication fails to complete when derived-credential SSO is attempted.	`4024` in Audit or `4025` in Enforce on the client generating the request, if the flow invokes the control.	Microsoft cites domain-joined MS-CHAPv2 as using NTLMv1 primitives; not every flow is guaranteed to generate this event.	Identify the credential requester, EAP/PPP/RADIUS method, and vendor support. Migrate to a supported modern method or explicitly retain Audit while planning replacement.
VPN using MS-CHAPv2	VPN login fails after the change; manual entry or another method may behave differently.	`4025` only if that exact NTLMv1-derived SSO request occurs. A VPN error without 4025 does not establish causality.	Plausible from MS-CHAPv2; depends on the client, VPN profile, plugin, and SSO behavior.	Test the profile with a test account; collect VPN client, NPS/RADIUS, and NTLM Operational logs; update the profile/vendor or EAP method.
Wi-Fi 802.1X / NPS / RADIUS	Wireless authentication fails for some users or devices.	Correlate any endpoint `4025` with NPS/RADIUS events; do not assume NPS is where 4025 is written.	Plausible only if the negotiation uses an affected MS-CHAPv2/SSO path. Not all 802.1X networks use MS-CHAPv2.	Verify EAP method, NPS policy, machine/user identity, and certificate chain; prefer a supported method independent of the affected primitives.
Legacy domain-joined application	Resource access or component startup does not complete; repeated credential prompt.	`4025` with process, target, and identity if the component requests the affected SSO.	Plausible; “legacy” alone does not prove NTLMv1-derived SSO.	Identify process and caller from the event; ask the vendor about MS-CHAPv2 or derived credentials; update or configure a supported method.
NAS or appliance	SMB, VPN, or centralized authentication fails only from certain clients.	Possible `4025` on the client if that is where the derived credential is requested. Absence does not rule out unrelated protocol faults.	Must be tested; NTLMv1/NTLMv2 and authentication support vary by firmware and flow.	Check firmware and negotiated mode; test Kerberos/NTLMv2 or another supported method; do not attribute every SMB error to this key.
Windows service or scheduled task	A job fails under a service identity or without an interactive session.	`4025` only if the job invokes the affected SSO generation; check PID/process, account, and time.	Hypothesis to test; services and scheduled tasks do not automatically use NTLMv1.	Reproduce under the same account and logon type; inspect saved credentials, task history, and target; migrate to gMSA/Kerberos where appropriate.
Older third-party software	SSO error or password prompt after an update.	`4025` is useful evidence if the software requested the blocked credentials; otherwise use the product's own log.	Confirm with the vendor or lab; software age does not prove dependency.	Update the product, configure a supported provider, or document temporary explicit Audit with an expiry.

Manual username/password entry is not a universal workaround. Microsoft documents that manual credential entry continues to work, but the result depends on how the application uses the credentials and the subsequent protocol. A successful UI fallback does not prove the cryptographic dependency was removed.

Observed path	Documented/expected behavior	Evidence to collect
Automatic SSO by the signed-in user, Audit	The NTLMv1-derived request is allowed and generates 4024.	Process, target, account, time, and functional result.
Same SSO request, Enforce	The request is blocked and should generate 4025.	Client event and failure of the same workflow.
Explicitly entered credentials	Microsoft says this continues to work; application outcome depends on subsequent use.	Manual prompt in a test, application log, and negotiated protocol.
NTLMv2 or Kerberos	Not the use blocked by this specific key.	Confirm with protocol evidence, not only successful access.
Application still fails without 4025	The key has not been shown to be the cause.	Application/VPN/RADIUS logs, Restrict NTLM, and target telemetry.

To compare SSO with manual entry in a controlled way, use the same isolated client, test account, target, and operation. Record the protocol and do not reuse saved credentials between runs. If SSO is blocked but manual entry succeeds, you have tested the documented functional difference; you have not proved that the remote service changed protocol or that the dependency was removed.

If manual entry succeeds without a 4025, do not conclude the system never used NTLMv1-derived SSO: the prompt may have bypassed the automatic path. Test the original SSO path separately and retain both results under the same change ID.

Operating plan: inventory, audit, remediation, enforcement

1. Inventory and baseline

Export Windows 11 24H2+ and Windows Server 2025 devices, separating clients, application servers, and VPN/RADIUS endpoints.
Record version/build/UBR, cumulative update, role, owner, criticality, and test window.
Detect missing key, 0, 1, and configuration source (GPO, MDM, script, local setting).
Check whether Credential Guard is running and its prerequisites; do not infer it from Windows edition alone.
Find MS-CHAPv2 workloads in VPN/802.1X/RADIUS configuration; mark unconfirmed dependencies as hypotheses.

2. Audit

Confirm feature availability on observed builds using KB5066470; do not assume month-based rollout was universal.
Collect 4024 for NTLMv1-derived SSO and 4020-4023 for general NTLM from clients/servers; retain domain-wide and Restrict NTLM events already used.
Forward the channel to WEF/SIEM; observe at least one complete business cycle, including shifts, backups, batch jobs, and recovery.
Enrich each event with process, target, account, source, owner, and a reproducible test.
If no 4024 appears, do not conclude there are no dependencies; check patches, channel, forwarding, and workflow frequency.

3. Remediation and test

Classify each dependency as documented, observed in your own logs, or a hypothesis to test.
Ask the vendor about protocol and Kerberos/modern-method support; use the dedicated internal guides for SPN/trust remediation.
Create a representative pilot group without Tier 0 services or unexplained dependencies.
Test Enforce only on endpoints where Credential Guard is not running, because the key has no effect while it is active.
Validate interactive logon, tasks, VPN, Wi-Fi, line-of-business applications, failover, reboot, and help desk; correlate 4025 and functional impact in the same time window.

4. Gradual enforcement

Expand by ring/OU/device profile with an approved owner and change window.
Monitor 4025, support tickets, application errors, and authentication failures; define thresholds and observation duration in advance.
Maintain an exception register for BlockNtlmv1SSO=0: system, owner, reason, expiry, remediation, and compensating control.
After each ring, confirm resultant GPO/MDM configuration on the client, not only in the management portal.
Remove Audit exceptions only after validating the replacement path and agreeing with the owner.

Review checklist

Isolated lab: set Enforce and observe 4025

Changing the DWORD does not by itself generate event 4025. An application or controlled flow must actually request NTLMv1-derived SSO credentials. Microsoft cites MS-CHAPv2 in domain-joined environments, but does not guarantee that every implementation or request will generate this record. If you do not have a documented, reproducible trigger, stop after validating configuration; do not fabricate an event.

Component	Recommended baseline
Client	Updated Windows 11 24H2 test VM, snapshot, isolated network
Identity	Test account and password; no real or privileged credentials
Service	Authorized MS-CHAPv2/RADIUS test implementation configured for the lab domain
Log	NTLM Operational enabled; retain local raw XML
Security	Disable Credential Guard only if the approved lab specifically needs to test the key; never alter production hosts
Cleanup	Restore snapshot or explicitly restore the prior configuration

Record OS/build, patch, and Credential Guard state; enable Microsoft-Windows-NTLM/Operational and note the time.
Export the current key and save whether the value exists. Stop if the VM is not isolated or the workflow uses real identities.
Reproduce the supported flow once in Audit (0) and look for 4024. If it is absent, confirm that the flow is the documented one; do not assume every MS-CHAPv2 login is sufficient.
Set Enforce (1) on this VM only, repeat the same request, and compare time, process, target, and result with the baseline.
Expected result only if the affected SSO request is exercised: event 4025 and blocked SSO. No event or a RADIUS error without 4025 does not prove BlockNtlmv1SSO caused the failure.
Restore explicit 0 to return to Audit and repeat; if the original state cannot be reconstructed, restore the snapshot.

# Only on the isolated VM: enable the channel and set Enforce
$logName = 'Microsoft-Windows-NTLM/Operational'
wevtutil set-log $logName /enabled:true
$regPath = 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0'
New-Item -Path $regPath -Force | Out-Null
New-ItemProperty -Path $regPath -Name BlockNtlmv1SSO `
    -PropertyType DWord -Value 1 -Force | Out-Null
Get-ItemProperty -Path $regPath -Name BlockNtlmv1SSO

# After the test: explicitly set Audit; do not leave the value absent
Set-ItemProperty -Path $regPath -Name BlockNtlmv1SSO -Type DWord -Value 0
Get-WinEvent -FilterHashtable @{
    LogName = $logName
    Id = 4024, 4025
    StartTime = (Get-Date).AddMinutes(-30)
} -ErrorAction SilentlyContinue | Format-List TimeCreated, Id, LevelDisplayName, Message

This test does not authorize enabling MS-CHAPv2 or changing production VPN/Wi-Fi/RADIUS authentication. To test the future default, use a second VM with no explicit value only after the applicable Microsoft update is available and verified in release notes. Do not anticipate the behavior by uninstalling updates or guessing at a build.

GPO management and rollback criteria

This is not a Restrict NTLM policy: BlockNtlmv1SSO is a registry value. Deploy it using Group Policy Preferences > Windows Settings > Registry (Hive HKEY_LOCAL_MACHINE, key SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0, value BlockNtlmv1SSO, type REG_DWORD) or an approved endpoint-management platform. Scope it carefully, check precedence/conflicts, and measure the client result. To remain explicitly in Audit after the default change, create value 0; do not delete it.

Deploy an explicit Audit value through Group Policy

Configure the Registry preference in a separate GPO targeted to the approved ring:

Group Policy Preference field	Value
Action	Update
Hive	`HKEY_LOCAL_MACHINE`
Key Path	`SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0`
Value name	`BlockNtlmv1SSO`
Type	`REG_DWORD`
Data	`0`
Targeting	Approved pilot computer group or lab OU

Update creates or changes the specified value without deleting unrelated data. If Audit and Enforce are managed by separate GPOs, their scopes must be mutually exclusive or precedence must be documented. An endpoint must not ambiguously receive both 0 and 1.

Change sequence:

Create a pilot GPO with the change ID and mode in its name.
Link it only to an isolated OU or use security filtering for approved computers.
Export gpresult and the current registry key before the change.
Run gpupdate /target:computer /force during the approved window.
Verify the registry value on the client and save the resultant policy report.
Repeat event queries and functional tests after application.
Remove or narrow targeting only after verifying that the previous setting is no longer present.

# Run on the pilot client during the approved change window
gpupdate /target:computer /force
gpresult /scope computer /h '.\gpresult-ntlmv1-pilot.html'
Get-ItemProperty `
    -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0' `
    -Name BlockNtlmv1SSO

Do not enable general Restrict NTLM deny policies in the same pilot: BlockNtlmv1SSO and Restrict NTLM are separate controls, and a double block makes impact attribution harder.

Rollback: if a critical service fails and the failure correlates with 4025, and immediate remediation is unavailable, the change owner can explicitly set BlockNtlmv1SSO=0 for the affected group, verify deployment, and retest the workflow. Record reason, owner, expiry, residual risk, monitoring, and a plan to remove the exception. Reverting this value does not restore NTLMv1 as a protocol on systems where it was removed, disable Credential Guard, or fix unrelated authentication errors.

Scenario	Audit (`0`)	Enforce (`1`)	Recommended action
No NTLMv1-derived SSO request	No 4024 for the observed path.	No expected impact from this key.	Continue monitoring through periodic workflows.
SSO request identified by 4024	Warning logged; request allowed.	Attempt is blocked and should generate 4025.	Identify process/owner; test an alternative before Enforce.
Domain-joined MS-CHAPv2	May continue if the specific SSO generation is allowed; depends on the flow.	May fail if it uses derived credentials and requests SSO.	Confirm with events and a test; do not infer from protocol name alone.
Credential Guard active	BlockNtlmv1SSO control has no effect.	Same; key does not force an additional control.	Keep Credential Guard and verify it is running.
Older system without the feature	Depends on OS version and available policies.	The value does not imply uniform support for the control.	Inventory and use OS-specific documentation.
Critical service fails with correlated 4025	Setting `0` allows the affected request.	SSO remains blocked while Enforce is active.	Targeted, temporary rollback with owner and expiry; migrate the flow.

Respond to a service interruption correlated with 4025

Treat the event as a scoped availability issue until evidence indicates otherwise. Do not restore NTLM generally, disable Credential Guard, or change authentication policies domain-wide.

Confirm the affected client is in Enforce and 4025 coincides with the workflow failure.
Check that a second control, such as Restrict NTLM or an application policy, is not blocking the connection.
Identify the service, owner, and impact; consider isolating the device or using an approved alternative path.
If the change owner approves an exception, explicitly set BlockNtlmv1SSO=0 only for the affected endpoint/ring through the governed configuration source.
Confirm Audit locally, repeat the workflow with the owner, and observe whether the request is allowed.
If the problem persists without 4024, restoring the value is not a diagnosis: continue troubleshooting the protocol/application.
Record an expiry and owner for removing the exception; do not turn an emergency rollback into an untracked permanent policy.

If policy comes from GPO/MDM, change the source configuration for the authorized scope. A local Set-ItemProperty may be overwritten at the next refresh and create configuration drift. Use it only in an isolated VM or when the enterprise runbook explicitly authorizes local action.

# Local example for a test endpoint or explicitly approved rollback
$path = 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0'
New-Item -Path $path -Force | Out-Null
Set-ItemProperty -Path $path -Name BlockNtlmv1SSO -Type DWord -Value 0
Get-ItemProperty -Path $path -Name BlockNtlmv1SSO

This command does not restore the NTLMv1 protocol on Windows versions where it was removed; it only allows the derived SSO path controlled by this key where the feature exists. After service recovery, retain the event, change record, effective value, and test confirming the outcome.

Triage an event 4024 or 4025

Preserve the original event and collect context before assigning an owner. Reading one rendered message field can conflate the supplied account, process identity, and destination.

Evidence	Triage purpose
Event time and time zone	Correlate with tickets, application logs, and user attempts. Preserve original time and normalize to UTC in the SIEM.
Source host	Identify the device generating the request; the target server can be a different system.
Event ID, level, provider	Distinguish SSO audit, SSO block, and general NTLM events.
PID and process name	Starting point for identifying the calling application or service.
User, domain, LUID	Distinguish supplied user from process/session identity.
Target server and Mechanism OID	Help map to a service; interpret the OID only with relevant mechanism documentation.
Registry and Credential Guard at event time	Compare with effective configuration then; a current value does not prove historical state.

Suggested procedure:

Filter the client by event ID and a narrow failure time window.
Open raw XML and identify the named fields present in that build.
Map the process name to a service, package, or product using inventory/EDR.
Compare the target with application telemetry; for VPN or RADIUS also use product logs.
Reproduce with a test account and endpoint while keeping other variables constant.
Treat 4025 plus a functional failure in the same workflow as strong evidence; an application error without 4025 does not prove causation.
Record build, update, key value, Credential Guard state, owner, test, and rollback decision.

The Microsoft text for 4025 is: An attempt to use NTLMv1-derived credentials for Single Sign-On was blocked due to policy. The KB lists target server, supplied user/domain, PID/process name, LUID, process identity, and Mechanism OID. Treat these as documented examples, not an immutable XML schema: use field names present in the collected record.

The process svchost.exe can host multiple services; PID and process name alone may not identify the component. Correlate them with Service Control Manager, EDR, and the application catalog. Mechanism OID alone does not identify the application protocol or owner.

# Preserve original XML for recent SSO events
$since = (Get-Date).AddHours(-2)
Get-WinEvent -FilterHashtable @{
    LogName = 'Microsoft-Windows-NTLM/Operational'
    Id = 4024, 4025
    StartTime = $since
} -ErrorAction SilentlyContinue |
    ForEach-Object { $_.ToXml() } |
    Set-Content '.\ntlmv1-sso-events.xml' -Encoding utf8

Before importing into a SIEM, validate the document with an XML parser and protect it as authentication telemetry: it can include usernames, hosts, processes, and internal targets. Limit access and retention to approved rules.

Measure pilot outcomes

Compare equivalent pre/post windows and workflow outcomes, not just total error counts. Automated retries can repeat one 4025; a rare event may instead coincide with an important recovery job.

Indicator	Pre-change evidence	Gate before expansion
Event 4024	Distinct hosts, processes, targets, and time windows.	Dependency and owner identified; alternative tested or exception approved.
Event 4025	Unique hosts/processes/targets in addition to row count.	No unexplained critical block in the observation window.
Application/VPN errors	Baseline failure ratio and severity.	No increase beyond the threshold agreed with the service owner.
Service desk tickets	Category, impact, users, and timestamps.	No unresolved upward trend after the approved duration.
Configuration state	Coverage of intended value across the ring.	In-scope hosts verified; exclusions have a documented reason.
Collection quality	Source host identity and forwarding delay.	No gaps that make the pilot unobservable.

The change owner sets thresholds and duration based on service volume and criticality; Microsoft publishes no universal threshold for authorizing enforcement.

Evidence record for each dependency

Do not aggregate every event by account or device first. Create a record for each distinct client, process, target, and workflow combination; multiple processes on one endpoint may represent different dependencies.

Field	Data to retain
Finding/change ID	Stable ticket and change identifier.
First/last observation	Timestamp and time zone, preserving the original source.
Client and role	Source host, interactive user or service identity, business function.
Operating system	Edition, release, build/UBR, and cumulative update.
Configuration	Key value, GPO/MDM/local source, Credential Guard state.
Event	ID, level, provider, channel, and XML field names actually present.
Raw evidence	Protected location of original XML and applied retention.
Process	Name, PID at event time, account, and owning service if identified.
Supplied identities	Supplied user/domain and process identity, kept distinct.
Destination	Recorded target, service, and address if available.
Protocol	Observed application method and evidence source; do not infer from a prompt.
NTLM reason	Usage Id/Reason from enhanced events when present.
Impact	Failed function, users, criticality, and frequency, not only event volume.
Owner	Technical contact, business owner, and vendor/case reference.
Test	Test ID, non-privileged account, build, before/after result.
Decision	Remediation, exception, accepted risk, approver, and expiry.
Closure check	Event absent for the agreed period, functional test passed, and logs retained.

Pseudonymize identities in reports for groups that do not need usernames. Keep the reversible mapping only in the authorized incident system. A count without process and target is useful for capacity/volume but is not sufficient to approve Enforce.

Verify rollout before changing the default

The date in the KB is a planned timeline, not proof that the update has reached your fleet. Record the observed facts in a change log:

Field	Evidence to record
Verification date	Date, time, and time zone of the check.
Microsoft source	KB and section reviewed; product/cumulative update release notes; Message Center ID if available.
System checked	Client/server edition, release, build, and UBR.
Key state	Missing, `0`, or `1`; note whether GPO/MDM set it.
Credential Guard state	Running/not running, collected on the same endpoint.
Behavior test	Audit 4024 or Enforce 4025 from an authorized test; write “not reproduced” if absent.
Decision	Ring, approving owner, exception, review date, and rollback.

Before calling the change “deployed,” check more than one device and its cumulative update, compare applicable Microsoft documentation, and confirm whether the value is explicit or missing. A policy setting 0 may intentionally mask the new default; a missing key on an unupdated build may simply not have received the change.

Go/no-go for each ring

Proceed to the next ring only when all of these statements are true:

the endpoint team confirmed release, build/UBR, and applicable Microsoft update;
the application owner reviewed 4024 events and relevant MS-CHAPv2 hypotheses;
WEF/SIEM coverage can observe the ring's clients;
Credential Guard was classified per device, and the key is not being used as a test control where it is already running;
Enforce testing has a functional criterion, business owner, and approved window;
rollback to explicit 0 was tested and the exception group has an expiry;
the service desk knows symptoms and escalation route for the ring.

Stop and remain in Audit if a request cannot be assigned to a process/owner, logs are missing from the SSO-generating computer, an unclassified 4025 affects a critical workflow, or the test does not reproduce production state.

The change record should separate three states instead of compressing them into “NTLM disabled”:

Announced by Microsoft: the KB plans a future Enforce default and may still be subject to change.
Available in the product: release notes or an update identify the applicable product/build.
Observed in the fleet: inventory/configuration and endpoint testing show the result after the update.

Only the third state supports a description of impact actually observed in the environment; the first two do not replace functional testing.

FAQ

Is NTLMv1 being disabled everywhere in October 2026?

No. The change concerns SSO with NTLMv1-derived credentials on applicable devices without an explicit key. NTLMv2 remains allowed, and the roadmap for disabling network NTLM is separate.

Can I leave `BlockNtlmv1SSO=0` indefinitely?

The KB documents 0 as Audit and allows an explicit value. Govern it as a compatibility exception with an owner, accepted risk, monitoring, and review date; it is not the final remediation for a legacy cryptographic dependency.

Does event 4024 mean a password was compromised?

No. It records an SSO attempt with NTLMv1-derived credentials. Treat it as evidence of use and weak cryptography exposure, not standalone proof of compromise.

Does Enforce also block a user who types a password?

The KB says manually entered credentials continue to work. Application behavior still needs testing: the event covers the specific SSO request, not every possible subsequent authentication.

Should I expect 4025 on every client or domain controller?

No. It is tied to the blocked SSO request and the component making that request. Do not assume a DC logs a client-local process event; use channel documentation and the source host.

How do I distinguish NTLMv1 from NTLMv2?

Use events and fields specific to this feature, not just a successful access or Authentication Package: NTLM. General events 4020-4023 help locate NTLM use but are not a unique NTLMv1 indicator by themselves.

Do IAKerb or Local KDC automatically fix this dependency?

That is not documented as an automatic outcome. They are Kerberos capabilities on a roadmap for specific scenarios; check current availability, prerequisites, and application support in documentation and release notes.

Microsoft Support, KB5066470: upcoming NTLMv1 changes in Windows 11 24H2 and Windows Server 2025.
Microsoft Support, KB5064479: NTLM auditing enhancements.
Microsoft Learn, Credential Guard overview.
Microsoft Learn, NTLM deprecation and Windows authentication resources.
Windows IT Pro Blog, The evolution of Windows authentication.
For general NTLM auditing and rollback: From NTLM audit to enforcement in Active Directory.
For SPN and fallback prerequisites: SPNs in Active Directory and Kerberos-to-NTLM fallback.
For account protection scope and limitations: Protected Users: production limitations.

Last updated

Last updated: October 3, 2026. At today's check, the KB still describes the default change as a future update and its timeline remains tentative. Recheck cumulative update notes and Windows Message Center; when the release is identifiable, update this note with the observed KB, build, and date.

Disclaimer

The lab instructions are for isolated VMs and networks. Do not apply Enforce, change Credential Guard, or modify VPN/Wi-Fi/RADIUS methods in production without inventory, approved change control, functional testing, monitoring, and rollback. Scenarios labeled plausible or unconfirmed are not Microsoft-guaranteed behavior. Verify sources and behavior on your build before taking action.

The contents of this guide are provided for informational purposes only, without warranties. Application of any procedure is at the user's own risk. Disclaimer.

Appreciation

If this guide is useful, leave a like.

Related guides

Active Directory / Authentication