Architecture
100% Zero Trust Endpoint
Zero trust is a design principle, not a product you can finish buying. On the endpoint it means nothing is trusted by default — not the user session, not an installed application, not a script that happens to be signed. XPC-Plus applies that principle to a Windows endpoint: the user sees only approved connections, only approved software executes, and approved software is constrained in what it may reach. It is a posture you operate, not a guarantee anyone can honestly sell.
Deny
By default
Only approved applications, scripts and libraries execute. Everything else is denied rather than assessed.
Windows
Kept, not replaced
No Linux migration, no new endpoint OS, no loss of Windows-native peripheral and application compatibility.
Control
Instead of reduction
Capability is governed rather than removed, so the endpoint stays useful when the requirement changes.
The objection
But isn’t Linux more secure than Windows?
Not automatically.
Security is an architecture, not an operating-system logo. Linux earns its reputation from configuration discipline, smaller default attack surface and, in thin-client products, deliberate feature removal — not from the kernel being categorically safer in every deployment.
The same discipline applied to a Windows endpoint produces a similar effect. The question worth asking is not which kernel you booted, but what a user, a process or an attacker is actually able to do once the machine is running.
The part that gets skipped
Linux still requires security management
A Linux endpoint is not maintenance-free. Packages, browsers, remote-desktop clients and runtimes on it still ship vulnerabilities, still need updates, and still need someone to notice when an update is missing.
If the argument for Linux is that it removes endpoint security work, the argument is overstated. It changes the work, the tooling and the skills your team needs — it does not delete the work.
Still true on a Linux endpoint
- Firmware, kernel and package updates need to be applied
- The browser and the remote-desktop client are still exposed software
- Misconfiguration is still the most common practical weakness
- You still need to know which endpoints are behind, and act on it
- Your team needs Linux skills alongside its Windows skills
Giving credit first
What about a hardened Linux thin-client OS?
These products are genuinely good at what they set out to do.
A purpose-built thin-client OS has real advantages: a small attack surface, a read-only or tightly controlled system image, fast boot, low resource use, central management built for exactly this job, and a user who simply cannot reach a general-purpose desktop.
There is a tradeoff, and it is architectural rather than a flaw: security through reduction also means capability through reduction. The things removed to make the endpoint safe are also the things you cannot get back when a requirement changes.
Where reduction usually shows up
- A Windows-only line-of-business application that must run locally
- A specialist peripheral whose vendor ships Windows drivers only
- Signature pads, label printers, scanners, badge readers, clinical devices
- Vendor-specific client software with no Linux build
- A second management platform, a second skill set and a migration project to get there
The reframe
What if you could get extreme endpoint control without giving up Windows flexibility?
That is the whole idea behind XPC-Plus. Instead of removing capability from the endpoint, govern it: present only the connections you approve, patch what is installed, allow only approved software to execute, and constrain what that approved software may reach.
The user experience becomes as narrow as a thin client. The platform underneath stays Windows, so compatibility, peripherals and your team’s existing skills survive the change.
Reduction versus control
- Reduction: capability is deleted, so risk falls and so does what you can do
- Control: capability remains present but is governed by policy
- Reduction is reversed by a migration; control is changed by a policy edit
- Control keeps Windows-native compatibility available when you need it
The other architecture
What about immutable operating systems?
Immutability is a strong idea, and it solves a specific problem well.
An immutable or read-only system image resists persistent change: a reboot returns the endpoint to a known state, drift is limited, and unauthorised modification of the system image is hard. For fixed-function endpoints that is a genuinely elegant answer.
The tradeoffs are worth stating plainly. Immutability controls change to the system; it does not by itself control what a permitted session is allowed to do while it is running. Updates arrive as image releases on the vendor’s cadence, local flexibility is limited by design, and anything the image does not include usually means waiting for the vendor.
What immutability does and does not cover
- Does: resist persistent modification of the system image
- Does: return the endpoint to a known state on reboot
- Does not necessarily: restrict what an approved in-session process may execute or reach
- Constraint: capability is bounded by what the vendor ships in the image
Do you want security by eliminating capability — or security by controlling capability?
Could XPC-Plus provide a stronger practical security posture?
In some environments, plausibly yes — and it is worth being precise about the comparison, because the honest one is narrower than the marketing version.
The comparison is between a Windows endpoint running XPC-Plus — locked user experience, managed patch remediation, deny-by-default execution control and ringfencing — and a typical unmanaged or lightly managed endpoint, whatever operating system it runs. Against that, an endpoint where only approved software can execute and installed software is patched on a managed schedule is a materially better position.
It is not a claim that XPC-Plus is more secure than any specific vendor’s hardened or immutable operating system. Those are different architectures with different tradeoffs, and a well-run deployment of either can be strong. What XPC-Plus offers is that posture without a migration, without a second endpoint OS and without losing Windows-native compatibility.
Two ways to constrain an endpoint
Immutability controls change. XPC-Plus controls behaviour.
Immutable OS
Immutability controls change.
- System image resists persistent modification
- Reboot restores a known state
- Update cadence follows vendor image releases
- Capability bounded by what the image includes
- Getting there is a migration project
XPC-Plus
XPC-Plus controls behaviour.
- Only approved applications, scripts and libraries execute
- Approved software constrained in what it may reach
- Windows and third-party patching managed continuously
- Windows-native compatibility retained
- Getting there is a policy change, not a rebuild
These are complementary ideas, not opposites. One governs change to the system; the other governs behaviour within it.
Familiarity is a security feature too
Users make fewer mistakes on an interface they recognise, and support teams resolve problems faster on a platform they already know. An unfamiliar endpoint OS creates support contacts, workarounds and shadow processes — and workarounds are where real security posture is quietly lost.
Windows flexibility without the Windows free-for-all
Keeping Windows does not require keeping the general-purpose desktop. XPC presents one access screen, XPC-Plus decides what may execute behind it, and the flexibility of Windows stays available to IT rather than to every user by default.
Secure enough for IT, simple enough for users
The endpoint your users see is a single screen with the connections they need. The endpoint your IT and security teams see is patched, allowlisted, ringfenced and reported on. The same machine satisfies both, which is the only version of this that survives contact with a real business.
Architecture comparison
Four approaches, stated as tradeoffs rather than scores
Every column here describes a legitimate architecture. The right one depends on how much Windows-native capability your environment actually needs.
| Criterion | Standard Windows PC | Hardened Linux thin-client OS | Immutable OS | XPC-Plus on Windows |
|---|---|---|---|---|
| User-facing attack surface | Full general-purpose desktop | Intentionally constrained | Intentionally constrained | Single approved access screen |
| Windows application compatibility | Windows-native | Limited to what the OS supports | Limited to the shipped image | Windows-native |
| Peripheral and driver support | Windows-native | Depends on vendor support | Depends on the image | Windows-native |
| Patch and vulnerability remediation | Depends on your tooling | Vendor image plus your process | Vendor image releases | Managed for you, continuously |
| Application execution control | Typically none | Reduced by feature removal | Depends on vendor | Deny-by-default, plus ringfencing |
| Constraint on approved software | None by default | Depends on vendor | Depends on vendor | Ringfenced by policy |
| Route to adoption | Already there | OS migration project | OS migration project | Install the MSI, enable the mode |
| Reversibility | n/a | Re-image to change course | Re-image to change course | Policy change |
| Team skills required | Windows | Windows plus Linux | Windows plus vendor platform | Windows |
| User familiarity | Familiar | New interface | New interface | Familiar Windows behaviour behind one screen |
Descriptions of third-party approaches are generalised across product categories, since individual vendors differ. Verify specifics against the vendor’s current documentation.
Architecture questions
The questions buyers actually ask
Sources and further reading
- NIST SP 800-207, Zero Trust Architecture
The reference definition of zero trust as an architecture and set of principles rather than a product.
- NIST SP 800-40r4, Guide to Enterprise Patch Management Planning
Why patch remediation is treated as a continuous, planned programme rather than an occasional task.
- CISA and partners, Zero Trust Maturity Model
Maturity framing used to describe endpoint posture as progressive rather than binary.
- NCSC guidance on device security and application allow listing
Public-sector guidance describing allow listing and restricting execution as endpoint hardening measures.
Technical information last reviewed August 2026.
Extreme endpoint control, without giving up Windows
XPC-Plus adds managed patching and deny-by-default execution control to the Windows PCs you already own — $17 per endpoint per month, or $19 with the XPC Lite compatibility architecture.