Hardening administrative actions: What IT pros need to know

Administrative actions are undergoing hardening changes that reduce the risk of privilege escalation and unauthorized access on Windows devices. These changes strengthen the trust boundary between identity, authentication, and User Account Control (UAC) enforcement. It’s now much harder for an attacker (or a misconfigured cloned device) to reuse or manipulate authentication artifacts after an OS restart to silently gain elevated privileges.

With these hardening changes, Windows now detects and blocks authentication attempts between machines that share duplicate SIDs.

This is by design and should be seen as a security signal, not a code defect.

Some environments deploy Windows devices using automation or virtual machine templates. Some of these methods rely on previously accepted authentication behavior between cloned systems. If you created these deployments without running Sysprep, that’s your case. Recent authentication hardening updates might now require you to rebuild affected devices using supported imaging methods.

A temporary workaround (detailed below) is available to provide time for remediation. However, it reduces the security protections introduced by the latest updates and cannot be used as a permanent solution due to its lifecycle end date.

Running Sysprep prepares a Windows image for deployment. Sysprep removes device-specific identity and security information, allowing each deployed machine to generate a unique system identity and authentication context when it starts.

Let’s take a closer look at why these hardening changes are important to the overall security of your environment and how you can update your cloning, imaging, and authentication practices.

Why administrative action hardening is necessary for security

The current administrative action hardening phase began with the August 2025 non-security update (KB5064081) and the September 2025 security update (KB5065426). These updates strengthen loopback authentication protections. They help ensure that Kerberos authentication is more tightly bound to the current machine state across OS restarts.

Previously, authentication artifacts could persist across restarts in ways that allowed elevated operations to proceed without explicit user approval. Current hardening helps reduce this risk. It improves how machine identity is validated during authentication.

While these changes improve security posture, they might require adjustments to how you deploy and manage devices in some environments.

Symptoms of administrative action hardening

With the installation of Windows updates released on or after August and September 2025, your devices were hardened against unauthorized attempts to bypass loopback detection. This applies to devices running Windows 11, version 24H2 and later as well as Windows Server 2025.

You might have observed authentication failures between machines when accessing SMB shares or connecting via Remote Desktop. Similar failures might also occur with authentication using New Technology LAN Manager (NTLM) or between machines that aren’t joined to a domain.

The target machine shows the following LsaSrv Event ID 6167 in the System event log:

This is an inconvenient but necessary symptom of administrative action hardening that might require operational change to support your organization’s security posture. Here’s why.

What changed internally

User Account Control (UAC) in Windows primarily acts as a privilege mediation mechanism. It helps ensure that administrative rights are exercised only with explicit user approval. While users may hold administrative credentials, applications they launch initially run with standard user privileges. Privileges must be explicitly elevated through a UAC consent prompt to perform administrative actions.

Recent security investments in Windows have tightened how you approve and enforce administrative actions. These UAC hardening changes reduce the risk of elevation without explicit user consent. Hardening happens through Windows updates and applies regardless of whether Administrator protection is enabled. Administrator protection (available in preview) also benefits from these changes. It helps reduce automatic elevation paths and reinforces explicit, user-approved elevation for administrative operations. The result is a stronger trust boundary between identity, authentication, and UAC enforcement. 

Loopback detection and token filtering scenarios are also part of this effort. A machine ID is used to check if a machine is performing loopback authentication, i.e., authenticating to itself. Before the August 2025 non-security update, each boot randomly generated the machine ID. However, authentication artifacts could still persist across a restart in ways that allowed threat actors to bypass token filtering.

Windows updates released on and after August 2025 detect and block such behavior. Windows now persists part of the machine ID across boots.

Before, authentication handshakes between Windows hosts that were cloned from each other succeeded because only per-boot components were checked. Now, authentication handshakes are detected and blocked because the cross-boot component of the machine ID is the same between the two hosts, while the per-boot component is not, resulting in a partial mismatch of machine IDs.

Specifically, if you've cloned machines without running Sysprep, you might see Kerberos and NTLM authentication failures. You can identify them by the LsaSrv event 6167 log in the auth target machine, for both NTLM and Kerberos protocols.

This behavior is not a regression. It’s a direct and intentional consequence of binding loopback authentication more tightly to machine identity across OS boots.

In summary, prior to installing Windows Updates released on or after August 2025:

• Machine ID regenerated on every boot.
• Loopback detection relied entirely on per-boot state.
• Persisted authentication artifacts could bypass token filtering.

After August 2025:

• Machine ID combines per-boot and cross-boot components.
• Loopback detection survives restarts.
• Persisted authentication artifacts are reliably rejected.

Management recommendations for administrative action hardening symptoms

While administrative action hardening improves security, it requires an adjustment in your strategy to clone Windows images. As you embrace administrative action hardening for its security benefit, you should take the following actions:

• Stop any automation that clones devices without Sysprep. If not addressed, devices end up with duplicate security IDs (SIDs).
• Rebuild all devices with duplicate SIDs from scratch, then run Sysprep. It's not sufficient to unjoin devices and run Sysprep. If needed for transition only: temporarily roll back the hardening change.

Recommended solution

When cloning a Windows image, you should always use Sysprep. You can read more about this recommendation in our official documentation in KB314828 and The Microsoft policy for disk duplication of Windows installations.

If your scenario falls outside of this recommendation, the only supported and durable resolution is to rebuild affected systems using supported deployment and imaging methods. Once done, you should remove existing clones.

Temporary workaround (not recommended)

We understand that while cloning without Sysprep may have been unsupported, you still may have taken a dependency on it. To help ease the transition to a supported configuration, a temporary compatibility option is now available. This option relaxes the updated authentication behavior to allow continued operation in affected environments. It’s provided solely to facilitate remediation and should not be considered a long-term configuration.

Please contact Microsoft Commercial Customer Service and Support (CSS) to get information about this registry value. Complete the intake form as follows:

You must have an understanding of the risk of disabling administrative action hardening. You’ll also need to provide:

• Reasoning for requiring this temporary workaround
• A clear plan for the long-term resolution of reimaging cloned machines in your environment
  
  

This registry key will act as temporary rollback until it expires and allow authentication that would otherwise by blocked by loopback identity protections. Event Viewer helps you monitor this temporary workaround. If you set this temporary registry value and restart the system, the next authentication attempt will be allowed. An LsaSrv warning event 6168 will be logged in the target machine in the System event log:

The only way to stop seeing this event is to migrate your environment to a supported state. Once done, please delete the registry key or set it to 0.

Timeline to remove the clones in your environment

The rollback is temporary and will remain available until the end of 2027. We hope this timeframe provides your organization with sufficient opportunity to migrate your environment to a supported state by following established deployment methods for cloning.

For additional information, check out the following resources:

• KB5070568: Kerberos and NTLM authentication failures due to duplicate SIDs
• KB5068222: Strengthening administrator protection and Kerberos authentication 
• The Microsoft policy for disk duplication of Windows installations 
• Sysprep 
• Administrator Protection
• Windows 11: August 29, 2025—KB5064081 (OS Build 26100.5074) Preview
• Windows Server 2025: September 9, 2025—KB5065426 (OS Build 26100.6584)

Securing the present, innovating for the future

Security is a shared responsibility. Through collaboration across hardware and software ecosystems, we can build more resilient systems secure by design, by default and during runtime, from Windows to the cloud, enabling trust at every layer of the digital experience.

The updated Windows 11 Security Book and Windows Server Security Book are available to help you understand how to stay secure with Windows. Learn more about Windows 11, Windows Server, and Copilot+ PCs. To learn more about Microsoft security solutions, visit our website. 

Bookmark the Security Blog to keep up with our expert coverage on security matters.

Also, follow us on LinkedIn (Microsoft Security) and X (@MSFTSecurity) for the latest news and updates on cybersecurity.

Continue the conversation. Find best practices. Bookmark the Windows Tech Community, then follow us @MSWindowsITPro on X and on LinkedIn. Looking for support? Visit Windows on Microsoft Q&A.