Mobile Incident Response Checklist (IR) — Step-by-Step Guide for Security Teams

A mobile incident response checklist gives security teams a repeatable way to contain, investigate, and recover from iOS/Android incidents without destroying evidence. Because most modern mobile compromises involve identity, tokens, and cloud access, this guide treats the phone as only one part of the attack path.

How mobile incident response works

Mobile IR works best when you assume the device is only one part of the story. Many mobile compromises succeed by abusing SSO, refresh tokens, OAuth consent, and cloud sync, so response must cover endpoints (the phone), identity (IdP/MFA), and services (email, MDM, collaboration apps).

If you also need to coordinate investigation across user endpoints (laptops/desktops) during a broader incident, see this Windows endpoint comparison guide: best antivirus for windows business endpoints 2026.

Step-by-step mobile incident response checklist

1) Confirm scope and severity (first 10–30 minutes)

Trigger questions - Is this a lost/stolen device, suspected malware, phishing, SIM swap, or policy bypass (rogue MDM profile, jailbreak/root)? - Which accounts are logged in (email, SSO, VPN, password manager, messaging, finance apps)? - Is the device corporate-owned (COPE/COBO) or BYOD? This dictates what you can collect and remotely control.

Immediate scoping data to capture - User, device model, OS version, device identifier (serial/IMEI where appropriate), phone number/eSIM status - Time of suspected compromise, last known location (if policy allows), last successful sign-in - MDM enrollment state and compliance posture

2) Contain the threat (do before deep investigation)

Containment priorities: stop access, stop spread, preserve evidence.

Device-level containment (via MDM/EMM if available) - Quarantine/lock the device; disable corporate profiles/work container access. - Remove corporate email profile (or block email sync) if you suspect token theft or mailbox compromise. - Disable VPN configuration profiles if they might be abused. - If corporate-owned and risk is high, prepare for remote wipe—but only after evidence capture steps below.

Identity and access containment (often the highest ROI) - Force sign-out of the user across sessions (IdP “revoke sessions”). - Revoke OAuth refresh tokens and app passwords. - Require step-up MFA and reset the password if compromise is likely. - Disable risky legacy protocols and block access from unknown device posture.

Network containment - Block the device from Wi‑Fi/VPN by MAC/device certificate if managed. - Add temporary Conditional Access rules: require compliant device, block jailbroken/rooted signals, require up-to-date OS.

3) Preserve evidence (don’t wipe first)

Mobile investigations often fail because responders wipe immediately. Preserve what you can within your legal/policy boundaries.

Evidence sources to preserve - MDM/EMM logs: enrollment changes, profile installs/removals, compliance events, app install history, remote commands executed - Identity logs: IdP sign-in events, MFA challenges, token grants, risky sign-ins, device posture changes - Email and collaboration audit: mailbox rules, forwarding, OAuth consent grants, file share changes - Mobile threat defense / EDR for mobile logs (if deployed) - Carrier data for SIM swap scenarios (timestamps, SIM/eSIM changes) where available

Technical notes: quick evidence capture checklist (copy/paste)

Evidence to export/save (minimum):
- IdP: sign-in logs (user + device), token revocation events, MFA events
- MDM: device timeline (commands), profile/config changes, app inventory deltas
- Email: audit logs, forwarding rules, suspicious OAuth app grants
- Network: VPN auth logs, Wi-Fi RADIUS logs (if used), DNS security events
- Ticket: user statement + timestamps + screenshots (phish/SMS/app popups)

4) Triage and analyze (what happened and what’s at risk)

Mobile triage is about identifying the attack path and blast radius quickly.

Common incident patterns - Mobile phishing (smishing) leading to credential theft or MFA fatigue/approval - Token theft / OAuth consent abuse (malicious app granted access) - Rogue configuration/profile (iOS) or unknown device admin / accessibility abuse (Android) - Root/jailbreak (policy violation or compromise indicator) - Lost/stolen device with weak unlock controls - SIM swap leading to SMS OTP interception and account takeover

What to verify - OS and patch level; signs of jailbreak/root (from MDM or threat defense signals) - New/unexpected apps installed, especially sideloaded sources (Android) or enterprise-signed apps - New VPN/proxy settings, DNS changes, or installed certificates (man‑in‑the‑middle risk) - New device enrollments or re-enrollments in MDM - Unusual sign-ins: new geolocation, impossible travel, new device fingerprints - Mailbox rules: auto-forwarding, hidden rules, OAuth app grants

Technical notes: investigation cues (log patterns to look for)

Red flags in logs:
- Multiple MFA prompts followed by a successful sign-in
- OAuth consent grants to unknown apps, especially with mail/file scopes
- Enrollment or profile install events outside IT change windows
- Sudden compliance state changes (e.g., "not compliant" -> "compliant") with no patching
- New VPN profile pushed/installed or certificate trust store changes

5) Eradicate (remove persistence and close the door)

Eradication is where you remove the attacker’s foothold—often in the cloud more than on the phone.

Device cleanup actions - Remove suspicious profiles/certificates/VPN configurations. - Uninstall suspicious apps; disable sideloading (Android) where possible. - If integrity is doubtful (root/jailbreak, unknown profile, repeated re-compromise), perform factory reset and re-enroll from a known-good process.

Identity and cloud cleanup actions - Reset password and rotate MFA methods if SIM swap or push-approval compromise is suspected. - Revoke all sessions/tokens; invalidate app passwords. - Remove malicious OAuth apps and revoke their grants. - Review mailbox rules, delegates, forwarding addresses; remove anything unauthorized. - Rotate secrets the device could access (VPN creds, API keys, shared passwords).

6) Recover safely (restore access with guardrails)

Recovery should rebuild trust and prevent immediate re-entry.

Recovery checklist - Re-enroll device into MDM; enforce baseline policies: encryption, screen lock, OS minimum version, app allowlists (where feasible). - Require phishing-resistant MFA for high-risk users (hardware key or passkeys where supported). - Enforce Conditional Access: only compliant devices, block legacy auth, require device-bound tokens when available. - Restore required apps from approved stores; verify app signing and publisher.

Technical notes: “return-to-service” acceptance criteria

Return-to-service gate:
- Device enrolled + compliant in MDM
- OS updated to approved baseline
- No unknown profiles/certs/VPNs
- Account sessions revoked + password reset completed
- MFA method verified (not SMS if SIM swap suspected)
- Email forwarding rules reviewed and clean

7) Document and learn (post-incident improvements)

Treat mobile incidents as a feedback loop for policy, tooling, and training.

Post-incident deliverables - Incident timeline (containment → eradication → recovery) - Root cause and contributing factors (e.g., SMS OTP, unmanaged BYOD, weak Conditional Access) - User impact and data exposure assessment (what data could be accessed via apps/tokens) - Control improvements: MDM coverage gaps, mobile phishing training, token governance, app governance

Hardening recommendations (high impact) - Reduce reliance on SMS OTP; adopt phishing-resistant MFA. - Block OAuth app consent by default; use an admin approval workflow. - Enforce device compliance for email/SSO access. - Monitor for SIM swap signals where possible; add carrier PIN policies for executives/high-risk roles. - Use mobile threat defense/EDR signals to feed access policies (risk-based access).

Common mobile IR scenarios (and what to do first)

Lost or stolen phone

• Revoke IdP sessions + refresh tokens immediately.
• Use MDM: mark device lost, lock, and (if required) wipe after evidence export.
• Validate whether passcode/biometric and device encryption were enabled; assess data exposure based on policy.

Smishing / mobile phishing

• Capture screenshots/URLs from the user and preserve SMS/email headers if available.
• Reset password, revoke sessions, rotate MFA if approvals were granted.
• Hunt for follow-on activity in email rules, OAuth grants, and file sharing.

SIM swap response

• Treat as identity compromise: rotate credentials, remove SMS as a recovery/MFA option, and re-verify MFA enrollment.
• Coordinate with carrier for timestamps, SIM/eSIM changes, and account security notes.
• Expand scope to other accounts that used SMS recovery.

Tooling notes (optional but practical)

• Password manager: Enforcing a managed vault reduces password reuse and speeds recovery when rotations are needed. If you’re standardizing a business password manager, consider 1Password via Try 1Password → for shared vaults, admin controls, and recovery workflows.
• VPN for travel or risky networks: For employees on untrusted Wi‑Fi, a reputable VPN can reduce opportunistic interception risks (it does not “solve” phishing or token theft). Options include NordVPN Check NordVPN pricing → or Surfshark Try Proton VPN →.
• Malware and cleanup support: If your playbook includes endpoint scanning on non-managed devices during triage, Malwarebytes Get Malwarebytes → is commonly used for remediation assistance—pair this with identity log review to confirm containment.

When you’ll encounter this checklist

You’ll use a mobile incident response checklist when: - A user reports a lost or stolen phone with corporate email/SSO access. - Security sees suspicious sign-ins tied to a mobile device (new location, impossible travel, unusual device posture). - A user clicks a link in SMS/WhatsApp and enters credentials (smishing), or approves unexpected MFA prompts. - MDM flags jailbreak/root, unknown profile installs, or sudden policy tampering. - Executives or finance users report phone number takeover symptoms (carrier service loss, unexpected eSIM changes), indicating a potential SIM swap. - You detect unauthorized mailbox forwarding rules or new OAuth grants from mobile app sign-in flows.