Locking Down Business Terminals with Kiosk Mode — Choosing Between Assigned Access and Shell Launcher, and Designing for Operation

“A PC that was supposed to be a reception kiosk, and a visitor was opening Excel from the taskbar.” “YouTube was playing behind the device’s operator panel, and that turned out to be the cause of the complaints about the touch panel being sluggish.” “We came in one morning and the exhibition demo machine was sitting on a bare desktop showing the screen saver settings.” Left alone, a Windows terminal that is supposed to be dedicated to a single application will always end up being used as “just a PC”.

The usual countermeasure — “turn on auto-logon and register the business app in Startup” — protects nothing at all. The Explorer shell is running in full, so Alt+Tab or the Windows key gets you to the desktop in an instant. On the other hand, Windows has several mechanisms for kiosks — Assigned Access, Shell Launcher and multi-app kiosk — and which of them you can use varies by edition and Windows version, so it is common to end up reworking a design after discovering that “we tried to build it on a Pro machine and Shell Launcher wasn’t there”.

This article is for developers and IT staff who want to configure a “PC that runs only one application” — a reception terminal, a factory operator panel, an inspection machine’s operator screen, an exhibition kiosk. It lays out the overall picture of the available approaches and their edition requirements, configuration examples in PowerShell and XML, and the operational design around auto-logon, recovery from unexpected termination, Windows Update and maintenance access — all backed by the official documentation.

1. The Bottom Line First

• “Auto-logon plus a Startup entry” is not a kiosk. As long as the Explorer shell is alive, users can do anything. If you want to protect something, use a purpose-built mechanism.
• An Assigned Access single-app kiosk runs a UWP app or Microsoft Edge full screen on top of the lock screen and restarts it automatically when it is closed. It is available on Pro and above.¹
• On Windows 11, Assigned Access can make a Win32 (desktop) app a kiosk too. You specify the path to the EXE in v4:ClassicAppPath, added in the Windows 11 (21H2) schema and later. Kiosks on Windows 10 are limited to UWP/Edge.²
• Shell Launcher is a mechanism that replaces Explorer.exe itself with your business application (Win32 or UWP), and it is limited to the Enterprise / Education / IoT Enterprise family of editions. It cannot be used on Pro. It lets you declaratively configure what happens when the shell exits (restart the shell, restart the machine, and so on).³⁴
• A multi-app kiosk (restricted user experience) creates a “shared terminal where only a handful of apps can be used” via a list of allowed apps and a dedicated Start menu. AppLocker rules are generated automatically, and apps outside the allow list cannot be launched.²
• The configuration methods have been consolidated. Single-app, multi-app and Shell Launcher are all now configured through the AssignedAccess CSP (via MDM such as Intune) or via the WMI bridge plus PowerShell, which drives the same CSP locally.⁵⁶
• The default way out of a kiosk experience is Ctrl+Alt+Del. On Windows 11 you can change it with BreakoutSequence. Always leave a route in your design for a maintenance engineer to sign in.²
• However hard you lock the terminal down, poor design on the business application side (full-screen UI, no exit button, self-recovery on exception) leaves a hole. The OS mechanism and the application design come as a set.

2. The Overall Picture — Four Approaches That Differ in What They Can Protect

Start by laying the approaches side by side. What matters is not how they look, but what happens to the Explorer shell and who stops disallowed actions.

The intuition for choosing between them goes like this.

• Terminals touched by visitors or the general public (reception, exhibitions, public browsing): single-app kiosk. It minimizes the surface anyone can touch.
• Shared terminals that use a fixed handful of apps (line terminals on the shop floor, education): multi-app kiosk.
• Industrial use running a single Win32 business app as a device’s operator panel: Shell Launcher. Its strength is that Explorer-derived UI (notifications, the taskbar, the UI that appears on an edge swipe) simply does not exist, and being able to configure recovery actions per exit code also suits equipment.⁴
• Auto-logon plus Startup is used as a component of any of the above (automating sign-in), but on its own it is not a kiosk.

Note that you cannot configure both KioskModeApp (single-app kiosk) and Shell Launcher on the same device.² You pick one or the other.

3. Edition Requirements — What Pro Can Do, and What Requires Enterprise

Before choosing an approach, check the edition of the terminal you have in hand. Leaving this until later means redoing the whole design.

• Assigned Access (single-app / multi-app): Pro / Enterprise / Education / IoT Enterprise (including each LTSC).¹
• Shell Launcher: Enterprise / Enterprise LTSC / Education / IoT Enterprise / IoT Enterprise LTSC. Not available on Pro.³
• Keyboard Filter (key suppression): Enterprise / Education / IoT Enterprise family only. Not available on Pro.⁸

So the classic request, “I want to run just one Win32 app on a Pro machine”, works out as follows:

• On Windows 11, Assigned Access’s v4:ClassicAppPath does it directly.²
• On Windows 10 Pro, there is no such option: you either convert the app to UWP, get close with a multi-app kiosk plus auto-launch (rs5:AutoLaunch), or upgrade the edition.²

If you are selecting new terminals for an embedded or industrial PC, IoT Enterprise LTSC is the obvious front-runner: it has Shell Launcher and Keyboard Filter, and no feature updates are pushed at you. The thinking behind edition selection is covered in detail in “Choosing a Windows Edition for Industrial PCs — A Practical Guide to IoT Enterprise LTSC”, published the same day.

One further prerequisite: a kiosk experience requires UAC to be enabled and a sign-in from the console. A kiosk experience will not work over a Remote Desktop connection.¹ “Let’s connect via RDP and check it works” is the classic first-timer’s trap. For the relationship between console sessions and RDP sessions, see “How to Think About Windows Session Isolation”.

4. Building a Single-App Kiosk with Assigned Access

There are three configuration routes. We will look at them in order of simplicity.

(1) The Settings app. Under Settings > Accounts > Other users, “Set up a kiosk” walks you through creating a local kiosk account and choosing the target app in a wizard. If you choose Edge, you can also set full screen (digital signage) versus restricted browser, the start URL and the idle time before a restart. For a single machine running Edge or a simple UWP app, this is enough.⁵

(2) PowerShell cmdlets. Set-AssignedAccess creates the minimal configuration — “this local standard user gets only this UWP app” — in a single line (UWP only, local standard users only, administrator accounts not allowed).⁹

# Restrict the local standard user KioskUser to a single UWP app (find the AUMID with Get-StartApps or similar)
Set-AssignedAccess -UserName 'KioskUser' -AppUserModelId 'Contoso.KenkiPanel_abc123!App'

# Remove the configuration
Clear-AssignedAccess

(3) Configuration XML plus the AssignedAccess CSP. This is the real approach, covering Win32 app specification, auto-logon and changing the breakout key. From MDM such as Intune you apply it to ./Vendor/MSFT/AssignedAccess/Configuration; on a standalone machine you push the same XML through the WMI bridge from PowerShell running as SYSTEM.⁵ The essentials of the XML look like this.

<AssignedAccessConfiguration
    xmlns="http://schemas.microsoft.com/AssignedAccess/2017/config"
    xmlns:rs5="http://schemas.microsoft.com/AssignedAccess/201810/config"
    xmlns:v4="http://schemas.microsoft.com/AssignedAccess/2021/config">
  <Profiles>
    <Profile Id="{EDB3036B-780D-487D-A375-69369D8A8F78}">
      <!-- Windows 11: make a Win32 app the kiosk (arguments can be passed too) -->
      <KioskModeApp v4:ClassicAppPath="%ProgramFiles%\Contoso\KenkiPanel.exe"
                    v4:ClassicAppArguments="--line 3" />
      <!-- Change the breakout key from the default Ctrl+Alt+Del -->
      <v4:BreakoutSequence Key="Ctrl+Alt+K" />
    </Profile>
  </Profiles>
  <Configs>
    <Config>
      <!-- Windows creates and manages a dedicated local standard user and signs in automatically -->
      <AutoLogonAccount rs5:DisplayName="Reception Terminal" />
      <DefaultProfile Id="{EDB3036B-780D-487D-A375-69369D8A8F78}" />
    </Config>
  </Configs>
</AssignedAccessConfiguration>

For a UWP app you specify the AppUserModelId (AUMID) on KioskModeApp. One caveat: a UWP app update can change the AUMID, in which case the configuration needs updating.⁷ Also, kiosk profiles can only be assigned to users, not to groups.²

To apply it through the WMI bridge, start PowerShell as SYSTEM (with psexec or similar) and set the HTML-encoded XML on the Configuration property of the MDM_AssignedAccess class (in the form $obj.Configuration = [System.Net.WebUtility]::HtmlEncode($xml)). To remove it, set the same property to $null and restart.⁵

5. Making a Win32 App the Shell with Shell Launcher

If you can use an Enterprise-family edition, Shell Launcher is the strongest candidate for terminals like a device operator panel where “the very existence of Explorer is a nuisance”. Shell Launcher v2 (Windows 10 1809 and later) has CustomShellHost.exe launch and monitor the business app in place of Explorer.exe, and either a Win32 or a UWP app can be the shell.³

Configuration uses a dedicated XML, and its biggest feature is that you can declare the recovery action per exit code when the app terminates.⁴

<ShellLauncherConfiguration
    xmlns="http://schemas.microsoft.com/ShellLauncher/2018/Configuration"
    xmlns:V2="http://schemas.microsoft.com/ShellLauncher/2019/Configuration">
  <Profiles>
    <DefaultProfile>
      <!-- Users with no profile assigned, such as maintenance engineers, get the normal Explorer -->
      <Shell Shell="%SystemRoot%\explorer.exe" />
    </DefaultProfile>
    <Profile Id="{the GUID you allocated}">
      <Shell Shell="%ProgramFiles%\Contoso\KensaPanel.exe" V2:AppType="Desktop"
             V2:AllAppsFullScreen="true">
        <ReturnCodeActions>
          <ReturnCodeAction ReturnCode="0"  Action="RestartShell"/>   <!-- normal exit -> restart -->
          <ReturnCodeAction ReturnCode="10" Action="RestartDevice"/>  <!-- request a machine restart -->
        </ReturnCodeActions>
        <DefaultAction Action="RestartShell"/>
      </Shell>
    </Profile>
  </Profiles>
  <Configs>
    <Config>
      <AutoLogonAccount/>  <!-- creates and auto-signs-in the local standard user "Kiosk" -->
      <Profile Id="{the GUID you allocated}"/>
    </Config>
  </Configs>
</ShellLauncherConfiguration>

There are four actions: RestartShell / RestartDevice / ShutdownDevice / DoNothing. If the exit code is not in the mapping and DefaultAction is undefined, “nothing happens” — that is, the machine sits at a black screen. Always define DefaultAction.⁴ To apply the configuration, use ./Vendor/MSFT/AssignedAccess/ShellLauncher from MDM, or locally set the XML on the ShellLauncher property of MDM_AssignedAccess through the same WMI bridge used for Assigned Access.⁶ In some environments you first need to enable the Shell Launcher feature under Device Lockdown (Client-EmbeddedShellLauncher) via “Turn Windows features on or off”.

Three pitfalls specific to Shell Launcher are worth calling out.³

• An app that launches another process and then exits cannot be the shell. Shell Launcher monitors the exit of the process you specify, so if you point it at a launcher-style EXE (write.exe in the official documentation’s example), it immediately decides the shell “has exited”.
• The shell runs with the privileges of the signed-in user. Assign the shell to an administrator account and it can do anything with those privileges; and if the shell app itself requests elevation, it cannot start unless you disable UAC. The right answer is to design the app so it does not need elevation in the first place.
• Shell Launcher does not prevent other apps from being launched. It only replaces the shell, so routes such as launching an EXE from a file dialog inside the business app remain. On terminals where you cannot trust whoever is using them, combine it with AppLocker or Keyboard Filter.

6. Operational Design — Auto-Logon, Recovery, Update and Maintenance Access

Choosing an approach and configuring it is not the end. The design that keeps it running unattended is the substance of a kiosk.

For auto-logon, make AutoLogonAccount in the configuration XML your first choice. Windows creates and manages a dedicated local standard user, so there is no password to store.²⁴ The traditional Winlogon registry approach (AutoAdminLogon/DefaultUserName/DefaultPassword) also works, but leaves the password in plain text. And since auto-logon is specified not to work on machines where an EAS password restriction applies, check that it does not conflict with your MDM policy.⁷

When the app falls over, leave the first line of recovery to the OS. An Assigned Access kiosk restarts the app automatically when it closes.¹ Shell Launcher configures recovery via DefaultAction/ReturnCodeActions.⁴ On top of that, scheduling a nightly restart task improves recoverability in the case where “it restarts and keeps falling over on the same exception” (for how to build the task, see “When Task Scheduler Tasks Don’t Run or Exit with 0x1”).

Rather than blocking Windows Update, control when it happens. The officially recommended configuration is to align active hours with business hours, use automatic download plus a scheduled overnight install, and turn off notifications including restart warnings.⁷ Verify on real hardware that after a restart, everything chains automatically through “auto-logon → kiosk restored”. Do the same with power settings: set the sleep and display-off timeouts to 0 (disabled) and disable the power button.⁷ Repurposed laptops and Modern Standby machines have particularly quirky behavior here, so also check “Sleep, Hibernation, Modern Standby, and Long-Running Apps”.

The holes around keyboard and touch differ by approach. On a multi-app kiosk (restricted user experience), Alt+F4, Alt+Tab and Ctrl+Alt+Del are not blocked by default.⁷ Keyboard Filter is what blocks them, suppressing key combinations from both physical and on-screen keyboards (enable it with Dism /online /Enable-Feature /FeatureName:Client-KeyboardFilter; Enterprise family only).⁸ On tablet-style terminals, set the LockDown/AllowEdgeSwipe policy to disabled (0) so that a swipe from the screen edge does not bring up system UI.

Securing maintenance access matters just as much as blocking things. The way out of an Assigned Access kiosk is Ctrl+Alt+Del by default (changeable on Windows 11 with BreakoutSequence), and from there you sign in with an administrator account.² If you block Ctrl+Alt+Del with Keyboard Filter, Keyboard Filter’s own breakout key (by default, pressing the left Windows key five times) becomes your last route to the welcome screen.⁸ Note also that Keyboard Filter is inactive in safe mode and can be exempted for administrator accounts.⁸ The kiosk experience is console-only, but administrative RDP maintenance can run alongside it, so leaving a remote route in place reduces the number of site visits. When something goes wrong, the event log’s “AssignedAccess > Operational” channel is the primary source of information about configuration mistakes.⁷

7. Business Application Design and Practical Standards (Decision Table)

However hard you lock down the OS side, holes remain if the app is still “an ordinary desktop application”. Here are the design requirements for an app you put on a kiosk.

• Maintain full-screen, borderless display yourself. Shell Launcher’s V2:AllAppsFullScreen exists, but fundamentally the app itself should keep itself maximized, topmost and without a title bar, and bring itself back to the foreground when it loses focus.
• Do not show an exit button. Instead of putting any means of closing on screen, expose a maintenance menu through a hidden gesture only maintenance engineers know (for example, tapping the four corners of the screen in order plus a password). If you separate the exit codes, you can coordinate with Shell Launcher’s ReturnCodeActions — “exit from the maintenance menu → do nothing so Explorer can come back”, “exit after an update → restart the machine”.⁴
• Recover from exceptions by yourself. The worst outcome is swallowing an unhandled exception and leaving the screen up but unusable. Write a log, terminate your own process promptly, and let the OS-side restart mechanism (the kiosk’s automatic restart, Shell Launcher’s RestartShell) pick it up.
• Prevent multiple instances. When automatic restart mechanisms overlap with your own restart handling, double launches are easy to trigger. Put mutex-based single-instance protection in place (“Preventing Multiple Instances of a Windows App”).
• Do not require elevation. The kiosk account should be a standard user as a matter of principle, and with Shell Launcher a shell that needs elevation forces you to disable UAC.³ Separate out any processing that needs administrator privileges (“How to Separate Out Only the Operations That Need Administrator Privileges in a Windows App”).

Finally, the decision table.

8. Summary

• “Auto-logon plus a Startup entry” is not a kiosk. As long as Explorer is alive it protects nothing, so use Assigned Access or Shell Launcher.
• Assigned Access is available on Pro and above, and can configure a single-app kiosk (UWP/Edge, and Win32 on Windows 11) and a multi-app restricted user experience.
• Shell Launcher replaces Explorer.exe with your business application. It is limited to the Enterprise / Education / IoT Enterprise family and lets you declare recovery actions per exit code (RestartShell and so on).
• Configuration has been consolidated into the AssignedAccess CSP, and even without MDM you can apply the same XML through the WMI bridge plus PowerShell (running as SYSTEM).
• The backbone of operational design is: automatic sign-in via AutoLogonAccount, recovery via the OS restart mechanism plus a scheduled restart, time control over Windows Update, and securing escape routes through BreakoutSequence, the breakout key and remote maintenance.
• The last line of defense is the business application’s design. Only once it maintains full screen, has no exit button, recovers itself on exception, prevents multiple instances and needs no elevation do you actually have a “PC that runs only one application”.

Related Articles

• Choosing a Windows Edition for Industrial PCs — A Practical Guide to IoT Enterprise LTSC
• Preventing Multiple Instances of a Windows App — Named Mutexes and Activating the Existing Window on a Second Launch
• How to Think About Windows Session Isolation — Session 0, RDP, and Running Multiple Users Concurrently
• Sleep, Hibernation, Modern Standby, and Long-Running Apps — Designing Around ‘It Stopped Overnight’
• When Task Scheduler Tasks Don’t Run or Exit with 0x1 — Isolating the Cause and Designing for Reliable Operation
• How to Separate Out Only the Operations That Need Administrator Privileges in a Windows App

Related Consulting Areas

KomuraSoft LLC handles the selection and configuration of kiosk approaches for reception terminals, factory operator panels and inspection equipment operator screens; the design and development of business applications that stand up to kiosk use (full-screen UI, self-recovery, privilege separation); and the “re-hardening” of existing terminals.

• Windows App Development
• Device Integration & Soft Real-Time Control App Development
• Technical Consulting & Design Review
• Contact Us

References

Related Articles

Recent articles sharing the same tags. Deepen your understanding with closely related topics.

Related Topics

These topic pages place the article in a broader service and decision context.

Frequently Asked Questions

Common questions about the topic of this article.

Can Assigned Access be used on Windows Pro?

Yes. Assigned Access (single-app kiosk and the multi-app restricted user experience) is supported on Pro, Enterprise, Education and IoT Enterprise, including their LTSC variants. Shell Launcher, which replaces Explorer.exe itself with your business application, is available only on the Enterprise / Education / IoT Enterprise family and cannot be used on Pro. Note also that a kiosk experience requires UAC to be enabled and a sign-in from the console; a kiosk experience over a Remote Desktop connection is not supported.

Do I need Shell Launcher to run a Win32 (desktop) app as a kiosk?

Not on Windows 11. Assigned Access on Windows 11 (the 21H2 schema onwards) lets you point the v4:ClassicAppPath attribute of the KioskModeApp element at a desktop application's executable path, so you can configure a single-app kiosk running a Win32 app even on a Pro machine. Assigned Access kiosks on Windows 10 are limited to UWP apps and Microsoft Edge, so if you want to run just one Win32 app there, the realistic options are Shell Launcher (Enterprise family only) or a multi-app configuration using AutoLaunch. Confirm which editions support which approach before you start designing.

Will the kiosk app restart automatically if it terminates unexpectedly?

The behavior differs by approach. An Assigned Access single-app kiosk is specified to restart the app automatically when it is closed. With Shell Launcher, you can declaratively configure what happens when the app you made the shell exits, using DefaultAction and ReturnCodeActions, choosing from RestartShell (restart the shell), RestartDevice (restart the machine), ShutdownDevice and DoNothing. If there is no action defined for the exit code and no DefaultAction either, nothing happens and the machine sits at a black screen — so always define DefaultAction. The application also needs to be designed to terminate itself on an unhandled exception so that the recovery action can take over.

How is a maintenance engineer supposed to sign in as an administrator?

An Assigned Access kiosk experience can be exited with Ctrl+Alt+Del by default, and on Windows 11 you can change that key combination with the BreakoutSequence element. In a configuration where Keyboard Filter blocks Ctrl+Alt+Del as well, you can leave a route back to the welcome screen via Keyboard Filter's own breakout key (by default, pressing the left Windows key five times). The kiosk experience itself is console-only, but administrative maintenance over Remote Desktop with an administrator account can be used alongside it as a separate session. The important thing is not to block every escape route and end up with a terminal that can only be recovered on site.

Is it safe to write the auto-logon password into the registry?

We don't recommend it. The Winlogon AutoAdminLogon approach leaves DefaultPassword in the registry in plain text. Both the Assigned Access and Shell Launcher configuration XMLs have an AutoLogonAccount element, and with it Windows creates and manages a dedicated local standard user itself and signs in automatically, so you never have to store a password yourself. As a rule, make the kiosk account a least-privilege local standard user and avoid reusing a domain account. Also note that auto-logon does not work on machines where an Exchange ActiveSync password restriction policy is in effect.

Author Profile

Profile page for the article author.

Go Komura

Representative of KomuraSoft LLC

Focused on Windows software development, technical consulting, and investigations into failures that are difficult to reproduce.