Fix Local Windows Autopilot Reset When Deny Access from Network Blocks the Local Admin

Local Windows Autopilot Reset is supposed to be the fast way to hand a device back to IT, wipe the user state, keep the Microsoft Entra and Intune relationship, and get the machine ready for the next deployment. In a lot of real environments, that workflow breaks at exactly the point where a technician needs it most: they press CTRL + WIN + R from the lock screen, try to authenticate with a local administrator account, and the reset never starts.

Microsoft has now documented this as a known issue. If an Intune policy sets Deny access to this computer from the network for the local account, the local Windows administrator account can’t trigger a local Windows Autopilot Reset. That matters because many hardening baselines intentionally deny network logon to local admin accounts, especially on shared or sensitive endpoints. The security control is reasonable. The side effect is not obvious until a field tech is standing in front of the device and the local reset path is dead.

This is the practical fix: confirm that local Autopilot Reset is enabled, verify that the effective User Rights policy includes the local admin in DenyAccessFromNetwork, remove that assignment or exclude the affected devices, sync policy, and retest. If you need the device turned around immediately, use remote Autopilot Reset from Intune or perform a full wipe if the device is hybrid joined.

Quick Fix checklist

If you need the shortest path back to a working reset, use this sequence:

1. Confirm the device is Microsoft Entra joined, not hybrid joined.
2. Confirm local Autopilot Reset is actually enabled through Autopilot Reset = Allow or the DisableAutomaticReDeploymentCredentials CSP value.
3. Export effective local security policy and check whether the local admin account or the local Administrators group is included in Deny access to this computer from the network.
4. In Intune, review any custom OMA-URI, Endpoint security, Settings catalog, or baseline policy that writes the UserRights/DenyAccessFromNetwork setting.
5. Remove the local account from that deny assignment, or exclude break/fix devices that need local Autopilot Reset.
6. Sync policy to the device and test CTRL + WIN + R again from the lock screen.
7. If the device must be reset immediately, trigger remote Autopilot Reset from Intune instead of waiting for a technician-side workaround.

The key point is that this is not primarily a WinRE problem, a bad keyboard shortcut, or a broken local admin password. It is an effective rights-assignment collision.

Root cause: a security hardening policy collides with the local reset sign-in flow

Microsoft’s Windows Autopilot known issues page now calls out this exact behavior: when an Intune policy sets Deny access to this computer from the network for the local account, the local Windows administrator account can’t start a local Windows Autopilot Reset. Microsoft says the workaround is to remove that setting for the local account, or exclude devices that require local Autopilot Reset from the policy.

The confusing part is that the policy name sounds like it should only affect SMB-style network access. In practice, Microsoft documents two details that matter here:

• the policy is exposed in Intune through the User Rights CSP as ./Device/Vendor/MSFT/Policy/Config/UserRights/DenyAccessFromNetwork
• the deny right supersedes the allow right if an account is subject to both

Microsoft also documents local Autopilot Reset as a credential-provider-based flow. The reset does not simply wipe the device after the keystroke. The technician presses CTRL + WIN + R, Windows opens the special local Autopilot Reset sign-in screen, and an account with local admin credentials must authenticate before the reset starts.

That is where the collision happens. Your hardening baseline is blocking the same local identity the reset flow depends on.

This is why admins often misread the symptom. The local admin can still exist. The password can still be correct. The Autopilot Reset policy can still be enabled. But the sign-in used to authorize local reset is blocked by the security assignment.

Where to check: policy, device state, and the reset prerequisites

Before you change anything, verify the three conditions that separate this issue from other Autopilot Reset failures.

1. Confirm the device is eligible for local Autopilot Reset

Microsoft says Windows Autopilot Reset supports two scenarios: local reset and remote reset. It also says Autopilot Reset doesn’t support Microsoft Entra hybrid joined devices. If the device is hybrid joined, stop there. You need a full wipe instead of chasing this known issue.

Good quick checks:

dsregcmd /status

Look for the join state and confirm the device is Entra joined in the way your tenant expects.

2. Confirm local Autopilot Reset is enabled

Microsoft documents the local reset control through the DisableAutomaticReDeploymentCredentials policy. The CSP path is:

./Device/Vendor/MSFT/Policy/Config/CredentialProviders/DisableAutomaticReDeploymentCredentials

The important values are:

• 0 = show the credentials for Autopilot Reset
• 1 = hide them, which is the default

On the Intune side, Microsoft documents this as Autopilot Reset = Allow in a Windows device restrictions profile.

A quick device-side registry check:

Get-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\PolicyManager\current\device\CredentialProviders' |
Select-Object DisableAutomaticReDeploymentCredentials

If the value is not present or does not reflect the policy you intended, fix that before you touch User Rights.

3. Confirm WinRE is not the real blocker

Microsoft also documents another Autopilot Reset failure path: if Windows Recovery Environment is disabled or misconfigured, Autopilot Reset can fail with ERROR_NOT_SUPPORTED (0x80070032).

Check it quickly:

reagentc /info

If WinRE is disabled, enable it:

reagentc /enable

If your field symptom is specifically that local admin authentication cannot start the reset after CTRL + WIN + R, you are more likely looking at the DenyAccessFromNetwork issue than the WinRE issue. Still, it is worth ruling out both in one visit.

How to prove DenyAccessFromNetwork is the problem

The cleanest proof is to inspect effective user-rights assignments on the endpoint and then match them to Intune policy.

Export the effective local security policy

Run this from an elevated session:

secedit /export /cfg C:\Windows\Temp\secpol-export.inf

Then inspect the exported file for the deny right:

Select-String -Path 'C:\Windows\Temp\secpol-export.inf' -Pattern 'SeDenyNetworkLogonRight'

On some devices you will see SIDs rather than friendly names. If the local Administrators group or the specific local admin account SID is present, that is your strongest device-side confirmation.

If you want to expand the picture, compare the deny right with the allow right:

Select-String -Path 'C:\Windows\Temp\secpol-export.inf' -Pattern 'SeDenyNetworkLogonRight|SeNetworkLogonRight'

Microsoft’s policy documentation is explicit that the deny assignment overrides the allow assignment when both apply.

Check whether Intune is writing the deny right through CSP

Microsoft documents the Intune-relevant CSP path as:

./Device/Vendor/MSFT/Policy/Config/UserRights/DenyAccessFromNetwork

In practice, look for this setting in:

• Settings catalog profiles using User Rights Assignment
• Custom OMA-URI profiles that write UserRights/DenyAccessFromNetwork
• Security baselines or hardening profiles that deny network access to local administrator accounts
• any legacy policy migration where a CIS-style or internal baseline was copied into Intune

If you find the device or local Administrators group in that assignment, you have the policy path Microsoft is warning about.

Validate the sign-in workflow you are testing

Microsoft says the local reset flow is:

1. from the lock screen, press CTRL + WIN + R
2. Windows opens the custom local Autopilot Reset sign-in screen
3. sign in with an account that has local admin credentials

If your technicians are testing from a regular user desktop session without locking the device first, or they are trying this on a hybrid-joined machine, they can blur the issue. Reproduce it exactly from the lock screen on an Entra-joined device.

Remediation workflow that works in production

This is the sequence I would use in an enterprise tenant.

Step 1: Identify which policy owns the deny assignment

Use Device configuration and Endpoint security policy reporting in Intune to find the winning profile. Do not just remove the setting locally because it will come back at the next sync.

Your goal is to answer three questions:

• which profile writes Deny access to this computer from the network
• whether it targets the local account, the Administrators group, or both
• whether the assignment is broad enough to affect kiosks, shared devices, break/fix carts, and reimage benches

Step 2: Decide whether to narrow scope or create an exclusion

Microsoft’s documented workaround is either:

• remove the setting for the local account, or
• exclude devices that require local Autopilot Reset from the policy

In mature environments, an exclusion group is usually safer than gutting the baseline for every endpoint. Common patterns:

• exclude Autopilot staging or bench devices
• exclude shared-device rings that are reset frequently
• exclude emergency break/fix devices used by field engineers
• create a separate hardened profile for devices where remote-only reset is acceptable

If your security team insists on preserving the deny right broadly, document that local Autopilot Reset is no longer an approved support workflow for those devices and switch to remote reset.

Step 3: Sync the device and verify the effective change

After you update the assignment, sync the device from Intune or from the endpoint:

start ms-settings:workplace

Then use Info and Sync, or trigger a remote sync from Intune.

Re-export the effective security policy and confirm the deny entry changed:

secedit /export /cfg C:\Windows\Temp\secpol-after.inf

Select-String -Path 'C:\Windows\Temp\secpol-after.inf' -Pattern 'SeDenyNetworkLogonRight'

Do not stop at a green check in Intune. Confirm the effective right changed on the actual device.

Step 4: Retest the local reset flow

Lock the device, press CTRL + WIN + R, and authenticate with the approved local admin account.

If the reset still does not start, check the other two prerequisites again:

• DisableAutomaticReDeploymentCredentials must allow the local reset credential provider to appear
• WinRE must be enabled

That catches the cases where two unrelated issues were present at once.

Step 5: Use remote reset when local reset is not worth preserving

Microsoft documents remote Windows Autopilot Reset through Intune as a supported alternative. If your security baseline intentionally blocks local admin-driven reset on shared devices, remote reset is often the cleaner operating model.

That gives you:

• no technician-side dependency on local admin authentication
• no exception in your deny-network baseline for standard endpoints
• a cleaner audit trail in Intune device actions

For hybrid-joined devices, remember that Microsoft says Autopilot Reset is not supported. Use a full wipe instead.

Limitations and gotchas

A few traps show up quickly in the field.

This is a known issue, not a permanent product design contract

Microsoft marks the issue as under investigation. That means a future Windows or Intune change could alter the behavior. Until Microsoft publishes a fix, assume the current workaround is the supported path.

Removing the deny right has security tradeoffs

Microsoft’s security-policy guidance recommends caution with Deny access to this computer from the network because it is often used to stop local accounts from being used over the network. If you remove it broadly, you may weaken a control your security baseline intentionally relied on.

That is why scoped exclusions are usually better than blanket rollback.

Local reset is not always the best workflow

Some teams keep local Autopilot Reset enabled everywhere because it is fast for deskside support. Others are better served by remote reset plus tighter local-account hardening. Pick one model intentionally. Do not let a hidden policy collision choose for you.

A successful CTRL + WIN + R screen does not prove the device will finish resetting

Even after you fix the local admin sign-in problem, WinRE, enrollment state, and other Autopilot prerequisites can still fail later. Treat this article as the fix for the local admin cannot start local reset symptom, not the cure for every Autopilot Reset failure.

Bottom line

If local Windows Autopilot Reset suddenly stops working for your technicians, and you recently hardened local admin rights in Intune, check Deny access to this computer from the network before you burn time elsewhere. Microsoft has already documented the collision: the local admin account needed for CTRL + WIN + R can be blocked by the same policy meant to reduce local-account exposure.

The durable fix is to align your support model with your hardening model. Either exclude the devices that need local Autopilot Reset from the DenyAccessFromNetwork assignment, or standardize on remote Autopilot Reset and stop depending on the local reset path. What you should not do is leave your field teams guessing whether the keyboard shortcut, the password, or the device is broken when the real cause is an Intune User Rights policy.