Zero Trust ArchitectureOctober 30, 20262 views

Why kiosk and shared PCs only allow approved apps to open

guide9 min

This guide is for teams using shared desks, front-desk terminals, exam stations, warehouse PCs, or public kiosks and wondering why the machine is locked down to a short list of apps. You’ll learn what this control actually does, how it fits into Zero Trust, when it is worth the friction, and what a practical setup looks like on common platforms.

zero-trustkiosk-modeshared-computersapplication-allowlistingapplockerdevice-management

TL;DR — On a shared or kiosk computer, limiting which apps can open is one of the simplest Zero Trust controls: the device should only do the one or two jobs it exists for, and nothing else. The most likely right answer is to use your device-management tool to put the machine into kiosk mode or apply an application allowlist (a list of approved programs), then test with a real user workflow before rollout. Reading time: ~7 min

What it is and where it sits

When we limit which apps can be opened on a shared or kiosk computer, we are applying application allowlisting (only approved apps can run) instead of the older, weaker pattern of blacklisting (trying to block known bad apps one by one).

In Zero Trust Architecture, this sits at the device control layer. The idea is simple: do not trust the computer just because it is inside your office or on your Wi‑Fi. Trust the specific action the device is allowed to perform.

For a kiosk, that action might be:

open one web browser in full-screen mode to a check-in page
print labels from one warehouse app
run one point-of-sale application
let a patient fill out a form, but not browse the web or open email

What talks to it

In a typical setup, several pieces work together:

Device management tool (software that pushes settings to PCs), such as Microsoft Intune, Windows Group Policy, Apple device management, or your Linux desktop management stack
Identity provider (the sign-in system), such as Microsoft Entra ID, Google Workspace, or Okta
The approved app itself, often a browser pointed at one internal web app
The operating system (Windows, macOS, Linux), which actually enforces what can launch

What it replaces

This replaces a risky assumption: “people will only use the machine for the intended task.” It also replaces the impossible maintenance burden of trying to block every unwanted app, website, installer, USB tool, and remote access utility after the fact.

Where it lives in the flow

This control lives on the endpoint (the actual computer), but it supports controls higher up the stack. Even if your app requires login, a shared machine can still leak data through screenshots, file downloads, browser history, saved passwords, or someone opening a second app.

Diagram

View as text

[User] ---- 1. signs in / starts session ----> [Shared PC]
[Shared PC] ---- 2. policy check: allowed app? ----> [OS policy]
[OS policy] ---- 3. allow only kiosk browser ----> [Approved App]
[Approved App] ---- 4. authenticate ----> [Identity Provider]
[Approved App] ---- 5. use business app ----> [Business Service]
[User] ---- 6. tries File Explorer / email ----> [Shared PC]
[Shared PC] ---- 7. blocked by allowlist ----> [OS policy]

The key architectural point: this is not mainly an app feature. It is a device boundary. Your web app, identity system, and network rules all help, but the local machine still needs a rule saying, “Only these apps may run here.”

How it actually works

Under the hood, the operating system checks a policy before launching a program. That policy can be based on:

the app’s file path (where it lives on disk)
the app’s publisher signature (who signed it)
a file hash (a fingerprint of the exact file)
the user account or device group the rule applies to

For kiosks, there are two common models:

Single-app kiosk: the device opens one app and little else.
Multi-app restricted device: a few approved apps are available, such as a browser, print helper, and accessibility tool.

End-to-end example: front-desk visitor check-in PC

Let’s walk one realistic example through the system.

A company has a Windows PC in the lobby. Visitors should only be able to check in using a browser pointed at https://checkin.example.com. Staff do not use this PC for email, Teams, downloads, or general web browsing.

Step 1: The device is enrolled and tagged

The PC is enrolled in the company’s device-management system and placed in a group like Lobby-Kiosks.

That group matters because policies should target only the kiosk devices, not every laptop in the company.

Step 2: A kiosk or allowlist policy is assigned

The admin creates a policy that:

signs in automatically with a local kiosk account or restricted user account
launches Microsoft Edge or Chrome in kiosk/full-screen mode
opens only the check-in site
blocks File Explorer, command prompt, email clients, settings panels, and arbitrary installers
optionally clears browser data at sign-out or restart

Step 3: The user interacts with the machine

A visitor taps the screen. The browser is already open to the check-in page.

If they try to:

press keys to open another app
click a downloaded file
open a mail link
browse to a different site

…the OS policy or browser kiosk policy blocks it.

Step 4: The approved app still uses normal security upstream

The browser reaches the check-in web app. That app may still use:

HTTPS (encrypted web traffic)
identity checks for staff-only pages
role-based access (different permissions for different users)
server-side logging and rate limits

This is important: app restrictions on the PC do not replace app security. They reduce what the endpoint can do if someone misuses it.

Step 5: Recovery and maintenance are controlled

When IT needs to update the browser or rotate settings, they do it through device management. If the machine drifts from the approved state, the management tool can reapply the policy.

That is why this control is practical at scale: it is not just “lock down this one computer manually.” It is “define a role for this device and keep it in that role.”

When to use it (and when not to)

Use this control when the computer has a narrow purpose, multiple users, or elevated risk if someone opens the wrong thing.

Scenario	Recommendation
Public-facing kiosk, reception desk, check-in terminal	Yes — use single-app kiosk mode if possible
Shared warehouse or factory PC used for 2-4 known apps	Yes — use a small app allowlist
Exam/testing machine	Yes — combine allowlisting with browser restrictions and session reset
Point-of-sale or label-printing station	Yes — lock to the POS/browser/print tools only
Normal employee laptop used for many tasks	Usually no — this is often too restrictive; use standard endpoint security instead
Developer workstation	No — developers need broad tool access; use least privilege and monitoring instead
Executive or knowledge-worker desktop	Usually no — focus on identity, patching, disk encryption, and endpoint detection

You probably don’t need this if...

the device is assigned to one trained employee and used for many legitimate tasks
your problem is really web access control, not local app launching
users constantly need new tools and plugins to do their jobs
you do not have a way to centrally manage exceptions and updates

In those cases, strict allowlisting can create more support tickets than security value.

Trade-offs

This control is useful precisely because it is restrictive. That also creates cost.

Benefit	What it costs
Greatly reduces accidental misuse on shared machines	More setup time to define exactly which apps are allowed
Limits malware paths like random downloads and unauthorized tools	Ongoing maintenance when apps update, move, or change signatures
Easier compliance story for kiosks and public terminals	More testing needed before rollout to avoid blocking real work
Smaller attack surface (fewer things can run)	User frustration if the device is sometimes expected to do “just one extra thing”
Clear device purpose and easier support	Potential vendor or platform lock-in if you rely heavily on one management stack
Helps contain damage if one session is abused	Does not replace app security, browser hardening, patching, or physical security

A practical rule: the narrower the device purpose, the better this control fits. The broader the purpose, the more painful it becomes.

In practice

Below are two examples you can adapt. The first is the dashboard-first route most teams should use. The second is a command example for Windows when you need to understand the moving parts.

Example 1: Windows kiosk setup with a browser command

In your device-management dashboard, look for a kiosk or assigned-access profile. Vendor menus vary, but it is usually under something like:

Devices → Configuration profiles → Create profile → Kiosk
or Devices → Windows → Device restrictions / Templates → Kiosk

Use a browser launch command like this:

msedge.exe --kiosk https://checkin.example.com --edge-kiosk-type=fullscreen --no-first-run

This opens Edge in full-screen kiosk mode directly to your check-in site. The gotcha: if your workflow needs pop-ups, printing, camera access, or file upload, test those explicitly because kiosk browser policies often block them by default.

Example 2: Windows AppLocker allowlist rule via PowerShell

⚠️ If you apply an application control policy too broadly, you can block legitimate apps and lock users out of work. Test on one non-critical device or a pilot group first.

If you manage Windows with Group Policy or local policy, AppLocker is a common built-in way to allow only approved apps. This example creates a default rule set and then lets you build from there:

New-AppLockerPolicy -DefaultRule -XMLPolicy C:\Temp\AppLocker-Default.xml
Set-AppLockerPolicy -XMLPolicy C:\Temp\AppLocker-Default.xml -Local
Get-AppLockerPolicy -Local | Select-Object -ExpandProperty RuleCollections

This generates and applies a basic local AppLocker policy, then shows the active rule collections. The gotcha: default rules are only a starting point; if you stop there, users may still have more access than you intended, so add explicit allow rules for the kiosk apps and test blocked behavior.

Example 3: Chrome policy file for a Linux kiosk session

On Linux kiosks, a common pattern is to auto-launch Chrome or Chromium with managed policies. A policy file may look like this:

{
  "HomepageLocation": "https://checkin.example.com",
  "HomepageIsNewTabPage": false,
  "RestoreOnStartup": 4,
  "RestoreOnStartupURLs": ["https://checkin.example.com"],
  "IncognitoModeAvailability": 1,
  "BrowserGuestModeEnabled": false,
  "DeveloperToolsAvailability": 2
}

This tells Chrome to start on the check-in page and disables some escape hatches like guest mode and developer tools. The gotcha: browser policy alone is not enough for a true kiosk; users may still switch apps unless the desktop session or OS also restricts what can launch.

Have a project in mind?

Get an instant AI price estimate for it, or talk directly to our team.

Get an instant estimate Talk to us

One email a month on what we learn building with AI

Back to Knowledge Base

Zero Trust ArchitectureOctober 30, 20262 views

Why kiosk and shared PCs only allow approved apps to open

guide9 min

zero-trustkiosk-modeshared-computersapplication-allowlistingapplockerdevice-management

TL;DR — On a shared or kiosk computer, limiting which apps can open is one of the simplest Zero Trust controls: the device should only do the one or two jobs it exists for, and nothing else. The most likely right answer is to use your device-management tool to put the machine into kiosk mode or apply an application allowlist (a list of approved programs), then test with a real user workflow before rollout. Reading time: ~7 min

What it is and where it sits

For a kiosk, that action might be:

open one web browser in full-screen mode to a check-in page
print labels from one warehouse app
run one point-of-sale application
let a patient fill out a form, but not browse the web or open email

What talks to it

In a typical setup, several pieces work together:

Device management tool (software that pushes settings to PCs), such as Microsoft Intune, Windows Group Policy, Apple device management, or your Linux desktop management stack
Identity provider (the sign-in system), such as Microsoft Entra ID, Google Workspace, or Okta
The approved app itself, often a browser pointed at one internal web app
The operating system (Windows, macOS, Linux), which actually enforces what can launch

What it replaces

Where it lives in the flow

Diagram

View as text

[User] ---- 1. signs in / starts session ----> [Shared PC]
[Shared PC] ---- 2. policy check: allowed app? ----> [OS policy]
[OS policy] ---- 3. allow only kiosk browser ----> [Approved App]
[Approved App] ---- 4. authenticate ----> [Identity Provider]
[Approved App] ---- 5. use business app ----> [Business Service]
[User] ---- 6. tries File Explorer / email ----> [Shared PC]
[Shared PC] ---- 7. blocked by allowlist ----> [OS policy]

How it actually works

Under the hood, the operating system checks a policy before launching a program. That policy can be based on:

the app’s file path (where it lives on disk)
the app’s publisher signature (who signed it)
a file hash (a fingerprint of the exact file)
the user account or device group the rule applies to

For kiosks, there are two common models:

Single-app kiosk: the device opens one app and little else.
Multi-app restricted device: a few approved apps are available, such as a browser, print helper, and accessibility tool.

End-to-end example: front-desk visitor check-in PC

Let’s walk one realistic example through the system.

Step 1: The device is enrolled and tagged

The PC is enrolled in the company’s device-management system and placed in a group like Lobby-Kiosks.

That group matters because policies should target only the kiosk devices, not every laptop in the company.

Step 2: A kiosk or allowlist policy is assigned

The admin creates a policy that:

signs in automatically with a local kiosk account or restricted user account
launches Microsoft Edge or Chrome in kiosk/full-screen mode
opens only the check-in site
blocks File Explorer, command prompt, email clients, settings panels, and arbitrary installers
optionally clears browser data at sign-out or restart

Step 3: The user interacts with the machine

A visitor taps the screen. The browser is already open to the check-in page.

If they try to:

press keys to open another app
click a downloaded file
open a mail link
browse to a different site

…the OS policy or browser kiosk policy blocks it.

Step 4: The approved app still uses normal security upstream

The browser reaches the check-in web app. That app may still use:

HTTPS (encrypted web traffic)
identity checks for staff-only pages
role-based access (different permissions for different users)
server-side logging and rate limits

This is important: app restrictions on the PC do not replace app security. They reduce what the endpoint can do if someone misuses it.

Step 5: Recovery and maintenance are controlled

When IT needs to update the browser or rotate settings, they do it through device management. If the machine drifts from the approved state, the management tool can reapply the policy.

That is why this control is practical at scale: it is not just “lock down this one computer manually.” It is “define a role for this device and keep it in that role.”

When to use it (and when not to)

Use this control when the computer has a narrow purpose, multiple users, or elevated risk if someone opens the wrong thing.

Scenario	Recommendation
Public-facing kiosk, reception desk, check-in terminal	Yes — use single-app kiosk mode if possible
Shared warehouse or factory PC used for 2-4 known apps	Yes — use a small app allowlist
Exam/testing machine	Yes — combine allowlisting with browser restrictions and session reset
Point-of-sale or label-printing station	Yes — lock to the POS/browser/print tools only
Normal employee laptop used for many tasks	Usually no — this is often too restrictive; use standard endpoint security instead
Developer workstation	No — developers need broad tool access; use least privilege and monitoring instead
Executive or knowledge-worker desktop	Usually no — focus on identity, patching, disk encryption, and endpoint detection

You probably don’t need this if...

the device is assigned to one trained employee and used for many legitimate tasks
your problem is really web access control, not local app launching
users constantly need new tools and plugins to do their jobs
you do not have a way to centrally manage exceptions and updates

In those cases, strict allowlisting can create more support tickets than security value.

Trade-offs

This control is useful precisely because it is restrictive. That also creates cost.

Benefit	What it costs
Greatly reduces accidental misuse on shared machines	More setup time to define exactly which apps are allowed
Limits malware paths like random downloads and unauthorized tools	Ongoing maintenance when apps update, move, or change signatures
Easier compliance story for kiosks and public terminals	More testing needed before rollout to avoid blocking real work
Smaller attack surface (fewer things can run)	User frustration if the device is sometimes expected to do “just one extra thing”
Clear device purpose and easier support	Potential vendor or platform lock-in if you rely heavily on one management stack
Helps contain damage if one session is abused	Does not replace app security, browser hardening, patching, or physical security

A practical rule: the narrower the device purpose, the better this control fits. The broader the purpose, the more painful it becomes.

In practice

Below are two examples you can adapt. The first is the dashboard-first route most teams should use. The second is a command example for Windows when you need to understand the moving parts.

Example 1: Windows kiosk setup with a browser command

In your device-management dashboard, look for a kiosk or assigned-access profile. Vendor menus vary, but it is usually under something like:

Devices → Configuration profiles → Create profile → Kiosk
or Devices → Windows → Device restrictions / Templates → Kiosk

Use a browser launch command like this:

msedge.exe --kiosk https://checkin.example.com --edge-kiosk-type=fullscreen --no-first-run

Example 2: Windows AppLocker allowlist rule via PowerShell

⚠️ If you apply an application control policy too broadly, you can block legitimate apps and lock users out of work. Test on one non-critical device or a pilot group first.

If you manage Windows with Group Policy or local policy, AppLocker is a common built-in way to allow only approved apps. This example creates a default rule set and then lets you build from there:

New-AppLockerPolicy -DefaultRule -XMLPolicy C:\Temp\AppLocker-Default.xml
Set-AppLockerPolicy -XMLPolicy C:\Temp\AppLocker-Default.xml -Local
Get-AppLockerPolicy -Local | Select-Object -ExpandProperty RuleCollections

Example 3: Chrome policy file for a Linux kiosk session

On Linux kiosks, a common pattern is to auto-launch Chrome or Chromium with managed policies. A policy file may look like this:

{
  "HomepageLocation": "https://checkin.example.com",
  "HomepageIsNewTabPage": false,
  "RestoreOnStartup": 4,
  "RestoreOnStartupURLs": ["https://checkin.example.com"],
  "IncognitoModeAvailability": 1,
  "BrowserGuestModeEnabled": false,
  "DeveloperToolsAvailability": 2
}

Have a project in mind?

Get an instant AI price estimate for it, or talk directly to our team.

Get an instant estimate Talk to us

One email a month on what we learn building with AI

Why kiosk and shared PCs only allow approved apps to open

What it is and where it sits

What talks to it

What it replaces

Where it lives in the flow

How it actually works

End-to-end example: front-desk visitor check-in PC

Step 1: The device is enrolled and tagged

Step 2: A kiosk or allowlist policy is assigned

Step 3: The user interacts with the machine

Step 4: The approved app still uses normal security upstream

Step 5: Recovery and maintenance are controlled

When to use it (and when not to)

You probably don’t need this if...

Trade-offs

In practice

Example 1: Windows kiosk setup with a browser command

Example 2: Windows AppLocker allowlist rule via PowerShell

Example 3: Chrome policy file for a Linux kiosk session

Further reading

Have a project in mind?

Why kiosk and shared PCs only allow approved apps to open

What it is and where it sits

What talks to it

What it replaces

Where it lives in the flow

How it actually works

End-to-end example: front-desk visitor check-in PC

Step 1: The device is enrolled and tagged

Step 2: A kiosk or allowlist policy is assigned

Step 3: The user interacts with the machine

Step 4: The approved app still uses normal security upstream

Step 5: Recovery and maintenance are controlled

When to use it (and when not to)

You probably don’t need this if...

Trade-offs

In practice

Example 1: Windows kiosk setup with a browser command

Example 2: Windows AppLocker allowlist rule via PowerShell

Example 3: Chrome policy file for a Linux kiosk session

Further reading

Have a project in mind?