• Brian Link

  Product CTO (Americas) and Head of Platform (AI, Data, Automation)

  Brian Link is Product CTO (Americas) and Head of Platform (AI, Data, Automation) at Omnissa, where he helps shape product strategy and enables global enterprises to realize the full potential of modern management across security, AI-driven automation, and digital employee experience.

  With prior executive IT and product leadership roles at Nike, Capital One, VMware, and Microsoft, Brian has a proven track record of guiding enterprise technology strategy, scaling EUC platforms, and delivering measurable business outcomes at global scale.

  A tech enthusiast, investor, and accomplished musician, Brian thrives at the intersection of creativity and strategy, whether building high-performing technology teams, designing next-generation platform experiences, or creating art that resonates with audiences around the world.

  Read More From the Author

Based on what has been publicly shared about the recent Stryker incident, this doesn’t appear to be a case of a platform being exploited in the traditional sense. There’s no smoking gun of a systemic failure. Rather, it’s a useful reminder of something we don’t talk about enough in enterprise IT. Not all major security events come from exploits. Some come from perfectly valid actions executed with the wrong authority.

In this case, there was no fundamental breakdown of the platform. No zero-day vulnerability or novel attack vector. Instead, attackers simply appeared to gain access to privileged credentials and used the system as it was designed to be used.

Not all major security events come from exploits. Some come from perfectly valid actions executed with the wrong authority.

The uncomfortable truth is that the platform is not what failed. The system behaved as intended, and the commands were valid. 

The problem lies in the model of authority. We tend to anchor security posture around: 

• Preventing unauthorized access
• Hardening endpoints
• Detecting anomalous behavior 

And all of that still matters, of course, but incidents like this expose a different class of risk.  

What happens when access is legitimate, but the action itself can be catastrophic?  

“Remote wipe” is a perfectly valid administrative function. It’s used every day across countless workflows around the world. But in the wrong hands, at the wrong scale…  it starts to look a lot like an operational weapon.

UEM hygiene is security hygiene. (I’ll say it louder for the folks in the back!) Your MDM or UEM solution is one of the most powerful execution layers in your environment. That is why mastering the fundamentals is so paramount.

We tend to think about “hygiene” in terms of table stakes:

• Device compliance
• Patch levels
• Encryption
• Configuration drift

But what about these considerations:

• How is your administrative authority structured?
• How are your actions scoped and constrained?
• What safeguards exist for those high-impact operations?
• How are you controlling blast radius before execution?

Your hygiene cannot just be about device state. You have to consider action governance.

Now, make no mistake. I’m not here to say that those table stakes no longer matter. On the contrary, you should patch early and often. You should encrypt all the things. You should maintain device state and compliance. But perhaps there are a few other things worth stress testing in your environment, especially in light of recent incidents:

1. Is your administrative access equivalent to unlimited impact? In many environments, the answer is effectively ‘yes’. Once someone inherits privileged credentials, they inherit the full operational capability of that role. And that, my friends, is a problem. Administrative access alone should not automatically allow unrestricted impact.
    
2. Is your authority compartmentalized or is it centralized? The architectural difference between the two matters. For example, in Workspace ONE UEM administrative authority can be segmented across:

• Hierarchical organizational groups
• Multi-tenant boundaries
• Scoped permissions across device populations, business units, geographies, etc.

This allows our enterprise customers to constrain authority, rather than concentrating it into global roles. If your model centralizes power, then compromise becomes exponentially more dangerous. 

3. Are you truly operating with least-privilege administration? Most organizations will say they are, but I can’t help but wonder how many actually are. Folks… fine-grained RBAC matters. Scope your permissions by:

• Device group
• Resource type
• Operational function
• And so on 

The goal is simple… no single role should have more power than it absolutely needs. 

4. Should your high-impact actions require additional confirmation? Not all actions are equal, nor should they be treated as such. Destructive or high-scale operations should introduce friction by design because, in a compromised scenario, speed and scale work against you. 
    
   For example, in Workspace ONE UEM you can (and should) require an administrative confirmation factor such as MFA. We even offer an admin PIN and intentionally store that control within the management platform itself, rather than solely in the identity provider. Why? Because if identity is compromised and all enforcement lives there, you’ve effectively lost your last line of defense. 
    
5. Can you control blast radius before execution? It’s not enough to log or alert after the fact. You need mechanisms to:

• Define thresholds for high-impact actions (like mass device wipes)
• Trigger additional authorization when those thresholds are exceeded
• Enforce separation of duties between policy definition and policy execution 

In Workspace ONE UEM, this shows up in capabilities like Device Wipe Protection, where operations exceeding a defined scope require added controls. 

Say it with me: Scope and scale should never be accidental. 

Where is all this heading?

We have to acknowledge that the industry is moving like a rocket toward a world where actions are faster, automation is more pervasive, and AI will increasingly participate in execution. At face value that is a powerful concoction that breathes life into a canvas of infinite possibilities. But it is also dangerous if governance doesn’t evolve alongside it.

We’re already seeing the next steps emerge before our eyes.

• We must expand threshold protections beyond singular actions and broaden them across all resources.
• Approval workflows may well become the new normal, especially when we consider what it means to have humans in, on, and out of the loop across operational tasks.
• We need to hold ourselves accountable and enable tighter controls over how configurations and payloads are authorized and deployed.

None of this is about slowing things down. If it were only that simple. We have to make sure that speed doesn’t outrun control.

I’ll say it again… the more I squint at it, the more it feels clear to me that the Stryker incident wasn’t a failure of technology. It was a reminder that in modern enterprise environments, the most dangerous thing is not unauthorized access; it is unrestricted, ungoverned authority operating at scale.

That is the next frontier of UEM hygiene, and we can’t afford to ignore it.