Kiosk and Shared Device Security Guide: Locking Down Multi-User Endpoints

Kiosks and shared devices break the one-user, one-device assumption that most endpoint and identity controls are built on. A self-service check-in terminal, a ward tablet passed between nurses, a warehouse scanner used on three shifts and a library PC all face the same problems: anyone can touch them, they often sign in automatically, and the previous user's session, files or tokens can be left behind for the next person. This guide covers the platform features that lock these devices down (Windows Assigned Access and Shared PC, Android Enterprise dedicated devices, Apple Single App Mode and Shared iPad, ChromeOS kiosks and managed guest sessions), how to handle the shared accounts behind them, and how to roll out, monitor and audit the result. It is written for endpoint engineers, identity teams and security architects responsible for frontline, retail, healthcare, education and public-facing estates.

Key takeaways

• Decide the device pattern first. A public single-app kiosk, a dedicated work device and a shared multi-user device need different platform modes, accounts and data-wiping rules.
• Use the platform lockdown, not a custom shell. Assigned Access, Android lock task mode, Apple App Lock and Chrome kiosk apps are enforced by the operating system and survive restarts far better than a full-screen app pretending to be a kiosk.
• Shared accounts destroy accountability. Replace shared passwords on multi-user devices with individual sign-in plus fast session switching, and keep auto-logon accounts limited to public kiosks that hold no sensitive access.
• Session end is the security boundary. Every shared device needs a defined, tested way to clear the previous user's data, cookies and tokens: ephemeral sessions, profile deletion, single sign-out or a wipe.
• Treat kiosks as untrusted in the network. Physical access, exposed USB ports and long-lived devices mean kiosks belong in their own segment with tight egress rules and managed patching.

Three patterns: public kiosk, dedicated device and shared device

Most failures start with picking the wrong mode. Classify every device before choosing settings.

A useful rule: if the device needs access to anything a member of the public should not see, it is not a public kiosk, and it needs individual sign-in.

Shared accounts: where identity fits

Shared devices are where generic accounts survive longest. A "ward1" or "store-tablet" account with a password on a sticky note gives every holder the same access, cannot be offboarded for one leaver and leaves an audit trail that names nobody. NIST SP 800-53 Rev. 5 control IA-2(5) "Individual Authentication with Group Authentication" addresses exactly this: where a group account is used, individuals should be authenticated individually first. Attackers value these accounts because they are rarely monitored and rarely rotated; MITRE ATT&CK tracks this under Valid Accounts (T1078), including Default Accounts (T1078.001) and Local Accounts (T1078.003).

• Kiosk auto-logon accounts: acceptable only for public kiosks. Make them local, standard (non-admin) accounts with no network credentials, no mailbox and no cloud licence. Treat the account as a non-human identity with an owner and a documented purpose. See the Service Account Security Guide.
• Individual sign-in on shared devices: use the identity provider rather than a device password. Microsoft Entra shared device mode on iOS, iPadOS and Android gives single sign-in and single sign-out across supporting apps, so one sign-out ends every app session, and Conditional Access can require the shared device to be enrolled and compliant.
• Fast, phishing-resistant sign-in: badge tap, FIDO2 security keys or short PIN plus a device-bound credential make individual sign-in practical for shift workers. See the Passwordless and Passkeys Guide and the Bluetooth, RFID and NFC Security Guide.
• Local administrator accounts: kiosks still have them. Randomise and rotate them per device. See the LAPS Guide.
• Device and enrolment credentials: MDM enrolment tokens, Wi-Fi pre-shared keys and kiosk app API keys are machine credentials. Store them in the management platform or a vault, not in kiosk app configuration files.

Windows: Assigned Access and Shared PC

Assigned Access

Assigned Access is supported on Windows 10 and Windows 11 Pro, Enterprise, Enterprise LTSC, Education, IoT Enterprise and IoT Enterprise LTSC. It has two modes.

• Kiosk experience: one Universal Windows Platform app or Microsoft Edge runs full screen above the lock screen, and restarts automatically if closed. It requires User Account Control to be enabled and only works from a console sign-in, not over Remote Desktop.
• Restricted user experience: users get a familiar desktop but can run only a defined list of apps, with a tailored Start menu and taskbar. Configurations can differ per user, which suits frontline, student and lab devices. Assigned Access generates AppLocker rules for the targeted user; do not create AppLocker rules that conflict with them.
• What gets locked: Assigned Access applies device-level settings to every user, including administrators (for example hiding networks on the logon screen and update notifications), and user-level settings to the targeted account, such as Remove Task Manager, Remove Run menu from Start Menu and Prevent access to drives from My Computer. Shortcuts such as Ctrl+Shift+Esc, Win+R, Win+E, Win+I and Win+X are blocked.
• Edge kiosks: with Microsoft Edge as the kiosk app, extra policies restrict the account to msedge.exe, turn off toast notifications and set the default risk level for file attachments to High risk. Pair this with a URL allow list so the browser cannot reach arbitrary sites. See the Enterprise Browser and Browser Security Guide.

Shared PC mode

Shared PC is configured through the SharedPC configuration service provider (./Vendor/MSFT/SharedPC/). The settings that matter for security:

For full lockdown of a device that runs a line-of-business desktop app rather than a UWP app or Edge, combine the restricted user experience with application control. See the Application Allowlisting Guide and the Windows Endpoint Hardening Guide.

Android Enterprise dedicated devices

Android Enterprise calls single-purpose, company-owned devices "dedicated devices" (formerly COSU). They are fully managed by a device policy controller (DPC), whether a custom DPC, the Android Management API or an EMM, and are typically enrolled by QR code after a factory reset.

• Lock task mode: the DPC allow-lists packages with setLockTaskPackages(); only those apps can run. By default the status bar is blank, Home and Overview are hidden, the lock screen is disabled and other apps cannot launch activities.
• System UI features: from Android 9, setLockTaskFeatures() re-enables specific features. LOCK_TASK_FEATURE_GLOBAL_ACTIONS (the power menu) is the only one on if the call is never made; LOCK_TASK_FEATURE_KEYGUARD is usually unsuitable for public kiosks; LOCK_TASK_FEATURE_NOTIFICATIONS and LOCK_TASK_FEATURE_OVERVIEW require LOCK_TASK_FEATURE_HOME. Enable the minimum.
• Exiting: the DPC ends lock task mode remotely by removing the package from the allow list. If the kiosk app itself can call stopLockTask(), protect that path behind an administrator action.
• Shared shifts: dedicated devices can use ephemeral or secondary users so each shift starts clean, and app package caching avoids re-downloading apps for each temporary user.
• Updates: a system update policy can freeze OS updates during critical periods; keep freeze windows short and documented so devices do not fall behind.

See the Android Enterprise Security Guide for work profile and fully managed modes.

Apple: Single App Mode and Shared iPad

• App Lock (Single App Mode): the com.apple.app.lock payload locks a device to one app until the profile is removed, and the device returns to that app after wake or restart. It requires supervision on iOS and tvOS and should only be pushed after the target app is installed.
• Autonomous Single App Mode: lets an approved app enter and leave single app mode itself, for example an exam or check-in app; restrict it to apps you control.
• Shared iPad: requires supervision, a device management service and organisation-owned Managed Apple Accounts, and at least 32 GB of storage. Users sign in with their own account so data stays separate.
• Temporary sessions: from iPadOS 13.4, anyone can tap Guest without credentials, and all their data, including browsing history, is deleted at log out. From iPadOS 17 the QuotaSize key can reserve storage for the temporary user. Apple has also announced an authenticated guest mode in which users sign in with a Managed Apple Account and local data is removed at sign-out.
• Supervision is the foundation: most kiosk controls are unavailable on unsupervised devices, so enrol shared iPhones and iPads through automated device enrolment. See the iOS and iPadOS Enterprise Security Guide.

ChromeOS kiosks and web app kiosks

• Kiosk apps: in the Google Admin console (Devices > Chrome > Apps & extensions > Kiosks) an app can be set as the Auto-launch app, so the device loads it immediately at start-up with no user session.
• Managed guest sessions: let people use a managed Chromebook without signing in to a Google Account. Session data is erased when they exit. Settings include Maximum user session length, idle settings, and controls for Incognito mode, screenshots, URL blocking, printing and external storage.
• Enrolment: both require enterprise-enrolled devices. See the ChromeOS and Chromebook Security Guide.
• Web app kiosks on any platform: a browser kiosk is only as safe as its URL allow list. Block downloads, developer tools, new windows, file pickers and external protocol handlers, and make sure the web application times out its own session, because a browser restart does not always clear server-side sessions. See the Session Hijacking and Cookie Theft Guide.

Physical, network and data hardening

• Network segmentation: put kiosks in a dedicated VLAN or SSID, allow egress only to the services the kiosk app needs plus management and update endpoints, and deny lateral access to corporate subnets.
• Disk encryption and secure boot: devices in public places get stolen; full-disk encryption and firmware passwords stop offline tampering. See the Lost or Stolen Device Response Checklist.
• EDR still applies: a locked-down kiosk is still a Windows, Android or Apple endpoint and should report to EDR or MTD where the platform supports it. See the EDR Guide and the Mobile Threat Defense Buyer's Guide.

Choosing an approach

• Single app versus restricted multi-app: choose a single-app kiosk whenever the use case allows it; every extra app is another breakout path. Use a restricted multi-app experience only for staff devices that genuinely need several tools.
• Auto-logon versus individual sign-in: auto-logon only where the kiosk reaches nothing sensitive. As soon as the device touches personal, patient, payment or employee data, require individual sign-in with fast authentication.
• Ephemeral versus cached profiles: ephemeral (DeletionPolicy 0, Apple temporary sessions, Android ephemeral users, Chrome managed guest sessions) gives the strongest isolation; caching speeds sign-in but leaves data on disk, so pair it with encryption and short inactive thresholds.
• Small versus large estates: a small organisation with a handful of kiosks can use the built-in mode in its existing MDM with a single baseline profile. Large estates need device groups per pattern, staged update rings, inventory reconciliation and a named owner for every kiosk account and app.

How to implement

1. Inventory and classify: list every kiosk and shared device, its location, owner, pattern (public, dedicated, shared), operating system and current sign-in method. Flag every generic account.
2. Build one baseline per pattern and platform: lockdown mode, allowed apps or URLs, account model, data deletion setting, idle timeout, USB and storage controls, update window, network segment.
3. Lab test breakout: try keyboard shortcuts, long presses, accessibility features, print dialogs, file open and save dialogs, help links, error pages, external protocol links and power cycling. Each must return to the kiosk app and never to a desktop, browser or settings screen.
4. Test session clearing: sign in as user A, use every app, sign out, then sign in as user B and look for A's files, browser history, autofill, cookies and app tokens. Repeat after sleep and after a crash.
5. Pilot ring: deploy to a few devices per site for two weeks, with staff feedback and help desk ticket tracking. Where the platform has an audit or report-only option for application control, use it first.
6. Roll out in waves by site or device group through the MDM, with the previous profile kept so a group can be reverted by reassigning it.
7. Retire shared passwords: once individual sign-in works, disable the generic accounts and record the date.
8. Rollback plan: document how to remove the lockdown profile or lock task allow list remotely, and keep a local break-glass procedure (with a LAPS-managed administrator password) for devices that lose connectivity.

Detection and measurement

• What to log: sign-ins and sign-outs on shared devices (on Windows, Security log events 4624 and 4634 for logon and logoff, and 4625 for failures), kiosk app crashes and restarts, profile changes, USB device connections, lockdown profile removals and devices dropping out of compliance in the MDM.
• What to alert on: interactive sign-in by an administrator on a kiosk, use of the kiosk account anywhere other than its own device, kiosk devices contacting destinations outside the allow list, lockdown profiles removed outside a change window.

Metrics that show the programme is working:

1. Percentage of shared and kiosk devices running a platform lockdown mode with the current baseline.
2. Number of generic shared accounts remaining, trending to zero outside public kiosks.
3. Percentage of shared devices with a verified session-clearing test in the last quarter.
4. Median patch age of kiosk and shared devices against the general fleet.
5. Kiosk breakout findings from the last test or penetration test, and time to fix.
6. Kiosk devices that have not checked in with management for more than 14 days.

Framework mapping

Common failure patterns

• A full-screen app is not a kiosk: launching an app in full screen on a normal desktop session leaves Task Manager, file dialogs and shortcuts available. Use the platform lockdown mode.
• Browser kiosk without an allow list: a help link or an error page opens the open internet, then a download, then a file dialog onto the local disk.
• Shared accounts with real access: a ward or store account signed in to clinical, payroll or retail systems all day, with a password unchanged since deployment and shared by dozens of people. When it is phished or abused, logs cannot show who did what.
• Session clearing assumed, not tested: profiles cached by default, browser cookies surviving sign-out, or a native app that keeps its token after the device user changes. Entra shared device mode, for example, relies on apps clearing their own cached user data at sign-out.
• Forgotten devices: kiosks deployed by facilities or a vendor, outside the MDM, with old operating systems and no owner. Inventory reconciliation catches them.
• Kiosks on the corporate network: a public terminal with exposed ports on the same flat network as staff laptops gives anyone in the lobby a foothold.

Practitioner checklist

• Inventory every kiosk and shared device and classify it as public kiosk, dedicated device or shared multi-user device, with a named owner.
• Apply the operating system's own lockdown mode (Assigned Access, lock task mode, App Lock, Chrome kiosk) rather than a custom shell.
• Restrict auto-logon kiosk accounts to local, standard accounts with no network, mail or cloud access.
• Replace generic shared accounts on staff devices with individual, phishing-resistant sign-in and single sign-out.
• Configure and test session clearing: profile deletion, ephemeral users, temporary sessions or managed guest sessions.
• Set idle timeouts, sign-in on resume and short session lifetimes in both the device and the web applications.
• Cover or disable unused ports, enforce USB device control and full-disk encryption.
• Place kiosks in a segmented network with egress restricted to required services.
• Run a breakout and session-leakage test before rollout and after every major OS or app update.
• Track the six metrics above and review generic accounts quarterly.

Standards and references

• NIST: SP 800-53 Rev. 5 Security and Privacy Controls
• Microsoft Learn: What is Assigned Access?
• Microsoft Learn: SharedPC CSP
• Android Developers: Lock task mode
• Apple Developer: AppLock
• Apple Platform Deployment: Shared iPad overview
• Microsoft Learn: Shared device mode overview
• Google ChromeOS Admin Help: Kiosk apps and managed guest sessions for assessments

Related NHI Mgmt Group resources: Mobile Device Security Guide · Endpoint Security Guide · Passwordless and Passkeys Guide · Conditional Access Guide · Endpoint Security Maturity Model