An attacker who controls your mobile device management (MDM) or unified endpoint management (UEM) platform can wipe, reconfigure or run code on every enrolled device at once, using a channel the devices are built to obey. The platform pushes scripts, applications, certificates and configuration profiles, holds escrowed disk encryption recovery keys and local administrator passwords, and feeds the device compliance signal that access policies trust. A compromise is therefore an endpoint incident, an identity incident and a possible destruction event at the same time. This vendor-neutral playbook covers how the incident shows up, triage, stopping destructive actions first, scoping what was pushed or read, rotating the secrets the platform held, recovering devices and restoring trust in compliance signals, plus evidence and notification. It is for incident responders, endpoint engineers and identity leads, and builds on the Mobile Device Management Security Guide.
Key takeaways
- Stop destructive actions in the first minutes. Remove the attacker's administrative access and require a second administrator to approve wipes and script changes before you investigate anything else; one console session can wipe tens of thousands of devices.
- The platform is a secrets store. Escrowed disk encryption recovery keys, local administrator passwords, enrolment tokens and certificate issuance credentials must be treated as exposed if the attacker could read them.
- Look for what was pushed, not just who signed in. A malicious script, application, root certificate or VPN profile stays on devices after the attacker's account is gone.
- Compliance signals are untrusted for the window. If the attacker could mark devices compliant or enrol their own, every access decision that relied on device compliance needs review.
- Personal devices raise privacy duties. Wipes and data collection on employee-owned devices may be personal data incidents in their own right.
What an MDM or UEM compromise looks like
MITRE ATT&CK describes abuse of central management tools as T1072 Software Deployment Tools. The table maps compromise points to what an attacker can do through them.
| Compromise point | What the attacker can do | What you must check |
|---|---|---|
| Platform administrator account or role (often an identity provider account) | Wipe or retire devices, push scripts and apps, change compliance policy, create more administrators | Every administrative action in the window, and new role assignments (T1098.003 Additional Cloud Roles) |
| API client or application registration with device management permissions | The same actions through the API, often without interactive sign-in or MFA | API client sign-ins and actions; permissions granted in the window |
| Script and application deployment | Run code as system on enrolled devices (T1059 Command and Scripting Interpreter) | Every script and package created or changed, with its assignment and run results |
| Configuration profiles | Install a root certificate (T1553.004 Install Root Certificate), force a proxy or VPN, weaken encryption or lock settings | Profile changes and assignments |
| Escrowed secrets | Read recovery keys and local administrator passwords | Secret view or export events per device |
| Enrolment and certificate connectors | Enrol rogue devices that appear compliant, request device certificates for Wi-Fi or VPN | New enrolments, certificate issuance from the connector |
| Device actions | Mass wipe (T1561 Disk Wipe, T1485 Data Destruction), lock, locate devices | Device action history; devices offline or reset |
The destructive case is not theoretical. In the Stryker device wipe attack in March 2026, an attacker who had obtained an administrator account created a new global administrator in the company's cloud tenant and used the device management platform's own wipe command against enrolled devices, with no wiper malware on the endpoints. Some employees' personal devices were enrolled and lost personal data. CISA's alert after the attack asks organisations to use least privilege when designing administrative roles, enforce phishing-resistant MFA for privileged access, and require a second administrator's approval for high-impact actions such as device wipes, and says these principles apply to other endpoint management software too.
Triggers and first-hour triage
Invoke this playbook for: a wipe, retire or reset command issued to more devices than a normal day; a new platform administrator or a role change outside the change process; a script, application or configuration profile created or reassigned to all devices without a change record; secret view or export activity on recovery keys or local administrator passwords; new API permissions for device management; a burst of new enrolments from unknown hardware; or users reporting devices restarting, resetting or prompting for unexpected certificates.
- Stop destructive actions first: disable the suspicious administrative accounts and API clients, revoke their sessions, and turn on or tighten dual approval for wipes, scripts, applications and role changes. If you cannot do this within minutes, remove device action permissions from every role except named responders.
- Preserve evidence: export the platform audit log, device action history, script and app deployment history and identity provider sign-in logs for administrators, before configuration changes overwrite them.
- Identify the actor's capability: which account or client was used, its role and scope, and whether it could read escrowed secrets.
- Set the window from the earliest unexplained administrative sign-in to now.
- Classify: critical if any destructive action, script deployment or secret export occurred, or if platform administration links to tenant-wide identity administration; high for configuration or enrolment changes alone.
Containment in the right order
- Move responders out of band onto devices and communications that are not managed by the compromised platform, and keep a break-glass path into the identity provider that does not depend on it. See the Break-Glass Account Guide.
- Lock down administration: reduce platform administrators to named responders with phishing-resistant MFA, remove unapproved roles and API permissions, and restrict scope tags or groups so no single role can act on all devices.
- Pause pushes: unassign scripts, applications and profiles created or changed in the window, and stop new deployments until review is complete. Removing an assignment does not undo what already ran, so record which devices received each item.
- Protect device fleets you cannot lose: for critical shared or kiosk devices, clinical devices and executive devices, consider temporarily taking them off the network rather than risking another command.
- Close the enrolment path: suspend open enrolment, revoke enrolment tokens and pause certificate connectors until they are rotated.
- Treat device compliance as untrusted: where access policies grant access based on device compliance, add a temporary requirement such as phishing-resistant MFA for sensitive applications until compliance state is verified. See the Conditional Access Guide.
Scoping what was pushed or read
| Item | How to scope | Response |
|---|---|---|
| Scripts and packages | Platform deployment and run results per device; endpoint detection telemetry for the same hashes | Analyse the content; if malicious, treat each device that ran it as compromised and hand to endpoint response. See the EDR Tampering and BYOVD Response Playbook where the script targeted security tools |
| Configuration profiles | Profile change history; device inventory of installed root certificates, proxies and VPN settings | Remove unapproved profiles; for a rogue root certificate, assume encrypted traffic from those devices could be intercepted in the window |
| Escrowed secrets | Secret view and export events per device | Rotate every viewed or exported secret; if bulk export was possible, rotate all |
| Device actions | Device action history; devices that went offline | Build the recovery list; confirm which devices were personally owned |
| Enrolments | Enrolments in the window against procurement and asset records | Retire unknown devices; revoke certificates issued to them |
| Identity changes | Identity provider audit for roles, applications and credentials added by the same actor | Run the tenant response in parallel. See the Identity Provider Tenant Compromise Playbook |
Rotating the secrets the platform held
| Priority | Secret | Note |
|---|---|---|
| First | Platform administrator credentials and API client secrets or certificates | Replace client secrets with certificate or federated authentication where the platform supports it |
| First | Local administrator passwords escrowed in the platform | Force rotation on every device in scope; old values work offline |
| High | Disk encryption recovery keys escrowed in the platform | Rotate keys for every device whose key was viewed or exported, and for all devices if bulk access was possible; a recovery key read now enables offline data access to a stolen device later |
| High | Certificate connector credentials and enrolment challenges | Rotate, and revoke device certificates issued to unknown devices in the window |
| High | Enrolment tokens and device enrolment program links | Revoke and reissue |
| Medium | Wi-Fi, VPN and application secrets delivered in profiles | Rotate shared secrets such as pre-shared Wi-Fi keys; move to per-device certificates |
| Medium | Platform vendor push service credentials and directory connector accounts | Renew following the vendor's documented procedure; check whether renewal must use the original account, because a mismatch can force every device to re-enrol |
Local administrator and connector accounts are non-human identities with wide reach. Record each one with an owner and rotation method once the incident closes. See the Service Account Security Guide.
Recovering devices and restoring trust
- Restore the platform first: compare policies, scripts, applications, profiles, roles and scope against a verified configuration export, and revert every unexplained change. If the platform is self-hosted and the host or database was reached, rebuild it on clean infrastructure; NIST CSF 2.0 RC.RP-03 asks that restoration assets are verified before use.
- Recover wiped devices by priority: business-critical and front-line devices first, using automated enrolment from the hardware vendor's enrolment programme where available, so devices return to a known configuration without manual setup.
- Re-verify compliance: recalculate device compliance after configuration is restored, and remove temporary access requirements in stages.
- Remove persistence on devices: confirm unapproved root certificates, profiles, applications and local accounts are gone using the device inventory, not just the platform's assignment state.
- Re-enable deployments in stages: pilot group first, then the wider fleet, with dual approval left on permanently for wipes, scripts and role changes.
Evidence and notification
- Preserve: platform audit and device action logs, script and package content as found, configuration exports, identity provider sign-in and audit logs, API client activity, endpoint telemetry from devices that ran pushed scripts, and a list of devices wiped with ownership type.
- Personal data: wipes of personally owned devices, location data and inventory data collected by the platform, and data on devices reachable through a rogue certificate or script may each be personal data incidents for legal to assess. See the Cyber Incident Reporting Requirements Map.
- Operational and sector reporting: a mass wipe that stops operations may trigger sector incident reporting and, for listed companies, disclosure duties; involve legal on the first day.
- Staff: tell employees what happened to their devices and personal data in plain terms, with a recovery route.
Scaling the response
| Decision | Smaller fleet (hundreds of devices, one administrator team) | Large fleet (tens of thousands, delegated administration) |
|---|---|---|
| Containment | Remove all but two named administrators; pause every assignment | Restrict device actions to responders; pause assignments changed in the window and those targeting all devices |
| Secret rotation | Rotate every escrowed secret | Rotate viewed and exported secrets first, then the rest in a planned, dated campaign |
| Device recovery | Manual rebuild is feasible | Automated enrolment and staged waves are essential; pre-agree priority groups |
Detection and measurement
Keep high-priority alerting for at least 90 days on: device wipe, retire or reset volume above a daily baseline; new platform administrators and API permissions; script, application or profile assignments to all devices; secret view and export events; and enrolments from unknown hardware.
- High-impact actions covered by dual approval: wipes, scripts, applications, role changes, which should be 100%.
- Escrowed secrets rotated as a percentage of those in scope.
- Wiped devices restored to service and time to restore the critical group.
- Devices verified free of items pushed in the window, from device inventory.
- Platform administrators with standing access, against the approved list.
Common failure patterns
- Investigating before stopping wipes: the attacker keeps issuing commands while responders read logs.
- Treating it as an endpoint-only incident: the administrator account usually lives in the identity provider, where the attacker may also have created roles and applications.
- Unassigning without remediating: scripts already ran and root certificates are already installed.
- Forgetting escrowed secrets: recovery keys and local administrator passwords read during the window remain valid for years if not rotated.
- Trusting compliance during the window: rogue enrolments marked compliant pass device-based access checks.
- Standing global roles kept for convenience: one account able to act on every device is the blast radius.
Framework mapping
| Framework | Reference | Where it applies |
|---|---|---|
| NIST CSF 2.0 | RS.AN-03, RS.MI-01, RS.MI-02, RC.RP-03, PR.AA-05 | Analysis, containment, eradication, verified restoration, least privilege and separation of duties |
| NIST SP 800-53 Rev. 5 | IR-4, AC-3(2), AC-6, AC-19, CM-5, IA-5, CP-10 | Incident handling, dual authorisation, least privilege, mobile device access control, change restrictions, authenticators, reconstitution |
| MITRE ATT&CK v20 | T1072, T1098.003, T1059, T1553.004, T1561, T1485 | Abuse of management tooling, added roles, script execution, root certificates, wiping and destruction |
| NIST SP 800-124 Rev. 2 | Enterprise mobile device management | Lifecycle and management of organisation-provided and personally owned devices |
Practitioner checklist
- Require a second administrator's approval for wipes, scripts, applications and role changes.
- Scope administrative roles to groups of devices so no day-to-day role can act on the whole fleet.
- Remove standing tenant-wide administrator rights and alert on new assignments.
- Inventory API clients with device management permissions, with owners, and alert on new grants.
- Alert on wipe and retire volume above a daily baseline.
- Keep a verified configuration export and a list of critical device groups for recovery order.
- Document how to rotate escrowed recovery keys and local administrator passwords at scale.
- Run a tabletop where an administrator account issues a mass wipe at the start of the business day.
Standards and references
- CISA: CISA Urges Endpoint Management System Hardening After Cyberattack Against US Organization
- NIST: SP 800-124 Rev. 2, Guidelines for Managing the Security of Mobile Devices in the Enterprise
- NIST: SP 800-61 Rev. 3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management
- NIST: SP 800-53 Rev. 5, Security and Privacy Controls
- NIST: Cybersecurity Framework 2.0
- MITRE ATT&CK: Software Deployment Tools
- NCSC: Secure system administration, risk manage administration using tiers
Related NHI Mgmt Group resources: Mobile Device Management Security Guide · UEM Buyer's Guide · If your patch management tool is compromised · Identity Provider Tenant Compromise Playbook