Windows 802.1X SSO Failures After October 2026: Diagnose Before Changing Cisco ISE

Full technical analysis

The problem

A Windows endpoint installs the October 13, 2026 security update and suddenly cannot join an enterprise Wi-Fi network. The RADIUS policy has not changed, and other devices still connect. It is natural to look first at the Cisco ISE policy set. But on affected clients, the cause may be Windows itself: a newly enforced restriction on generating NTLMv1-derived credentials for single sign-on (SSO).

Microsoft changed the internal default for BlockNtlmv1SSO from Audit (0) to Enforce (1) when the registry value is absent. The change concerns Windows 11 24H2, 25H2, 26H1 and 26H2, and Windows Server 2025, when Credential Guard is disabled. On domain-joined systems, certain Wi-Fi, Ethernet and VPN SSO flows using MS-CHAPv2—including PEAP-MSCHAPv2—may fail when Windows can no longer generate the required response from a logged-on user’s credentials. This restricts automatic credential use; it does not remove every form of MS-CHAPv2 password authentication. Nor does every PEAP failure implicate this Windows change. [1]

Microsoft KBs to check first

• KB5066470 — Microsoft’s explanation of the default change, affected SSO flows, event IDs and temporary Audit-mode exception. Updated October 19, 2026 to include 26H1 in Applies To. [1]
• KB5127648 — October 13 Windows 11 24H2/25H2/26H2 update, builds 26100/26200/26300.9711. Its authentication release note explicitly describes the change. [5]
• KB5127646 — October 13 Windows 11 26H1, build 28000.3231. The page identifies the update but, as checked October 20, does not contain the corresponding NTLMv1 authentication release note. The 26H1 applicability claim comes from KB5066470; do not attribute it to this release note. [7]
• KB5126646 — October 13 Windows Server 2025 update, build 26100.33650, with the authentication release note. [6]

Important: The KBs establish software scope and documented behavior—not that a given endpoint’s failure has this cause. The internal-default change applies to eligible, updated devices only when Credential Guard is disabled and BlockNtlmv1SSO is absent. An explicit value has its documented meaning independently of that default. [1]

Diagnose the right layer

1. Establish applicability before changing anything. Record the OS build, installed update, domain membership, the Windows supplicant’s EAP method, whether it is attempting logged-on-user SSO rather than prompted credentials, and the actual Credential Guard running state. Compare an affected and an unaffected client. Do not infer what happens to pre-logon or machine-authentication flows from a logged-on-user SSO example alone. [1]

Save the following read-only diagnostics as a .ps1 file and run it from an elevated Windows PowerShell session. Microsoft documents elevation for the Credential Guard query. A single & { ... } block ensures a failed check stops the remaining diagnostics even when commands are pasted interactively. The NTLM event query distinguishes an empty retained log from errors accessing the log. [1][8][10][14]

& {
    $cv = Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion' -ErrorAction Stop
    "OS build: $($cv.CurrentBuild).$($cv.UBR)"

    $dg = Get-CimInstance -Namespace root\Microsoft\Windows\DeviceGuard -ClassName Win32_DeviceGuard -ErrorAction Stop
    if ($null -eq $dg -or $null -eq $dg.SecurityServicesRunning) {
        throw 'Unable to establish Credential Guard running status.'
    }
    "Credential Guard running: $(@($dg.SecurityServicesRunning) -contains 1)"

    $regPath = 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0'
    $key = Get-Item -LiteralPath $regPath -ErrorAction Stop
    if (@($key.GetValueNames()) -contains 'BlockNtlmv1SSO') {
        "BlockNtlmv1SSO: $($key.GetValue('BlockNtlmv1SSO')) [$($key.GetValueKind('BlockNtlmv1SSO'))]"
    } else {
        'BlockNtlmv1SSO: absent (interpret using installed update and Credential Guard status)'
    }

    try {
        Get-WinEvent -FilterHashtable @{
            LogName = 'Microsoft-Windows-NTLM/Operational'
            Id = 4013,4014,4024,4025
        } -MaxEvents 50 -ErrorAction Stop |
            Select-Object TimeCreated, Id, Message
    } catch {
        if ($_.FullyQualifiedErrorId -like 'NoMatchingEventsFound*') {
            'No matching NTLM events in the retained log; not proof no events occurred.'
        } else { throw }
    }
}

For Win32_DeviceGuard.SecurityServicesRunning, an output containing 1 means Credential Guard is running; 0 indicates it is not. Do not mistake another running VBS service for Credential Guard, or treat a failed query as confirmation that it is disabled. msinfo32.exe → System Summary → Virtualization-based Security Services Running provides a graphical cross-check. [10]

2. Split the diagnosis by Credential Guard status. If Credential Guard is running, the October default-change scenario is not the explanation; Credential Guard already prevents the relevant SSO credential use. Events 4013/4014 belong to the Credential Guard investigation. In that branch, setting BlockNtlmv1SSO=0 is not an effective workaround. With Credential Guard not running, investigate 4025 (blocked in Enforce mode) and 4024 (audited and permitted in Audit mode) under Applications and Services Logs → Microsoft → Windows → NTLM → Operational. Correlate the message’s process and timestamp with the actual connection attempt. [1][8]

3. Correlate with Cisco ISE. In Operations → RADIUS → Live Logs, filter on the relevant endpoint and timestamps; inspect the detailed authentication report where present. Determine whether an EAP exchange reached ISE, whether it ended in a policy reject, remained incomplete, resulted in a timeout, or left no completed authentication record. These are distinct outcomes. A Windows-side credential block does not prove an ISE authorization-policy defect. The actual PEAP sequence and ISE logging depend on the point of failure, the supplicant, the authenticator and retries. Do not claim a completed PEAP tunnel—or a particular ISE failure code—without packet or lab evidence. [2][4]

4. First recovery choice: leave enforcement enabled. For interactive user workflows that permit prompting, configure the Windows wired/wireless/VPN supplicant to request manually entered credentials, rather than automatically reusing Windows logon credentials. Microsoft explicitly says manually entered credentials continue working in Enforce mode. Confirm that the client still validates the expected EAP server identity and trusted CA; do not weaken server validation to make prompting work. Exact UI or GPO/MDM instructions vary by supplicant profile and management method. This is not an asserted fix for unattended, pre-logon or machine-authentication flows. [1][8]

5. Use a temporary exception only when prompting is not feasible. Obtain security approval, identify the affected devices and an expiration date, confirm the update and Credential Guard preconditions, and determine whether the value is managed by Group Policy or Intune/MDM. If policy-managed, make and roll back the exception in that policy: a local registry edit can be reverted by policy refresh.

For a locally managed pilot device only, the following Windows PowerShell reference procedure changes one registry value, not its containing key. Save the entire block as Apply-BlockNtlmv1SSO-Audit.ps1 and execute it as a script from elevated Windows PowerShell (for example, with powershell.exe -NoProfile -File .\Apply-BlockNtlmv1SSO-Audit.ps1), following your organization’s execution and signing policy. Use the same administrative account later for rollback. #Requires -RunAsAdministrator applies to script execution, not reliably to interactive paste; the explicit administrator check and & { ... } wrapper also guard pasted use. The block refuses to proceed if Credential Guard status is unknown or running, the documented key is missing, the existing value has an unexpected type/data, or a prior-state file already exists. It saves the original presence, data and type before setting Audit. The state file lives in the administrative account’s profile; preserve it in an approved, access-controlled change record. Treat that plain-text file as an operational record, not tamper-proof evidence. Review the script for your environment before execution. This script has not been executed in a Windows lab. [1][9][10][12][13][14]

#Requires -RunAsAdministrator
& {
    $ErrorActionPreference = 'Stop'
    $me = [Security.Principal.WindowsIdentity]::GetCurrent()
    if (-not ([Security.Principal.WindowsPrincipal]::new($me)).IsInRole(
        [Security.Principal.WindowsBuiltInRole]::Administrator)) {
        throw 'Run in an elevated Windows PowerShell session.'
    }

    $path = 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0'
    $name = 'BlockNtlmv1SSO'
    $stateFile = Join-Path $env:USERPROFILE "BlockNtlmv1SSO-before-$env:COMPUTERNAME.json"
    if (Test-Path -LiteralPath $stateFile) {
        throw "Prior-state file already exists: $stateFile. Investigate before re-running."
    }

    $dg = Get-CimInstance -Namespace root\Microsoft\Windows\DeviceGuard -ClassName Win32_DeviceGuard -ErrorAction Stop
    if ($null -eq $dg -or $null -eq $dg.SecurityServicesRunning) {
        throw 'Credential Guard status unavailable; no exception applied.'
    }
    if (@($dg.SecurityServicesRunning) -contains 1) {
        throw 'Credential Guard is running; Audit mode will not restore SSO.'
    }

    $key = Get-Item -LiteralPath $path -ErrorAction Stop  # Do not create this key
    $existed = @($key.GetValueNames()) -contains $name
    $kind = if ($existed) { $key.GetValueKind($name).ToString() } else { $null }
    if ($existed -and $kind -ne 'DWord') {
        throw 'Unexpected original registry type; investigate manually.'
    }
    $oldValue = if ($existed) { [int]$key.GetValue($name) } else { $null }
    if ($existed -and $oldValue -notin @(0,1)) {
        throw 'Unexpected original registry data; investigate manually.'
    }
    if ($existed -and $oldValue -eq 0) {
        throw 'Already in Audit mode; no new exception applied.'
    }

    $state = [ordered]@{
        Schema = 1; Computer = $env:COMPUTERNAME; Path = $path; Name = $name
        Existed = $existed; Kind = $kind; Value = $oldValue
        CapturedUtc = (Get-Date).ToUniversalTime().ToString('o')
    }
    $state | ConvertTo-Json -Depth 3 |
        Out-File -LiteralPath $stateFile -Encoding UTF8 -NoClobber -ErrorAction Stop
    $record = Get-Content -LiteralPath $stateFile -Raw -ErrorAction Stop | ConvertFrom-Json -ErrorAction Stop
    if ($record.Schema -ne 1 -or $record.Computer -ne $env:COMPUTERNAME -or
        $record.Path -ne $path -or $record.Name -ne $name -or
        $record.Existed -ne $existed -or $record.Kind -ne $kind -or
        $record.Value -ne $oldValue) {
        throw 'Could not validate saved prior state; no registry change applied.'
    }

    New-ItemProperty -Path $path -Name $name -PropertyType DWord -Value 0 -Force -ErrorAction Stop | Out-Null
    $key = Get-Item -LiteralPath $path -ErrorAction Stop
    if ($key.GetValueKind($name).ToString() -ne 'DWord' -or [int]$key.GetValue($name) -ne 0) {
        throw 'Audit-mode write verification failed; investigate and use recorded rollback.'
    }
    "Temporary Audit mode enabled. Preserve state file: $stateFile"
}

This procedure does not modify other MSV1_0 values. Never recreate the existing MSV1_0 key with New-Item -Force: Microsoft documents that doing so can replace the key and its values. Microsoft states no device restart is required for a BlockNtlmv1SSO change; nevertheless, a reconnect, updated supplicant behavior and resulting event/ISE evidence must be tested rather than presumed. [1][9]

Security consequence: Audit mode permits NTLMv1-derived SSO credential generation that Enforce mode would block. This is a deliberately scoped security exception, not a durable repair. Do not broadly uninstall the cumulative security update as a standard remediation.

Decision guide

Observation	Interpretation and next action
Credential Guard running; 4013/4014	Investigate Credential Guard, not the October default-change branch.
Credential Guard not running; eligible update; 4025	The Enforce-mode SSO restriction is a plausible cause; correlate with the attempted connection.
Same connection succeeds with manually entered credentials	Supports a logged-on-user credential-derivation issue; still verify ISE and supplicant evidence.
4024 after a scoped exception	Audit-mode legacy-derived SSO activity is occurring; identify and eliminate the dependency.
ISE reject, incomplete EAP, timeout or no completed record	Preserve the distinction; troubleshoot the actual failure stage rather than assuming ISE authorization was responsible.

Move toward certificate authentication

The longer-term remediation is to remove reliance on this SSO credential-derivation path. For managed endpoints with a workable certificate lifecycle, EAP-TLS offers a practical migration, provided both the endpoint and ISE certificate trust and authorization are designed correctly. Cisco ISE configuration here refers to the 3.5 administration guide and should still be checked against the exact deployed version and patch. [2][4][11]

1. Issue endpoint certificates. Provision user and/or device certificates with the appropriate identity attribute, Client Authentication purpose and key usages. Determine whether the access policy expects user identity, machine identity or both. Establish renewal, key protection and revocation procedures before wide deployment. [2][4]
2. Configure ISE’s EAP server certificate. Under Administration → System → Certificates → System Certificates, use a suitable CA-signed server certificate on the relevant Policy Service Nodes with EAP Authentication usage. Verify its server-authentication purpose, trusted chain and the server identity that Windows clients are configured to validate. Binding or replacing certificates can restart services; plan the specific change and node sequence in a maintenance window rather than assuming every certificate import restarts every node. [2][4]
3. Trust the endpoint issuing CA chain. Under Administration → System → Certificates → Trusted Certificates, import the appropriate CA certificates, and select Trust for authentication within ISE and Trust for client authentication and Syslog for CA entries used to authenticate EAP endpoints. This is not an arbitrary expansion: Cisco ISE 3.5 Table 11, Trusted Certificate Edit Settings, says the second option applies only if the first is selected, and identifies endpoint EAP authentication as its use. Scope trust to the intended issuing CAs; do not select unrelated administrative-authentication trust purposes. Cisco documents restart prompts following trusted-certificate imports in some workflows, including certificate-based administrator access. Follow the deployed release’s prompts, sequence changes carefully and plan a maintenance window; do not assume every EAP-TLS trust import necessarily restarts every node. [2][4]
4. Map certificate identities. Configure Administration → Identity Management → External Identity Sources → Certificate Authentication Profile, selecting the principal username attribute that matches the issued certificates and the intended account/device lookup. Make explicit whether identity-store lookup or group-based authorization is required. [2][3][4]
5. Enable EAP-TLS in the right policy. At Policy → Policy Elements → Results → Authentication → Allowed Protocols, enable Allow EAP-TLS in the intended protocol list. Use that list in a scoped policy set under Policy → Policy Sets, with appropriate authentication and authorization rules. Configure Windows clients to select EAP-TLS and validate the ISE server certificate and expected server name. Cisco’s 3.5 Segmentation guide documents the Allowed Protocols location and setting. [4][11]
6. Pilot and test negative cases. Begin with a small SSID/VLAN/port scope. Check ISE Live Logs for the actual certificate authentication and authorized access. Test untrusted issuers, wrong certificate identity, missing appropriate EKU, and expired certificates. Note that ISE has an explicit option to allow expired certificates for a tightly restricted renewal workflow: the required negative outcome may be no normal network authorization, not necessarily an outright authentication failure, if that feature is deliberately enabled. [2][11]

Certificate revocation is a policy decision, not an automatic guarantee

Before relying on revocation as a control, configure OCSP, CRL or both on the relevant issuing CA’s Trusted Certificates entry. In Cisco ISE 3.5, OCSP may be configured to reject UNKNOWN or unreachable responder conditions; CRL settings include whether to bypass verification when no CRL has been received and whether to disregard CRL validity dates. If both methods are enabled, Cisco documents attempting OCSP first and falling back to CRL when status cannot be determined. These are deliberate security-versus-availability choices, not universal defaults. [2]

Test a genuinely revoked client certificate after the configured checking method has current revocation information, and separately test expired/stale or unreachable revocation infrastructure. Account for OCSP caching and CRL retrieval intervals; a recently revoked certificate may not be rejected immediately by a previously cached status. Record what actually happens in the chosen policy. Do not claim fail-closed behavior based only on EAP-TLS being enabled. [2]

7. Roll back the temporary Windows exception. After the pilot confirms an acceptable replacement method, return a locally managed endpoint to the exact state recorded before the exception. Use the same elevated administrative account/profile as in Step 5 so the stored state file is available, or retrieve the protected file from the approved change record. Save the complete block as Restore-BlockNtlmv1SSO-Original.ps1 and run it as a .ps1 file from elevated Windows PowerShell, under the organization’s script-signing and execution policy. The & { ... } wrapper prevents any failed guard from falling through to later statements if the code is pasted interactively. The script validates the saved host/value identity and refuses to overwrite a current value that is neither the expected temporary Audit setting nor the already-restored prior state. It operates only on BlockNtlmv1SSO. Not lab-tested. [12][13][14]

#Requires -RunAsAdministrator
& {
    $ErrorActionPreference = 'Stop'
    $me = [Security.Principal.WindowsIdentity]::GetCurrent()
    if (-not ([Security.Principal.WindowsPrincipal]::new($me)).IsInRole(
        [Security.Principal.WindowsBuiltInRole]::Administrator)) {
        throw 'Run in an elevated Windows PowerShell session.'
    }

    $path = 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0'
    $name = 'BlockNtlmv1SSO'
    $stateFile = Join-Path $env:USERPROFILE "BlockNtlmv1SSO-before-$env:COMPUTERNAME.json"
    if (-not (Test-Path -LiteralPath $stateFile -PathType Leaf)) {
        throw "Prior-state file missing: $stateFile; do not guess rollback values."
    }
    $state = Get-Content -LiteralPath $stateFile -Raw -ErrorAction Stop | ConvertFrom-Json -ErrorAction Stop
    if ($state.Schema -ne 1 -or $state.Computer -ne $env:COMPUTERNAME -or
        $state.Path -ne $path -or $state.Name -ne $name -or
        $state.Existed -isnot [bool] -or
        ($state.Existed -and ($state.Kind -ne 'DWord' -or $state.Value -notin @(0,1))) -or
        (-not $state.Existed -and ($null -ne $state.Kind -or $null -ne $state.Value))) {
        throw 'Unexpected state-file contents; stop for manual review.'
    }

    $key = Get-Item -LiteralPath $path -ErrorAction Stop
    $existsNow = @($key.GetValueNames()) -contains $name
    $kindNow = if ($existsNow) { $key.GetValueKind($name).ToString() } else { $null }
    $valueNow = if ($existsNow -and $kindNow -eq 'DWord') { [int]$key.GetValue($name) } else { $null }
    $alreadyRestored = if ($state.Existed) {
        $existsNow -and $kindNow -eq $state.Kind -and $valueNow -eq [int]$state.Value
    } else { -not $existsNow }

    if (-not $alreadyRestored) {
        if (-not $existsNow -or $kindNow -ne 'DWord' -or $valueNow -ne 0) {
            throw 'Current value differs from the temporary Audit setting; investigate policy or intervening changes.'
        }
        if ($state.Existed) {
            New-ItemProperty -Path $path -Name $name -PropertyType DWord -Value ([int]$state.Value) -Force -ErrorAction Stop | Out-Null
        } else {
            Remove-ItemProperty -Path $path -Name $name -ErrorAction Stop
        }
    }

    $key = Get-Item -LiteralPath $path -ErrorAction Stop
    $existsAfter = @($key.GetValueNames()) -contains $name
    if ($existsAfter -ne [bool]$state.Existed) { throw 'Rollback presence verification failed.' }
    if ($existsAfter -and ($key.GetValueKind($name).ToString() -ne $state.Kind -or
        [int]$key.GetValue($name) -ne [int]$state.Value)) {
        throw 'Rollback type/data verification failed.'
    }
    'Original registry state restored or already present. Retain the state file with the change record.'
}

Restoring the prior state is not always the same as enabling enforcement. If the value was originally absent, deleting the temporary value reactivates the eligible updated Windows default (Enforce). If it was explicitly 1, rollback restores Enforce. If an administrator had already set 0 before this change, returning to that prior policy remains Audit; remediation and an approved move to Enforce are separate changes. The example exception script deliberately refuses to add a second exception when Audit is already set. After a successful rollback and sign-off, archive the prior-state JSON in the controlled change record; the apply script deliberately refuses to run again while the local state file remains. Do not remove a value now controlled by GPO/MDM or blindly import an old snapshot of the entire MSV1_0 key. The checks in these scripts cannot make a registry change atomic with a simultaneous policy refresh; managed deployments must perform this through their management policy. [1]

Prove success

On the pilot clients, confirm the intended EAP-TLS authentication, server identity validation and ISE authorization while Windows remains in Enforce mode—or while the registry value is absent and the eligible post-October default is Enforce. Correlate the Windows and ISE evidence, and measure 4024 events on remaining Audit-mode exception devices over a defined observation window. After restoring enforcement on migrated devices, verify that relevant 4025 blocks no longer appear for that network authentication workflow. A quiet log by itself is not proof: confirm actual reconnection and policy results. Obtain security sign-off before wider removal of exceptions. [1][2]

Find dependencies before the next enforcement change

Microsoft began surfacing audit events in 2025 to identify dependencies on NTLMv1-derived SSO credentials. Where Windows NTLM/Operational logs or centralized copies are retained, review 4024 occurrences by device, process and time, correlate them with supplicant configurations, and target those dependencies for migration. Absence of historical events may mean there was no use, no retained history, insufficient logging or no matching activity during the observation window; do not assume which. [1]

Validation boundaries

This is a documentation-grounded implementation pattern, not an executed lab transcript. The following remain LAB-TESTING-REQUIRED before claiming deployment-specific behavior: machine and pre-logon authentication effects; the exact PEAP/EAP trace and ISE Live Log outcome of a Windows-side block; whether reconnecting without restarting the supplicant picks up the registry change in the intended environment; and ISE’s effective response to an unreachable or stale OCSP/CRL source. The PowerShell procedures require validation on a disposable Windows test endpoint with its actual policy and PowerShell version (including Windows PowerShell 5.1); their & { ... } fail-stop behavior has not been executed here on a Windows console, including PSReadLine or conhost. Test under the actual endpoint management and administrative-account model before operational reuse.

Takeaway: Diagnose Windows SSO behavior before changing Cisco ISE authorization. When practical, manually entered credentials offer an immediate path that keeps enforcement in place; make a registry exception only as a time-limited, recorded fallback. The durable improvement is eliminating the legacy SSO dependency through a tested authentication-method migration.

References

[1] Microsoft, Manage changes to NTLMv1 and prevent network issues in Windows 11 and Windows Server 2025 (KB5066470; revised October 19, 2026). https://support.microsoft.com/en-us/servicing/os/windows/docs/2025/08/upcoming-changes-to-ntlmv1-in-windows-11-version-24h2-and-windows-server-2025

[2] Cisco, Cisco Identity Services Engine Administrator Guide, Release 3.5 — Basic Setup, especially Certificate Usage, System Certificates and Table 11: Trusted Certificate Edit Settings. https://www.cisco.com/c/en/us/td/docs/security/ise/3-5/admin_guide/b_ise_admin_3_5/b_ISE_admin_basic_setup.html

[3] Cisco, Cisco Identity Services Engine Administrator Guide, Release 3.5 — Asset Visibility, Certificate Authentication Profiles. https://www.cisco.com/c/en/us/td/docs/security/ise/3-5/admin_guide/b_ise_admin_3_5/b_ISE_admin_asset_visibility.html

[4] Cisco, Configure EAP-TLS Authentication with ISE, TechNote 214975 (July 13, 2023). This is a general ISE 3.x configuration example, not a substitute for release-specific ISE 3.5 documentation. https://www.cisco.com/c/en/us/support/docs/security/identity-services-engine/214975-configure-eap-tls-authentication-with-is.html

[5] Microsoft, October 13, 2026—KB5127648 (Windows 11 24H2/25H2/26H2). https://support.microsoft.com/en-us/servicing/os/windows-11/2026/10/kb5127648-windows-11-24h2-25h2-26h2-security-update

[6] Microsoft, October 13, 2026—KB5126646 (Windows Server 2025). https://support.microsoft.com/en-us/servicing/os/windows-server/2026/10/kb5126646-windows-server-2025-security-update

[7] Microsoft, October 13, 2026—KB5127646 (Windows 11 26H1). Confirms build/update, but not a specific NTLMv1 note as checked October 20, 2026. https://support.microsoft.com/en-us/servicing/os/windows-11/2026/10/kb5127646-windows-11-26h1-security-update

[8] Microsoft Learn, Considerations and known issues when using Credential Guard, especially Wi-fi and VPN considerations and events 4013/4014. https://learn.microsoft.com/en-us/windows/security/identity-protection/credential-guard/considerations-known-issues

[9] Microsoft Learn, New-Item (PowerShell 5.1), Example 9 note concerning -Force on existing registry keys. https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.management/new-item?view=powershell-5.1

[10] Microsoft Learn, Configure Credential Guard, Verify if Credential Guard is enabled. https://learn.microsoft.com/en-us/windows/security/identity-protection/credential-guard/configure

[11] Cisco, Cisco Identity Services Engine Administrator Guide, Release 3.5 — Segmentation, Allowed Protocols, Table 13, including EAP-TLS and expired-certificate renewal policy. https://www.cisco.com/c/en/us/td/docs/security/ise/3-5/admin_guide/b_ise_admin_3_5/b_ISE_admin_segmentation.html

[12] Microsoft Learn, Out-File (PowerShell 5.1), -NoClobber to prevent replacing a saved prior-state file. https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.utility/out-file?view=powershell-5.1

[13] Microsoft Learn, New-ItemProperty (PowerShell 5.1), -PropertyType DWord and -Force. https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.management/new-itemproperty?view=powershell-5.1

[14] Microsoft Learn, about_Requires (PowerShell 5.1), RunAsAdministrator and script prerequisite behavior. https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_requires?view=powershell-5.1