Kiosk & shared devices
Reception screens, scanners and shared frontline machines are a distinct build type with their own failure modes. This section configures purpose-locked device modes — kiosk profiles, Shared PC mode and shutdown control — in your own Intune tenant.
Why this matters
A reception screen is not a laptop with the wallpaper changed. Left as an ordinary Windows device, a kiosk invites exactly the behaviour it exists to prevent: passers-by close the display app, open a browser, or shut the machine down and nobody notices until the next working day. Shared frontline and classroom devices have the opposite problem — user after user signs in, each leaving a cached profile behind, until the disk fills and sign-ins slow to a crawl.
Most organisations solve this by hand: a local auto-logon account here, a registry tweak there, a Start layout XML found on a forum. It works until the device is reset or replaced, at which point the one person who remembers how it was built has usually moved on. Purpose-locked devices deserve configuration that lives in the tenant, not in someone's head.
What a good build does
Decolla treats kiosk and shared devices as a distinct build type, covered by a focused set of items: assigned-access kiosk profiles (single-app for a locked display, multi-app for scanners and frontline task sets), Shared PC mode for genuinely multi-user machines, and a shutdown-control policy that removes Shut Down and Restart from Start — scoped to kiosk devices only, deliberately.
Each item follows the same discipline as the rest of the catalogue: it appears in a written, itemised plan before anything runs, with its delivery method and reversibility class stated, and anything irreversible flagged for your explicit approval. Shared PC mode is the standing example — it reconfigures profile handling and power behaviour in ways that do not cleanly revert, and the plan says so up front rather than letting you find out later.
One honest caveat: demand evidence for this build type is thinner than for mainstream hardening — documentation plus scattered field reports rather than a chorus — so the newer items here are held at niche popularity in the catalogue instead of being promoted as if every tenant needs them. If you run no kiosks, skip the section; the plan is itemised precisely so you can.
Where it bites people
Two failure modes recur.
- Shared PC mode is effectively one-way. Enabling it changes account management, profile deletion and power settings at a depth that simply unassigning the Intune profile does not undo. Admins pilot it on a normal device, decide against it, remove the profile — and the machine carries on behaving like a shared PC. Its cleanup logic also deletes cached accounts when storage runs low, which is correct for a library machine and catastrophic for anyone who saved work locally. That is precisely why Decolla's plan flags this item's reversibility class before you approve it.
- Shutdown removal scoped too broadly. Apply "remove Shut Down and Restart" across the estate instead of to kiosks only, and ordinary users can no longer restart machines that are overdue an update reboot. The "(kiosk only)" in the item's name is not decoration — it is the scoping lesson baked into the catalogue.
What's in this section (3 items)
| Item | Tier | Delivery | Reversibility |
|---|---|---|---|
| Remove Shut Down/Restart from Start (kiosk only) | Optional | settingsCatalog | auto |
| Kiosk mode (single-app / multi-app assigned access) | Advanced | native | reverse |
| Shared PC mode (multi-user devices) | Advanced | native | reverse |
Reversibility: auto reverses when unassigned · reverse reversible with a documented step · irreversible flagged before you approve the plan.
See it on a real device.
Decolla is in private build — early-access members see a build defined, deployed and rolled back first.
Get early access