Intune kiosk mode: why autologon and Windows 11 multi-app kiosks fail

Intune kiosk mode rarely fails with an error. The profile reports success and the device restarts. Then, instead of a locked-down app, you get a password prompt or an ordinary desktop. Both outcomes have documented causes, but the causes are spread across four Microsoft articles in two product libraries, and the Intune page covers only part of the story.

The template you create in Intune is a thin wrapper around Windows Assigned Access, and most kiosk failures happen in Windows. The Intune portal never sees them. That is the same gap between reported and effective state described in Intune policy conflict, with the added problem that a kiosk has nobody sitting at it to notice. Every Microsoft fact below was checked against Microsoft Learn on 26 September 2026.

What the Intune kiosk template actually builds

The profile is created at Devices > Manage devices > Configuration > Create > New policy, with platform Windows 10 and later and profile type Templates > Kiosk. It writes to the AssignedAccess configuration service provider, and Microsoft’s configuration article says the policy is applied the next time each device checks in.

The limit that surprises people is in the Intune kiosk settings reference. It states that Intune can currently configure a multi-app kiosk on Windows 10 devices. For Windows 11 it sends you to a separate Windows article. So the template builds a single-app kiosk on either version, but a multi-app kiosk only on Windows 10. Windows 10 reached end of support on 14 October 2025.

Why Intune kiosk mode autologon fails

Autologon is the setting most public kiosks depend on, and it fails for three documented reasons.

The first is password policy. Microsoft’s Assigned Access configuration file article says the autologon account is created and managed by Assigned Access as a local standard user. It then states that when Exchange ActiveSync password restrictions are active on the device, the autologon feature doesn’t work, and that this behaviour is by design. The article does not list which Intune settings count as such a restriction. I would treat any device password policy targeted at the kiosk as a suspect, including one inherited from a baseline. Intune security baseline conflicts explains how a second profile ends up on a device nobody meant to touch.

The second is Conditional Access. The same article tells you not to apply the kiosk profile to users or groups targeted by Conditional Access policies that require user interaction, such as multifactor authentication or terms of use. A kiosk that stops at an MFA prompt is behaving correctly. The fault is the policy scope, which is set in the Conditional Access policy, not in Intune.

The third is the account. The Intune reference states that the kiosk profile loads for standard user accounts and doesn’t load for members of the local admin group. A kiosk tested by signing in as an administrator will always look broken.

The failure modes

These are the ways Intune kiosk mode fails, matched to the documented cause behind each one.

One row has a licensing edge worth stating separately. The Intune reference still says that kiosks with autologon using Microsoft Kiosk Browser must use an offline licence from the Microsoft Store for Business, because autologon uses a local account with no Entra credentials. That is what the page says as of 26 September 2026. If you are building a new kiosk, Microsoft Edge in kiosk mode avoids the question, and the reference pairs the kiosk profile with a separate Edge profile that must be assigned to the same devices.

Windows 11 multi-app: the Assigned Access XML route

On Windows 11 the multi-app kiosk is built from an Assigned Access configuration file and delivered as a custom policy. Microsoft’s multi-app kiosk article names the node.

1# Custom configuration profile row for a Windows 11 multi-app kiosk.
2# The value is the full Assigned Access XML configuration.
3OMA-URI: ./Vendor/MSFT/AssignedAccess/Configuration

Three behaviours from the same documentation decide whether it works. The configuration takes effect the next time the targeted user signs in, not when the policy lands, so a device that sits at the lock screen after sync is not yet a failure. A KioskModeApp profile can only be assigned to users, not to groups. And it is not supported to associate an admin user with an Assigned Access profile. Most failed Windows 11 kiosks break one of these three rules.

Moving from the template to a custom policy is the same trade described in settings catalog vs administrative templates. You get the full feature set. You lose the portal validation, so a malformed XML fails on the device rather than in the editor.

Where to look when a kiosk fails

The Windows client kiosk mode troubleshooting article gives the locations. Sign-in and autologon problems are logged under Applications and Services Logs\Microsoft\Windows\Authentication User Interface\Operational. Configuration and runtime problems go to the AssignedAccess Operational channel, which is disabled by default. The article also says to verify that User Account Control is turned on.

The detail that matters is in the same article: some events are only captured once, and if you enable logging after the problem occurs, the logs may not contain them. Turn the AssignedAccess channel on before the first deployment, not after the first ticket. For devices you cannot reach, the Intune primary user field is worth checking too, because a shared kiosk usually should not have one.

What I would do differently

I have not deployed Intune kiosk mode to a production estate. My tenant is a lab with no enrolled devices, so this is judgement drawn from the documentation above.

Put kiosks in their own device group from day one and exclude that group from every password, Conditional Access and baseline assignment before the first kiosk enrols. Almost every documented autologon failure is a policy meant for people landing on a device meant for nobody.

Build Windows 11 multi-app kiosks with the XML route from the start, rather than trying the template first. The template will report success and build nothing, and time spent there is wasted.

Prefer Edge kiosk mode over Kiosk Browser for anything new, and test every kiosk with a standard account. Enable the AssignedAccess log channel in the same build. It is off by default, and it cannot tell you about a failure that happened before you switched it on.

Last verified: 26 September 2026