MS Kiosk?
Microsoft gives you the parts. XPC gives you the finished endpoint.
Microsoft provides capable, well-documented kiosk primitives. XPC is not a replacement for Windows or a criticism of those primitives — it is the difference between owning an ongoing lockdown engineering project and deploying a purpose-built, centrally managed Citrix and RDP endpoint experience.
The honest question
"Can't we just use Microsoft kiosk mode?"
Often, yes — technically. Microsoft supplies Assigned Access, Shell Launcher, Microsoft Edge policies and application control, and they are genuinely capable building blocks.
The real question is not whether Microsoft can lock down a PC. It is whether your organisation wants to design, build, test, document and maintain a bespoke endpoint lockdown architecture for a Citrix or RDP endpoint — forever.
XPC exists because most organisations do not want the ongoing project. They want the endpoint.
Two paths
The same destination. Very different amounts of work.
Both paths keep Windows. Only one of them makes your team the permanent owner of a lockdown architecture.
Do-it-yourself Microsoft kiosk engineering
You own every link in this chain
Every element above is a decision your team designs, documents, tests and re-tests after each Windows, Edge, Citrix or plug-in release.
The XPC chain
Three steps to a working endpoint
- Log in to the XPC Cloud Portal
- Install the XPC MSI package
- Enable XPC Mode
Windows, Citrix Workspace, your RMM, your endpoint security and your peripherals all stay exactly where they are.
Microsoft's approaches
Three different Microsoft options — each with its own scope.
Choosing between them is the first architectural decision, and it determines how much engineering follows.
Assigned Access — single app
Designed to run Microsoft Edge or an eligible packaged / UWP application full screen for a single purpose.
- Digital signage
- Simple public web terminals
- Simple single-purpose kiosks
But is your Citrix endpoint really one application?
Assigned Access — restricted user experience
Allows a defined group of applications while loading a restricted Windows desktop experience. This is the more realistic Microsoft approach for a Citrix endpoint.
- Microsoft Edge
- Citrix Workspace
- Citrix helper processes
- Authentication components
- Teams and Zoom VDI optimisation components
- Selected Windows functionality
The moment you move here, you are no longer configuring one kiosk app. You are designing an application-control environment.
Microsoft Shell Launcher
A separate Microsoft feature that replaces Explorer.exe with a specified application, subject to Windows edition requirements.
- A different Microsoft feature to Assigned Access
- Has Windows edition requirements
- It is not the same thing as XPC Mode
- XPC does not rely on it
XPC customers should not need to change Windows edition merely because Microsoft's Shell Launcher is unavailable to them.
The hidden project
A Citrix endpoint is not one application.
It is a browser, an authentication chain, a locally installed Citrix Workspace, helper processes, VDI optimisation plug-ins, peripherals and a set of Windows controls that real users still need.
What the project really contains
Everything below has to be decided, built, tested and maintained.
None of this is a Microsoft limitation. It is simply the size of the work when a general-purpose operating system is asked to behave like a purpose-built access appliance.
User self-service
The part most kiosk projects discover late.
Windows already supports these devices. The difficulty is exposing exactly the right controls inside a restricted experience — and nothing else.
| User need | Where Windows exposes it today | XPC self-service |
|---|---|---|
| Change microphone | Settings › System › Sound › Input › device selection (plus advanced audio options) | Audio |
| Wrong headset selected | Settings › System › Sound › Output, or a vendor audio utility | Audio |
| Speaker not working | Settings › System › Sound › Output › device properties | Audio |
| Add an external display | Settings › System › Display › multiple-display arrangement | Display |
| Change resolution | Settings › System › Display › Display resolution | Display |
| Change scaling | Settings › System › Display › Scale & layout | Display |
| Join Wi-Fi | Quick settings or Settings › Network & internet › Wi-Fi | Network |
| Pair Bluetooth device | Settings › Bluetooth & devices › Add device | Devices |
| Add or select a printer | Settings › Bluetooth & devices › Printers & scanners | Devices |
| Webcam not detected | Settings › Bluetooth & devices › Cameras, or Device Manager | Devices |
| Keyboard or language | Settings › Time & language › Language & region | Devices |
| Accessibility option | Settings › Accessibility › several sub-pages | Devices |
Decisions a DIY build must make
- Which Settings pages remain available?
- Which Control Panel applets remain available?
- Does the system tray remain available?
- Can users launch device-vendor utilities?
- Do those controls expose unrelated settings?
- What happens if Microsoft moves them in a future Windows release?
How XPC handles it
Four grouped panels — Audio, Display, Network and Devices — present only the endpoint controls the organisation approves.
Users solve their own headset, monitor, Wi-Fi and printer problems without navigating Windows Settings and without a service-desk ticket.
Operational value
Small tickets, repeated at scale, are the real cost.
Wrong microphone. Wrong monitor arrangement. Wrong default printer. Individually trivial; across a fleet, a permanent line item on the service desk.
Illustrative scale
What avoidable endpoint tickets look like across a fleet.
These figures are illustrative and deliberately conservative. They are here to frame the shape of the saving, not to quote it.
| Endpoints | Avoidable tickets / year | Support hours recovered | Relative scale |
|---|---|---|---|
| 500 | 250 | 21 hrs | |
| 2,500 | 1,250 | 104 hrs | |
| 10,000 | 5,000 | 417 hrs | |
| 50,000 | 25,000 | 2,083 hrs |
Illustrative only. Assumes 0.5 avoidable endpoint-configuration tickets per PC per year at five minutes each. Substitute your own service-desk figures.
Peripherals
Windows keeps doing what Windows does well.
XPC does not take over device support. Everything below remains handled by Windows and your existing tooling.
- Drivers
- USB support
- Printing stacks
- Smart-card and card-reader software
- Webcams
- Microphones
- Headsets
- Audio devices
- Specialist peripherals
- Vendor utilities
- Middleware
- Corporate agents
What changes
Only the user experience changes: what the user sees, what they can reach, and how the approved connections are presented.
The endpoint remains a managed Windows PC. There is no new operating system, no new hardware compatibility matrix and no re-certification of peripherals.
Citrix reality
A browser is not a Citrix endpoint.
Enterprise Citrix access typically runs through a chain of components that each need to work locally.
Typical authenticated launch chain
- Microsoft Edge
- Citrix Gateway
- Duo / identity provider
- StoreFront / resource enumeration
- Locally installed Citrix Workspace
- ICA / HDX
- Virtual desktop
What must exist locally
- Locally installed Citrix Workspace
- Native ICA / HDX
- Local endpoint components
- Microsoft Teams VDI optimisation
- Zoom VDI optimisation
- USB redirection
- Printing
- Webcams and microphones
- Multiple monitors
- Client-drive and other approved redirections
- Local authentication and browser hand-off
- Protocol handlers
Authentication elements a kiosk build must permit
- Citrix Gateway
- Redirects
- Duo
- Identity provider
- Authentication callbacks
- Protocol handlers
- Resource launch
A single-application Edge kiosk is generally not sufficient for this pattern, because the endpoint needs far more than a browser window.
Browser policy surface a DIY build owns
- Allowed URLs
- Blocked URLs
- External protocol handling
- Download behaviour
- Session behaviour
- Browser prompts
- Authentication-provider exceptions
With XPC, browser lockdown is not the basis of the endpoint experience, so this policy surface is not something the organisation has to design and maintain.
Security honesty
Microsoft kiosk mode is not insecure. It is configuration-dependent.
Security outcomes follow from how well every surface below is designed, validated and kept validated after each release.
Surfaces a DIY lockdown owns
- Application-control policy
- Browser-control policy
- Protocol-control policy
- Local-settings policy
- User-account policy
- Update policy
- Recovery policy
- Peripheral policy
- Operational monitoring
XPC reduces the number of these surfaces the customer must design themselves, because the endpoint experience is a product rather than a configuration.
Lifecycle
A DIY kiosk is never finished.
Four independent release streams can each change endpoint behaviour, and every change invites regression testing of the whole configuration.
Windows
Independent release cadence
Microsoft Edge
Independent release cadence
Citrix Workspace
Independent release cadence
VDI plugins
Independent release cadence
Support scenarios the team must own
- Citrix fails to launch
- Edge launches but authentication fails
- A Duo URL changes
- A Citrix helper process is blocked
- A VDI plug-in fails
- The webcam is unavailable
- The wrong microphone is selected
- Display scaling is wrong
- A printer is unavailable
- The network changes
- A certificate issue appears
- Windows Update changes behaviour
- An Edge update changes behaviour
- A Citrix update changes behaviour
Recovery and operations requirements
- Administrator recovery method
- Normal Windows maintenance access
- Remote support
- Logging
- Health and readiness information
- Rollback
- Policy update
- Endpoint visibility
XPC provides an administrator route back to the standard Windows shell through the XPC Suspended state, managed centrally in XPC Portal.
Side by side
Requirement by requirement.
This comparison describes where the work sits, not whether Microsoft's tooling is capable.
| Requirement | Microsoft kiosk approaches | XPC |
|---|---|---|
| Windows retained | Native | Native |
| Windows 11 Pro compatibility | Depends on the chosen kiosk architecture | No Enterprise-only dependency |
| Full Citrix Workspace | Requires configuration | Customer-installed, presented by XPC |
| Native HDX | Requires configuration | Customer-installed, presented by XPC |
| Teams VDI plugin | Requires configuration | Remains with existing Windows tooling |
| Zoom VDI plugin | Requires configuration | Remains with existing Windows tooling |
| Duo / browser authentication | Requires engineering | Presented through the approved connection |
| Edge configuration | Requires engineering | Not required for the XPC experience |
| URL restriction | Requires engineering | Not required for the XPC experience |
| Protocol handling | Requires engineering | Handled by the XPC connection experience |
| Application allowlisting | Requires engineering | Not the basis of the XPC experience |
| Citrix process dependency discovery | Requires engineering | Not required |
| Dependency maintenance | Requires ongoing maintenance | Not required |
| User endpoint settings | Requires engineering | Included in XPC |
| Audio self-service | Requires engineering | Included in XPC |
| Display self-service | Requires engineering | Included in XPC |
| Network self-service | Requires engineering | Included in XPC |
| Peripheral self-service | Requires engineering | Included in XPC |
| Restart / shutdown UX | Requires configuration | Included in XPC |
| Admin escape | Requires engineering | XPC Suspended state |
| Central connection configuration | Requires external tooling | Centrally managed by XPC |
| Cloud configuration portal | Requires external tooling | XPC Portal |
| Endpoint readiness visibility | Requires external tooling | Centrally managed by XPC |
| Existing RMM retained | Native | Remains with existing Windows tooling |
| Existing EDR retained | Native | Remains with existing Windows tooling |
| Existing drivers retained | Native | Remains with existing Windows tooling |
| Peripheral compatibility retained | Native | Remains with existing Windows tooling |
| Windows Update management retained | Native | Remains with existing Windows tooling |
| Multiple customer configurations | Requires external tooling | Centrally managed by XPC |
| MSP multi-tenant suitability | Requires external tooling | Tenants in XPC Portal |
| Branded user interface (logo, colours, wording) | Limited to wallpaper and Windows theming; not a designed brand surface | Fully brandable XPC interface |
| Per-customer or per-site presentation | Requires separate configuration engineering per variant | Separate XPC configurations, assignable per organisation, site or device group |
| Promotional or marketing messaging on the endpoint | Not a design goal of Assigned Access | Supported through XPC interface customisation |
| Ongoing kiosk XML maintenance | Requires ongoing maintenance | Not required |
| AppLocker interaction | Requires engineering | Not the basis of the XPC experience |
| Windows release regression testing | Requires ongoing maintenance | Windows testing continues; the XPC experience is unchanged |
| Edge release regression testing | Requires ongoing maintenance | Not part of the XPC experience |
| Citrix release regression testing | Requires ongoing maintenance | Citrix testing continues as today |
| VDI plugin regression testing | Requires ongoing maintenance | Remains with existing Windows tooling |
A realistic scenario
1,000 Citrix endpoints. Two ways to get there.
- Windows 11 Pro endpoints
- Citrix Workspace
- Duo
- Teams optimisation
- Zoom optimisation
- Multiple displays
- Webcams
- Headsets
- USB devices
- Printing
- Local networking
- RMM
- EDR
Path A — Microsoft kiosk engineering
- 1.Architect the configuration
- 2.Prototype
- 3.Determine required applications
- 4.Trace dependencies
- 5.Build the Assigned Access XML
- 6.Configure Edge
- 7.Configure Duo / IdP exceptions
- 8.Configure the Citrix hand-off
- 9.Expose required Windows controls
- 10.Test peripherals
- 11.Test plugins
- 12.Pilot
- 13.Remediate
- 14.Deploy
- 15.Document
- 16.Monitor
- 17.Regression-test future releases
Path B — XPC
- 1LOGIN — log in to the XPC Cloud Portal
- 2INSTALL — download the XPC MSI package and install it
- 3DEPLOY — enable XPC Mode from the XPC Cloud Portal
Both paths keep Windows. Only one keeps your engineers.
Technical appendix
The nine-phase do-it-yourself build, in full.
Written for endpoint architects. Every phase reflects real work that a Citrix kiosk deployment on Windows typically requires.
Phase 1 — Define the endpoint architecture
- Confirm the supported Windows edition and build.
- Decide between Assigned Access single-app, restricted user experience and Shell Launcher.
- Reject a single-app Edge kiosk if native Citrix Workspace and multiple local components are required.
- Determine whether Windows Pro or Enterprise functionality is required by the chosen architecture.
- Define the kiosk / local user model.
- Define the authentication model.
- Define the administrator recovery model.
- Define the RMM and support model.
- Define peripheral requirements.
- Define user self-service requirements.
Phase 2 — Prepare Windows
- Install Windows.
- Patch Windows.
- Install hardware drivers.
- Install the RMM agent.
- Install EDR / security tooling.
- Install required certificates.
- Install vendor middleware.
- Install printer drivers.
- Install card-reader middleware where applicable.
- Install webcam, headset and device software where necessary.
Phase 3 — Install Citrix
- Select a supported Citrix Workspace release.
- Install the full Windows Citrix Workspace application.
- Configure Workspace.
- Configure Gateway / StoreFront details.
- Validate ICA / HDX launch.
- Configure any required protocol handling.
- Install Teams VDI components.
- Install Zoom VDI components.
- Validate endpoint-side optimisation.
- Validate audio.
- Validate microphone.
- Validate webcam.
- Validate multiple displays.
- Validate printing.
- Validate USB and redirection requirements.
Phase 4 — Build the authentication browser configuration
- Install and configure Microsoft Edge.
- Define the Citrix Gateway URL.
- Identify every Duo URL used during the authentication chain.
- Identify identity-provider URLs.
- Identify callback and redirect URLs.
- Define the URL block policy.
- Define the URL allow policy.
- Configure external protocol handling where necessary.
- Configure Citrix Workspace launcher behaviour.
- Configure download behaviour.
- Configure browser prompts.
- Disable unnecessary browser functionality.
- Test authentication failure states.
- Test expired passwords and session states.
- Test Duo fallback and recovery behaviour as appropriate.
Phase 5 — Build the Assigned Access configuration
- Create the Assigned Access configuration XML.
- Select the correct Windows schema / version.
- Create profiles.
- Associate the kiosk user and configuration.
- Add Edge.
- Add Citrix Workspace executables.
- Determine required Citrix helper executables.
- Determine required authentication executables.
- Determine required Teams VDI components.
- Determine required Zoom VDI components.
- Determine required Windows components.
- Determine required peripheral and vendor utilities.
- Configure Start and taskbar behaviour.
- Configure autolaunch behaviour if required.
- Validate the resulting AppLocker behaviour.
- Identify dependencies blocked by the configuration.
- Add missing dependencies.
- Repeat until the full workflow succeeds.
Phase 6 — Decide what Windows functionality users still require
- Determine whether users need audio controls, microphone and speaker selection.
- Determine whether users need display settings, multi-monitor arrangement and DPI / scaling.
- Determine whether users need Wi-Fi and Bluetooth.
- Determine whether users need printers.
- Determine whether users need accessibility features.
- Determine whether users need language and keyboard controls.
- Determine whether users need vendor peripheral utilities.
- For each required capability, identify where Microsoft currently exposes it.
- Identify the URI, application or Control Panel component required.
- Determine whether it works inside the restricted experience.
- Allow any required application or dependency.
- Ensure unrelated Settings surfaces remain inaccessible where desired.
- Test whether users can escape into unwanted Windows functions.
- Document the configuration.
This is the problem XPC self-service solves.
Phase 7 — Peripheral validation
- Test supported headsets, microphones and webcams.
- Test USB devices.
- Test printers.
- Test card readers.
- Test multiple monitors.
- Test Bluetooth peripherals where applicable.
- Test device reconnect.
- Test device replacement.
- Test behaviour after reboot.
- Test behaviour after Citrix reconnect.
- Test behaviour after Windows updates.
Windows supports these devices. The work is integrating, exposing, controlling and supporting them inside a restricted user experience.
Phase 8 — Deployment
- Choose MDM, a provisioning package, PowerShell / RMM or another supported deployment method.
- Package the configuration.
- Deploy a pilot.
- Verify the kiosk profile.
- Verify account behaviour.
- Verify Edge policy.
- Verify Citrix launch.
- Verify Duo.
- Verify plugins.
- Verify peripherals.
- Verify remote-support access.
- Verify administrator recovery.
- Document rollback.
- Expand deployment.
Phase 9 — Lifecycle management
- Track Windows changes.
- Track Windows kiosk known issues.
- Track Edge changes.
- Track Citrix Workspace releases.
- Track Teams VDI changes.
- Track Zoom VDI changes.
- Track peripheral-driver changes.
- Regression-test updates.
- Validate allowed applications after updates.
- Validate authentication flows.
- Validate browser policies.
- Validate audio and video optimisation.
- Validate user self-service.
- Update documentation.
- Update deployment policies.
- Roll out changes across the estate.
FAQ
Microsoft kiosk mode, answered plainly.
References
Vendor documentation.
- Windows kiosk configuration overview
- Assigned Access configuration XML reference
- Assigned Access troubleshooting and known issues
- Shell Launcher and edition requirements
- Microsoft Edge kiosk and URL policies
- Citrix Workspace app for Windows
- Citrix optimisation for Microsoft Teams
Vendor behaviour, Windows edition requirements and supported configurations change over time. Documentation references last reviewed 12 August 2026. Please confirm against current Microsoft and Citrix documentation for your environment.
Brandable. Configurable. Customisable.
Assigned Access locks a screen down. XPC designs it.
A Microsoft kiosk build restricts what Windows exposes; its presentation is limited to wallpaper and Windows theming. XPC's interface is brandable and configurable by design — logo, colours, wording and connections, assignable per organisation, site or device group.
Your logo, your colours
The XPC interface carries the organisation's logo, colour palette, wallpaper and wording, so the endpoint looks like it belongs to the business rather than to a vendor.
Configured per deployment
Different sites, device groups, departments, schools or customers can each receive their own XPC configuration and presentation from the same XPC Portal tenant.
MSP white-label ready
Managed service providers can present XPC in their own identity, or in each end-customer's identity, across every organisation they manage.
Marketing and promotional use
Because the screen the user sees is fully designed, it can also carry campaign artwork, promotional messaging, safety notices or seasonal branding on retail, reception and public-facing endpoints.
For MSPs, schools, retail and public-facing endpoints, that difference matters: the same XPC deployment can be presented in each customer's identity, or carry promotional and marketing messaging, without a new engineering project each time.
Keep Windows. Skip the lockdown project.
XPC delivers a purpose-built, centrally managed Citrix and RDP endpoint experience on the Windows PCs you already own.