As the saying goes, "change is the only thing in life that remains constant," and it couldn't be truer when it comes to how we treat desktops and their operating systems. Traditional setups are designed to change and adapt. That flexibility has long been a strength of the traditional PC, especially for users who need local applications or specialized computing capabilities. But it also means security teams must protect devices whose state is in constant flux, and that same openness is exactly what attackers have learned to exploit.

Increasingly, the desired openness that makes a PC adaptable also makes it easier to abuse, and attackers don't need malware to do it. CrowdStrike's 2026 Global Threat Report found that 82% of detections tracked were malware-free, with adversaries using legitimate credentials, trusted identity flows, and approved applications to move through environments.

For organizations already moving applications and desktops into VDI, DaaS, SaaS, and browser-based environments, this raises an important question. If some employees primarily use an endpoint to access applications and data hosted elsewhere, does the operating system on that device need to remain as open and changeable as a traditional PC?

For certain users and workloads, an immutable operating system offers another approach to endpoint security by controlling what can change in the first place.

What Immutability Means at the Endpoint

Immutability can easily become another cybersecurity buzzword, so it is important to be clear about what it really means. An immutable endpoint is a device that IT cannot update, configure, or change while it is running. That said, organizations still need to apply security updates, update VDI clients and browsers, manage certificates, and adjust configurations as their environments evolve.

The difference between immutable and traditional endpoints is how changes occur and who or what can make them. A purpose-built immutable operating system uses trusted architecture based on a trusted read-only filesystem with tightly controlled configuration, rather than allowing users and applications to freely modify the underlying operating environment. In a non-persistent model, the root filesystem can load into memory at startup and reset on reboot, retaining only approved configuration information.

This creates a very different relationship between the endpoint and change. Instead of the operating system naturally accumulating software, local data, configuration changes, and other modifications over time, IT maintains greater control over what endures. That predictability has immense value for both endpoint management and security.

Why Persistence Matters

Preventing an initial compromise remains essential, but security teams must also consider what an attacker can do once they gain access to a device. 

Once malicious software or an attacker reaches an endpoint, establishing persistence can allow unauthorized activity to continue beyond the initial compromise. Changes to system files, startup processes, applications, and configurations often let malicious activity survive a reboot or remain available for later use.

A non-persistent operating system changes some of those conditions. If unauthorized changes to the operating environment aren't permanently written to the device, they can't become a part of its ongoing state. Rebooting the endpoint can restore the operating environment to its approved state rather than retaining all modifications from the previous session.

To be clear, this does not make an immutable endpoint immune to malware, ransomware, credential theft, or other attacks. Security still depends on controls throughout the environment, including identity, network, and application security, as well as ongoing monitoring and user behavior. Immutability limits the opportunity for unauthorized changes to become permanent. Rather than asking security tools to identify every unwanted modification after it happens, the architecture itself limits what the endpoint can retain.

A Known State Still Has to Be a Trusted State

Immutability protects the core, while non-persistence makes the reboot meaningful. A key limitation of simply returning an endpoint to a known state is that the state must be trusted. That state is only useful if the organization can trust what it loads. This is where endpoint security begins before the user signs in.

UEFI Secure Boot is the first checkpoint. It allows the device firmware to validate the bootloader's integrity and authenticity before execution, so a modified or improperly signed boot component never enters the trusted boot process. This can be dangerous because the most alarming compromises will operate beneath the operating system, loading before any security software does. Secure Boot closes that gap by exposing it.

Unified Kernel Image, or UKI, extends the same idea. Rather than validating the pieces of the Linux boot process separately, UKI consolidates them into a single cryptographically signed artifact that the endpoint can verify as a whole. Fewer independently trusted parts mean fewer seams for an attacker to slip between, and the "known state" the device boots into is verified as a single payload rather than assembled from parts trusted on faith.

The specific technologies matter less than the principle they enforce: an endpoint should never be considered trustworthy simply because it can turn on. Booting successfully proves the hardware works, not that the software is the software you intend to run. Verified boot turns "a known state" into "a trusted known state." In a non-persistent model, it is the foundation IT depends on.

Trust Cannot Stop at Reboot

Verifying the boot process only solves part of the problem, because an endpoint continues to load software and services after startup.

In a modular Linux architecture, operating system components such as graphics packages, VDI clients, audio components, and management agents can be packaged as compressed, signed, read-only filesystems mounted at runtime. Those packages can then be cryptographically validated before mounting and execution.

This extends the same principle used during secure boot into the running operating environment. The objective is to create a chain in which the device does not assume a component can be trusted just because it is present. Its integrity can be checked before it becomes part of the operating environment.

That becomes increasingly important as attackers find ways to operate through trusted systems rather than relying on malware. Endpoint security cannot depend entirely on identifying a malicious executable after it appears. Organizations also need to consider the integrity of the environment in which users authenticate and access corporate resources.

Not Every Endpoint Needs to Be Immutable

Consider all areas of your organization and where immutable endpoints are most needed. Many users will still need a traditional PC as their endpoint because they require locally installed applications, significant local processing, specialized peripherals, or the ability to customize their computing environments. In these cases, restricting those devices solely for standardization would create its own operational problems.

The opportunity is to avoid assuming those requirements apply to every employee. Many organizations now have users whose applications are primarily delivered through VDI, DaaS, SaaS, Windows 365, Azure Virtual Desktop, or a browser. Shared workstations in healthcare, retail, manufacturing, and other frontline environments may have an even stronger need for predictable devices that don't retain unnecessary information or accumulate changes between users.

In those cases, the endpoint increasingly serves as an access point to computing resources hosted elsewhere. This increased access lets organizations reconsider how much local flexibility they need.

Reducing What Security Has to Defend

For years, endpoint security has largely had to accommodate the flexibility of the traditional PC. Organizations have responded by adding security controls to monitor and protect increasingly complex devices, and those controls will remain important.

The changing way applications are delivered creates another option. When a user's work no longer depends heavily on local applications or data, organizations can consider designing the endpoint around a more controlled operating model. Signed read-only system components, non-persistence, verified boot processes, signed runtime components, and tightly managed configuration can reduce the number of ways an endpoint's underlying state can change.

Ultimately, the goal is not to eliminate all change from the endpoint; change is inevitable. The goal is to ensure change happens deliberately, through trusted and managed processes, rather than simply because the operating system allows it.