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. If the symptom is not obviously a kiosk problem, the Intune troubleshooting hub sorts failures by what you see first. 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.

Windows 11 kiosk mode auto login through the Assigned Access XML

On Windows 11 the multi-app kiosk has no autologon tick box, because there is no template. Autologon is an element in the XML. Microsoft’s Assigned Access configuration file article, linked in the autologon section above, last updated 7 July 2025 and re-read on 29 October 2026, describes AutoLogonAccount as an instruction for Assigned Access to create and manage a local standard user that signs in automatically after a restart. The optional display name sits in the rs5 namespace, so that namespace has to be declared on the root element or the file fails validation on the device.

1<!-- Fragment: the Config block that turns on autologon.
2     rs5 must be declared on the root element as
3     http://schemas.microsoft.com/AssignedAccess/201810/config -->
4<Configs>
5  <Config>
6    <AutoLogonAccount rs5:DisplayName="Reception kiosk"/>
7    <DefaultProfile Id="{your-profile-GUID}"/>
8  </Config>
9</Configs>

The password rule from the autologon section applies here unchanged. The same article repeats that autologon does not work while Exchange ActiveSync password restrictions are active, and calls it by design. Moving from the template to XML does not get you round it.

Edge blocked inside a Windows 11 multi-app kiosk

When the multi-app configuration applies, Windows generates AppLocker rules that allow only the apps listed in the XML. Microsoft also states that if an app depends on another app, both must be in the allowed list. Edge is the common casualty: the kiosk launches, Edge or an Edge tile is pinned, and Edge will not open because one of its executables was not listed. Microsoft’s example lists three entries for Edge, and I would include all three in any configuration that uses it.

1<!-- Fragment: the AllowedApps entries Microsoft&#039;s example uses for Edge
2     in a restricted user experience. Leave one out and AppLocker blocks it. -->
3<AllowedApps>
4  <App DesktopAppPath="%ProgramFiles(x86)%\Microsoft\Edge\Application\msedge.exe" />
5  <App DesktopAppPath="%ProgramFiles(x86)%\Microsoft\Edge\Application\msedge_proxy.exe" />
6  <App AppUserModelId="Microsoft.MicrosoftEdge.Stable_8wekyb3d8bbwe!App"/>
7</AllowedApps>

For a single-app Edge kiosk built in XML rather than the template, the same article runs Edge as a KioskModeApp with its kiosk arguments on the command line. That is also where the idle timeout belongs, since the Assigned Access idle timeout does not apply to Edge kiosk mode.

1<!-- Single-app Edge kiosk in the XML route. The idle timeout lives in the
2     Edge arguments, because Assigned Access IdleTimeOut ignores Edge. -->
3<KioskModeApp v4:ClassicAppPath="%ProgramFiles(x86)%\Microsoft\Edge\Application\msedge.exe"
4  v4:ClassicAppArguments="--kiosk https://www.contoso.com/ --edge-kiosk-type=fullscreen --kiosk-idle-timeout-minutes=2" />

One escape route is worth knowing before a kiosk goes into a public space. Microsoft’s configuration article states that by default Ctrl+Alt+Del can be used to exit kiosk mode. Test what that sequence exposes on your build before the device leaves the bench.

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. Intune kiosk settings reference (updated 14 April 2026) and the Assigned Access configuration file article re-checked 29 October 2026; the Windows 10 only limit on multi-app kiosks in the template still stands.