Stryker’s Intune breach shows why standing admin trust fails

At a glance

What this is: Britive argues that the Stryker Intune breach exposed a structural flaw in always-on administrator access, not a software defect.

Why it matters: It matters because IAM, PAM, and endpoint governance teams have to control destructive admin actions at execution time, not assume vaulting or group policy will contain a compromised account.

👉 Read Britive's analysis of the Stryker Intune breach and runtime admin controls

Context

Standing administrative access is a governance problem when one compromised account can create more privilege and trigger destructive actions without fresh verification. In identity terms, the issue is not the endpoint platform alone, but the trust model that lets a persistent admin identity act with durable authority.

This is a clear NHI and PAM lesson as well as an IAM one. When privilege is static, the blast radius of one stolen credential expands across human admins, service accounts, and other machine identities in the same control plane.

The article's starting position is typical, not exceptional: many organisations still rely on always-on administrative access and manual approval steps that are too slow for machine-speed abuse.

Key questions

Q: What breaks when a trusted administrative platform is compromised?

A: A trusted administrative platform turns into a high-speed impact channel. The attacker does not need to move laterally in the usual sense if the platform can already reach endpoints, users, or records at scale. The result is often bulk action, mass exposure, or service disruption before human review catches up. In practice, the failure is excessive administrative reach.

Q: Why does standing privilege increase the blast radius of privileged accounts?

A: Standing privilege gives attackers a reusable administrative foothold if a credential, token, or session is exposed. That makes lateral movement faster because the compromised identity already has durable access boundaries crossed on its behalf. The greater the permanence of the privilege, the larger the potential impact from a single misuse event.

Q: How should security teams separate approval and execution in high-risk workflows?

A: Security teams should design workflows so no single identity can request, approve, and complete the same high-risk action. In practice, that means separate roles for initiation, authorisation, and execution, plus logging that proves each step happened independently. The control matters most where money, privileges, or sensitive data can move quickly.

Q: Who is accountable when a compromised privileged account triggers remote wipe?

A: Accountability sits with the organisation that granted and governed the privilege, not with the platform feature alone. The breach exposes a governance gap in privileged identity management, admin separation, and operational approval. Frameworks such as NIST CSF and zero trust architecture expect high-risk actions to be constrained and continuously verified, which is where ownership must be enforced.

Technical breakdown

Standing administrative privilege and escalation paths

Standing privilege means an identity retains elevated access between tasks instead of requesting it for each action. That makes the credential itself the security boundary. Once an attacker compromises a privileged administrator account, they do not need to break the platform to gain control; they can use legitimate permissions to expand authority, create new privileged identities, and trigger management-plane actions such as endpoint wipes. In Microsoft Intune, those capabilities can affect large fleets quickly because the control plane is designed to execute administrative commands at scale.

Practical implication: remove persistent admin paths for destructive actions and scope elevated access to the exact task window.

Multi-admin approval as a runtime control

Multi-admin approval is a compensating control for high-risk changes such as device wipes, RBAC modifications, and application updates. It works by separating request from execution, so one compromised account cannot complete the action alone. The control fails when approval is bolted on after privilege is already active, or when the approval workflow is slow enough that attackers can complete the destructive step before oversight arrives. Runtime enforcement has to sit at the point of execution, not only in policy documentation.

Practical implication: place approval gates in the live execution path for destructive Intune actions, not just in policy or ticketing workflows.

Protected administration by design for cloud and endpoint control planes

Protected administration by design means the control plane assumes admin identities may be compromised and therefore treats every privileged action as a separate verification event. That aligns with ZTA and ZSP thinking: trust is temporary, least privilege is task-scoped, and elevated access expires immediately after use. The article also links this model to agentic AI, which is relevant because machine-speed execution makes persistent privilege even less defensible. The same design pattern applies across human, NHI, and autonomous actors when they can issue administrative commands.

Practical implication: redesign control-plane access around ephemeral privilege, not around permanent administrator membership.

Threat narrative

Attacker objective: The objective was to weaponise trusted administrative access to disable endpoints at scale and force operational disruption.

1. Entry occurred when attackers compromised an existing administrator account rather than exploiting Intune code or a zero-day vulnerability.
2. Escalation followed when the stolen administrative permissions were used to create a new Global Administrator account and broaden control.
3. Impact came from executing Microsoft Intune's built-in wipe command, which erased nearly 80,000 devices and disrupted operations.

Breaches seen in the wild

• Replit AI Tool Database Deletion — Replit vibe coding AI assistant deletes live production database and creates 4,000 fake user records.
• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Standing administrative trust is the failure mode, not just standing privilege. This breach worked because the identity model assumed an administrator account could remain continuously trusted once provisioned. That assumption fails when the account is compromised and can create still more privilege, turning access membership into a control-plane weapon. The implication is that endpoint governance cannot rely on persistent admin trust as a design premise.

Protected administration by design is now a governance requirement, not an optimisation choice. CISA and Microsoft's guidance reflects a wider shift away from static admin groups toward runtime checks, least privilege, and approval at the moment of action. The breach demonstrates that vaulting credentials without changing the execution model still leaves destructive authority in place. Practitioners should treat runtime enforcement as the baseline for privileged administration.

Multi-admin approval only works when it is native to execution, not layered on top of it. The article's central insight is that manual review is too slow once an attacker is already inside an active privileged session. That is especially relevant as organisations prepare for agentic AI, because machine-speed action collapses the review window even further. Security teams need to stop assuming that a human approval cycle will always precede destructive use.

Identity blast radius is the right named concept for this class of failure. A single compromised admin account can now affect thousands of devices, multiple policy domains, and broader cloud governance in one sequence. That is not a patching issue or an endpoint-only issue; it is a delegated authority problem that spans IAM, PAM, and machine identity governance. The practical conclusion is that blast radius, not mere credential secrecy, has become the primary design variable.

This breach also exposes a shared assumption across human and non-human identities. The same static trust pattern that fails for a human administrator will also fail for a service account or an autonomous agent if that identity can act with permanent authority. The governance lesson is cross-domain: privilege should be granted only for the task, verified at execution, and revoked immediately after use.

From our research:

• 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, according to The 2024 ESG Report: Managing Non-Human Identities.
• Two-thirds of enterprises have endured a successful cyberattack resulting from compromised non-human identities, which shows how often identity abuse becomes an operational incident rather than a theoretical risk.
• The 52 NHI breaches Report provides the case-level detail teams need to connect standing access, compromise, and impact across real incidents.

What this signals

Identity blast radius: enterprises need a way to quantify how much damage one compromised privileged identity can do before they decide whether a control is actually working. The Stryker case shows that endpoint governance and identity governance are now the same conversation when administrative access can trigger fleet-wide actions.

The governance signal is clear for IAM and PAM teams: approval flows that sit outside the execution path will not contain fast-moving abuse. Runtime privilege, not static membership, is becoming the practical test for whether a control plane can survive compromised credentials.

For teams mapping this issue to standards, the strongest alignment is with runtime access control and privileged authentication guidance in NIST SP 800-53 Rev 5 Security and Privacy Controls and the control-plane assumptions in MITRE ATT&CK Enterprise Matrix.

For practitioners

• Replace standing admin access with ZSP for destructive controls Make device wipes, RBAC changes, and software deployment actions require fresh, task-scoped privilege instead of permanent administrator membership.
• Move approval gates into the execution path Enforce multi-admin approval at the point where Intune or a similar control plane would actually execute the command, so the action cannot complete before secondary review.
• Audit which identities can create more privilege Map administrator accounts, delegated roles, and service accounts that can mint or assign new admin rights, then remove unnecessary paths that let one compromised identity expand authority.
• Apply runtime governance to all privileged actors Use the same execution-time controls for human admins, NHI credentials, and any agentic systems that can issue management commands, because the failure mode is delegated authority, not identity type.

Key takeaways

• The breach shows that a trusted administrator account can become a destructive weapon when standing privilege is left in place.
• The scale of impact, nearly 80,000 wiped devices, proves that identity compromise can be an enterprise availability event, not only a confidentiality issue.
• The control that matters most is runtime enforcement, including ephemeral privilege and multi-admin approval at the moment of execution.

Key terms

• Standing Privilege: Standing privilege is access that remains active even when no immediate task requires it. For NHI programmes, it is a common failure mode because long-lived credentials and persistent roles create unnecessary exposure. Reducing standing privilege usually means tighter expiry, on-demand access, and clearer review of who or what still needs access.
• Zero Standing Privilege: A control model in which an identity does not keep persistent access unless it is actively needed. For NHIs, this means credentials and permissions are issued for a narrow task and then removed. It reduces the time window and reuse value of stolen access.
• Multi-admin approval: Multi-admin approval is a governance control that requires more than one administrator to authorise a high-impact action. It reduces the chance that a single stolen credential can execute destructive changes such as device wipe, deletion, or policy removal without challenge.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.

What's in the full article

Britive's full blog covers the operational detail this post intentionally leaves for the source:

• The exact Intune command path and privileged workflow that enabled the wipe sequence.
• The runtime PAM and ZSP pattern the vendor describes for replacing standing administrative access.
• The multi-admin approval mechanics for destructive endpoint actions such as wipes and RBAC changes.
• The broader application of the same control model across human, NHI, and agentic identities.

👉 Britive's full post covers the trusted-admin failure mode, ZSP model, and multi-admin approval pattern in more detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an identity security programme, it is worth exploring.