Stryker MDM Cyberattack: Lessons for the Jamf Ecosystem

# Stryker MDM Cyberattack: Lessons for the Jamf Ecosystem

Briefing Document — March 2026

1. Stryker incident

Please read Jamf's Commitment to Access Security for a pre-amble on the Stryker incident and Jamf's advisory.

Critical Takeaway

This was not a malware attack. It was a living-off-the-land attack using the MDM platform's own legitimate administrative capabilities. The operating system obeyed the wipe command because it came from its trusted MDM server. No endpoint detection tool would catch it --- the commands were legitimate.

Why This Matters for the Jamf Ecosystem

Every MDM platform --- Jamf Pro included --- has the ability to issue remote wipe commands. This is a core, necessary feature. The Stryker attack demonstrates that the management plane itself is a high-value target, and that MDM platforms must be treated as Tier 1 critical infrastructure.

The key failure points at Stryker were:

Standing privileged access: Admin accounts with permanent, broad privileges
Credential compromise: Global Admin credentials were obtained (likely via AiTM phishing)
No multi-admin approval: A single compromised account could issue destructive commands at scale
Insufficient monitoring: Bulk wipe commands were not flagged or blocked in real time

The question is: How would the Jamf ecosystem provide checks against this exact attack pattern?

Jamf Security Controls

SSO Federation to an Identity Provider (IdP)

The Stryker gap: Attackers compromised admin credentials and accessed the Intune console directly. Standard MFA was reportedly bypassed via AiTM techniques.

How Jamf addresses this:

Jamf Account SSO (OIDC): Jamf now supports centralized SSO through Jamf Account using OpenID Connect. You configure your IdP (Entra ID, Okta, etc.) once in Jamf Account, and it flows across Jamf Pro, Jamf Protect, and Jamf Security Cloud. This consolidates the authentication surface.
IdP group-based privilege mapping: Jamf Pro supports mapping IdP groups to privilege sets. When an admin authenticates via SSO, their group membership in the IdP determines what they can do in Jamf Pro. This means privilege levels are centrally managed in the IdP --- not scattered as local Jamf Pro accounts.
Conditional Access at the IdP layer: Because Jamf admin authentication flows through the IdP, all IdP-level controls apply: device compliance checks, phishing-resistant MFA (FIDO2/passkeys), geographic restrictions, impossible travel detection, and session risk evaluation --- all before the admin ever reaches the Jamf Pro console.
Break-glass account strategy: Jamf recommends maintaining at least one local, non-SSO admin account accessible only via a failover URL. This provides emergency access if the IdP connection fails, while keeping the primary attack surface behind strong IdP controls.
Disable Jamf ID direct login: Once OIDC SSO is configured, organizations can disable Jamf ID direct login, forcing all authentication through the IdP and its associated security policies.

Infrastructure as Code (IaC) Controls

The gap: A single admin account with standing privileges could make destructive changes (including mass wipe) through the web console with no review, no approval workflow, and no rollback path.

How Jamf addresses this with IaC:

Terraform providers for Jamf: There are now two Terraform providers --- the community terraform-provider-jamfpro (Deployment Theory / Lloyds Banking Group) and Jamf's own terraform-provider-jamfplatform for the Platform API. Together they cover policies, profiles, groups, apps, blueprints, compliance benchmarks, and more.
GitOps workflow = mandatory peer review: In an IaC model, configuration changes are defined in code, committed to a Git branch, and go through pull request review and approval before being applied. No single person can push a destructive change without another set of eyes on it.
Eliminate ClickOps standing access: The IaC approach lets you dramatically reduce the number of people who need direct console access. If changes are made via Terraform + CI/CD, interactive admin accounts with write privileges become unnecessary for most operations. You can treat console access as an exception, not the norm.
State management and drift detection: Terraform maintains a state file that represents the intended configuration. If someone makes an unauthorized change via the console (or an attacker does), drift detection will flag it. This provides an additional layer of visibility.
Rollback capability: Because the entire configuration is version-controlled in Git, rolling back to a known-good state is a git revert + terraform apply away. In Stryker's case, the configuration was wiped with no documented path to restore. IaC provides that path by default.
API Roles and Clients for Terraform: Jamf Pro's API Roles and Clients feature lets you create narrowly scoped service accounts for Terraform. The Terraform service account can have permissions to manage policies and profiles but explicitly not have permissions to issue remote wipe commands. This enforces least privilege at the API layer.

Jamf Pro Privilege Sets and RBAC

Directly relevant controls:

Granular privilege sets: Jamf Pro allows custom privilege sets where you can explicitly grant or deny specific capabilities. The "Wipe Computer" and "Wipe Mobile Device" commands are individual, toggleable privileges. You can create admin roles that can manage policies and profiles but cannot issue wipe commands.
API Roles and Clients: Separate from user accounts, these provide programmatic access with custom privilege sets. You can create API clients for automation workflows that never have destructive capabilities.
Audit logs: Every MDM command, including wipe, is logged with the issuing user/account, timestamp, and device target. These logs can be exported and piped to a SIEM (Splunk, etc.) for real-time alerting.
Per-device wipe workflow: Unlike Intune's ability to bulk-wipe from a single action, Jamf Pro's wipe command is issued per-device from the individual device record's Management tab. There is no "select all and wipe" mass action in the standard console UI, which creates a natural friction point against mass destructive actions.

In Summary

The problem: MDM platforms are Tier 1 critical infrastructure. The Stryker attack proved that attackers don't need malware --- they just need admin credentials and the MDM's own tools. The management plane is the new attack surface.

Why ClickOps is dangerous: When admins make changes by clicking through a web console, there's no peer review, no approval workflow, no audit trail beyond basic logs, and no rollback path. A compromised account has immediate, unchecked power.

The Jamf defense stack:

Identity layer: SSO federation through Jamf Account OIDC pushes all authentication through the IdP, enabling phishing-resistant MFA, conditional access, and device compliance --- before anyone reaches the console.
Authorization layer: Jamf Pro's granular privilege sets let you separate configuration management from destructive operations. API Roles and Clients extend this to programmatic access.
Operational layer: IaC with Terraform moves configuration changes from the console to code --- with Git history, pull request review, automated testing, and rollback capability. Standing admin access becomes the exception.
Detection layer: Audit logs, webhooks, and SIEM integration provide visibility into admin actions. Jamf Protect telemetry adds behavioral analysis.
Architecture layer: Jamf Pro's per-device wipe design creates natural friction against mass destructive actions, unlike platforms that support bulk wipe from a single administrative action.

The call to action: Treat your MDM like you treat your cloud infrastructure. Federate authentication. Enforce least privilege. Move to IaC. Monitor everything. The tools exist in the Jamf ecosystem today --- the question is whether your organization has implemented them.

Document prepared March 13, 2026

Sources: Krebs on Security, Forrester, ThreatLocker, 7AI, Industrial Cyber, Hexnode, WION News, HIPAA Journal, trusted.jamf.com, Jamf developer documentation