The Omnissa 2026 State of the Digital Workspace: An EUC Perspective Decades in the Making
In this blog
- The shadow AI finding deserves its own conversation
- Windows has more agents because Windows has always been the target
- The Windows patching gap is a process problem, not a platform problem
- Critical industries are managing constraints, not ignoring updates
- The encryption numbers need context before anyone panics
- The bottom line
- Download
Omnissa recently published its inaugural State of the Digital Workspace 2026 report, and it is worth your time. Unlike most vendor research built on surveys and self-reported sentiment, this one draws from anonymized telemetry across millions of Workspace ONE-managed endpoints, spanning 17 industries over a full calendar year. That is a meaningful data set, and several of the findings should land with real weight for anyone running enterprise End-User Computing (EUC) environments today.
Telemetry tells you what is happening. It does not always tell you why.
Today we want to add context behind some of these findings based on what we have seen in enterprises around the world - not to argue with the data, but to make it more meaningful. Omnissa is an established EUC authority, and this report is a credible, well-constructed analysis. Here is our perspective based on real-world experience.
The shadow AI finding deserves its own conversation
Before getting into the nuance, one finding warrants a straight acknowledgment: the shadow AI data is alarming, and the report is right to lead with it.
GenAI-powered assistants grew nearly 1,000% across managed endpoints in 2025. On the sanctioned side, Microsoft Copilot dominates across platforms - no surprise given its distribution through Microsoft 365. On the unsanctioned side, ChatGPT and Gemini are showing up on corporate devices at a rate that should concern every IT and security leader reading this. The Android picture is particularly striking - unsanctioned AI tools account for roughly 98% of AI assistant installs on managed devices.
The risk is not complicated. Employees are feeding data into models with no enterprise governance attached to them. This is happening! Right now! At scale! On your managed fleet! Without proper controls, there is no way to even determine how much of that data contains proprietary information. Static blocklists are not going to solve it - users will always find a path to the tools that get their work done. The answer is visibility into what is running, followed by a deliberate decision to sanction, offer a secured alternative or restrict with a rationale people can actually understand. Modern Unified Endpoint Management (UEM) platforms can surface installed application inventory across managed devices, giving you a reasonable starting point for understanding your current exposure before building a broader policy response.
Shadow AI does not need more context. It needs more attention.
Windows has more agents because Windows has always been the target
The report identifies agent fatigue on Windows, with Endpoint Detection and Response (EDR), Data Loss Prevention (DLP), monitoring, patching, Security Information and Event Management (SIEM) connectors, and other security tooling accounting for nearly two-thirds of the deployed Windows software stack. That finding is accurate. The implied conclusion - that this is a Windows-specific problem - is where we would push back a little.
Windows carries more agents because Windows has traditionally been the primary deployed and most widely managed operating system in the enterprise. Security teams built their tooling around the platform that represented the overwhelming majority of managed endpoints. EDR agents, patch management clients, DLP agents, SIEM connectors - all of it landed on Windows first because that is where the risk was concentrated.
In many organizations, minority operating systems (Mac, Linux, mobility, etc), have avoided the plethora of installed system agents. Even in mature shops, that have been running some level of security tooling on Macs for years, there is still a disparate number of available system agents. Linux endpoint security is thinner still, often limited to whatever the configuration management tooling enforces rather than a dedicated endpoint security stack.
The gap is real across all non-Windows platforms, but its size varies considerably depending on how far along an organization is in extending their security stack beyond Windows. Mobile Threat Defense (MTD) (tools that detect threats on iOS and Android devices at the OS and application layer) remains thinner than most security teams would want to admit.
Here is the part that matters going forward. As organizations expand usage on non-Windows platforms (and this report shows they are doing exactly that), the security investment has to follow suit. An enterprise running 30% of its fleet on macOS without equivalent endpoint security coverage is not running a leaner environment. It is running a gap. The agent sprawl on Windows is worth fixing, but the answer is rationalizing the Windows stack while closing the coverage gap on other platforms at the same time. Lower Mac, Linux or mobile agent counts are not a model to replicate. They are a problem waiting to surface.
The Windows patching gap is a process problem, not a platform problem
The report shows that macOS updates 1.5 times faster than Windows, and iOS updates eight times faster than Android. Both gaps are real. The explanations are different for each, and they matter.
On Windows vs. Mac:
In most enterprises, Windows patch management runs through layers of governance built up over decades. Ring-based testing, Change Advisory Board (CAB) approvals, pilot deployments, staged rollouts. That process exists precisely because a bad patch reaching tens of thousands of Windows endpoints simultaneously can be a major incident - and staged rollouts are how organizations prevent that from happening.
It is also worth recognizing that this governance model was forged in environments full of legacy applications and interdependencies, and parts of it have persisted more out of institutional memory than current technical necessity. Mac patching in most organizations has not been subjected to the same validation rigor. It tends to run closer to "test it briefly and push it." That is not a Mac advantage. That is an asymmetric risk tolerance that has not been stress-tested at scale yet. As Mac fleets grow and become operationally critical, expect that governance gap to close - and expect Mac patching velocity numbers to start looking a lot more like Windows.
On iOS vs. Android:
This gap is structural, and it comes down to the supply chain. Apple controls the full stack - the silicon, the hardware, the OS and most of the core software. When Apple releases an iOS update, it goes directly to the device. One pipeline, no intermediaries.
Android does not work that way. An OS update has to clear Google's base build, then pass through OEM customization layers - Samsung, Zebra and Google Pixel each maintain their own firmware builds - and in some cases through carrier validation and device-specific testing - across dozens of hardware configurations. This is sometimes called the Android Update Cascade, and it is a feature of how the ecosystem was designed. Add to that the reality that a large share of enterprise Android devices are purpose-built hardware like Zebra scanners, which carry their own firmware layer and ISV dependencies on top of standard Android. Those devices are structurally slower to update than a standard smartphone, regardless of anyone's security intent.
A note on Linux:
Linux endpoint patching tells a different story. Most enterprise Linux endpoints - increasingly common as developer workstations - are managed through configuration management tools like Ansible or Chef rather than a dedicated UEM. Patch cycles are distribution-specific, kernel updates carry their own risks and the governance around Linux endpoint patching in most organizations ranges from "reasonable" to "largely informal." The report does not cover Linux endpoint patching, but if your environment includes Linux workstations, the same questions about process maturity and consistency apply.
In short, the patching velocity numbers in this report tell you something real about each platform's architecture and the processes organizations have built around them. They do not tell you much about anyone's security intent.
Critical industries are managing constraints, not ignoring updates
The report describes healthcare, pharma and retail as letting their OS environments "languish," with significant percentages of devices running versions four or five generations behind current. We understand why the data reads that way. Based on what we see in our customers, we believe it misses some important context.
These organizations are navigating real constraints:
- ISV certification cycles. The vendors supplying medical charting systems, pharmacy dispensing platforms and retail inventory management are notoriously slow to certify new OS builds. Pushing an OS update before your clinical application vendor has certified it is not a security win - it is a patient-facing application failure waiting to happen.
- Regulatory validation requirements. In FDA-regulated environments, software changes can trigger revalidation. An OS update is not always just a patch; it can be a compliance event with a multi-month remediation timeline attached.
- Extended Support agreements. Many of these organizations pay Microsoft for Extended Security Updates (ESU) on Windows 10. A fully patched, Microsoft-supported Windows 10 build under an ESU agreement carries a fundamentally different risk profile than an abandoned, unpatched endpoint. The report does not distinguish between the two. To be clear, ESU coverage has limits - it addresses security patches but does not extend the full support lifecycle - so ESU is a bridge, not a long-term answer. But it is not the same as running unprotected.
The right question to ask these organizations is not, "Why are you behind?" It is, "What is your remediation roadmap, and do you have compensating controls in place while you wait?" Those are different conversations, and they produce different answers.
The encryption numbers need context before anyone panics
The report flags high rates of unencrypted desktop devices across multiple industries, including regulated ones - banking and healthcare both showing roughly 23-27% of desktops without encryption. That number looks bad in aggregate. What it actually means depends heavily on which devices you are counting and, just as importantly, what layer of the environment the telemetry can actually see.
Before getting into the desktop scenarios, it is worth noting that mobile platforms are largely a non-issue here. iOS has been encrypted by default since its earliest enterprise deployments, and Android has enforced full-disk encryption by default since Android 6.0. The encryption conversation for desktops is a fundamentally different one.
This is where the VDI picture gets complicated. Encryption in a virtualized environment is not a single question - it is a layered one, and the answer changes depending on where in the stack you are looking:
- Thin clients run a minimal, typically locked-down local OS. Encryption at this layer is usually unnecessary by design - the device stores nothing meaningful, and the session data lives elsewhere.
- Virtual OS (VDI session disk). Whether the virtual disk needs encryption depends on whether it is persistent or non-persistent. A non-persistent VDI that resets on logoff has a fundamentally different data exposure profile than a persistent virtual desktop with a user-specific virtual disk carrying local data between sessions.
- Backend storage. If the Storage Area Network (SAN), Hyper-Converged Infrastructure (HCI) platform, or cloud infrastructure layer is encrypted at rest - think VMware vSAN, NetApp, Pure Storage or Azure Virtual Desktop storage - encrypting the virtual disk on top of it is often redundant and adds overhead without meaningfully improving the security posture.
The core issue is that endpoint management telemetry, including Workspace ONE, reports what it can observe at the device or OS layer. It cannot always see encryption that exists further down in the storage stack. A thin client or VDI session that reports no BitLocker or FileVault may well be running in an environment that is encrypted at every layer that actually matters. A practical first step for any team working through this is to map their device population into these categories before drawing conclusions from the aggregate number.
That leaves two scenarios that genuinely do warrant attention:
- Physical devices running Windows 11 or macOS. There is no good explanation for Disk encryption being off on a Windows 11 device - the platform requires TPM 2.0, and Modern MDM platforms have mature BitLocker management built in. Similarly, FileVault on macOS is straightforward to enforce through any modern MDM. If physical devices on either platform are genuinely unencrypted, that is a policy enforcement failure that needs to be investigated, not rationalized.
- Physical devices running Windows 10. If the organization is under an ESU agreement with active patching, the encryption gap is a separate problem from the OS version question - but it is still a problem. The follow-up is whether compensating controls exist and whether there is a documented plan to close it. Hopefully, there is.
The aggregate number is worth taking seriously. The response to it has to be calibrated to the layer you are actually talking about.
The bottom line
The core argument in this report - that visibility is the foundation of modern EUC management - is correct. Policy-based management alone cannot keep pace with the rate of change happening across today's endpoint environments. The shadow AI data makes that clear on its own. And it is worth noting that the report's employee experience data makes a parallel case for the business side of the house: Windows devices showing three times more forced shutdowns than Mac, and 7 times more app hangs, represent a measurable productivity cost that IT directors can take directly into a budget conversation.
What telemetry cannot do is explain the operational history, the regulatory constraints and the vendor dependencies that produced the patterns it observes. That is not a flaw in the research. It is just the nature of the data. The numbers show you where to look. Operational experience and context tell you what you are actually looking at. Know the difference before you decide what to do about it.