Intune Kiosk Asking for a Password After Restart? Here’s Why
You set up a single-app kiosk, tested it, everything was great — and then someone restarted it. Now it’s sitting at the Windows login screen asking kioskuser0 for a password. This is one of those Intune issues that feels random but almost always has the same root cause.
Let’s fix it.
Why This Happens
The kiosk profile in Intune relies on a passwordless auto-logon mechanism. Windows stores the kioskuser0 credentials in the LSA Private Store and sets a few registry keys under HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon (AutoAdminLogon = 1, DefaultUserName = kioskuser0) to log in automatically on every boot.
The moment a policy tells Windows that this account needs a real password — or that the device needs to lock after a period of inactivity — that whole mechanism breaks.
The Most Common Culprits
1. A compliance or security policy is conflicting with the kiosk account
This is the #1 cause. If you have a Security Baseline, Compliance Policy, or Device Restriction profile targeted at “All Users” or “All Devices” that enforces minimum password length, complexity, or screen lock timeouts — it will catch kioskuser0 and break auto-logon.
The fix: exclude your kiosk devices from every policy that touches passwords or device locking. Use Filters to do this cleanly rather than trying to manage it through group membership alone.
2. User-based policies are bleeding onto device assignments
If a global MFA requirement or password policy is scoped to users and your kiosk device isn’t explicitly excluded, Windows will apply those rules at sign-in.
The fix: put kiosk devices in a dedicated Dynamic Device Group and explicitly exclude that group from all user-based configuration profiles.
3. A Win32 app is returning exit code 3010 during ESP
There’s a documented quirk where a Win32 app returning a “Soft Reboot” exit code (3010) during the Enrollment Status Page can corrupt the auto-logon registry keys before the device finishes provisioning.
The fix: change the 3010 return code behavior for the app to either Success (0) or Hard Reboot in Intune’s app detection settings.
4. The PreferredAzureADTenantDomainName CSP
If you’re using the Preferred AAD Tenant Domain Name CSP on your kiosk devices, remove it. It’s a known conflict with the User Logon Type auto-login feature in Assigned Access profiles.
Quick Troubleshooting Checklist
If you’ve checked the policies and the device is still broken, go hands-on:
- Registry: Confirm
AutoAdminLogon = 1andDefaultUserName = kioskuser0underHKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon - Event Viewer: Check
Applications and Services Logs > Microsoft > Windows > Authentication User Interface > Operational— it usually logs the exact reason auto-logon failed - LSA Secrets: If any policy clears or rotates LSA secrets, the stored
kioskuser0password is gone and auto-logon will fail silently - UAC: Counterintuitively, disabling UAC can break Assigned Access. Make sure it’s enabled
The good news: once you find the conflicting policy and exclude your kiosk devices properly, a re-sync and reboot almost always sorts it out. If you’re still stuck after going through this list, drop your policy config in the comments.
