Rooted, Jailbroken and Emulated Devices: Risks and Controls

A rooted, jailbroken or emulated device removes the platform guarantees that mobile apps, MDM policies and the people using them quietly depend on. Sandboxing, hardware-backed key storage, verified boot and app store review all assume the operating system is the one the manufacturer shipped and that nothing runs with more privilege than it should. Once that assumption fails, a banking app cannot trust its own integrity checks, an MDM agent cannot trust the device's report on itself, and a user can no longer rely on the protections they think they have. This guide explains what each modification actually changes, the risks to users and to app owners, how Google Play Integrity, Android key attestation and Apple App Attest work as server-side signals, and how to set MDM compliance policy without locking out legitimate users. It is written for mobile app security leads, fraud teams and endpoint administrators.

Key takeaways

The core problem is trust in the platform, not the modification itself: OWASP MASVS-RESILIENCE-1 asks that the app validates the integrity of the platform because so many other controls assume it.
Client-side root and jailbreak checks can be lied to on a compromised device, so the decision belongs on the server, based on signed attestation from Google or Apple.
Play Integrity gives graded verdicts: MEETS_BASIC_INTEGRITY, MEETS_DEVICE_INTEGRITY and MEETS_STRONG_INTEGRITY mean different things, and on Android 13 and later device integrity requires hardware-backed proof of a locked bootloader.
App Attest proves a genuine app instance on Apple hardware with a Secure Enclave key; it is not a jailbreak detector and must be paired with risk logic on your server.
Respond in tiers, not with a blanket block: allow, allow with limits, step up or deny, after a period of measuring in report-only mode, so false positives do not lock out genuine customers or staff.

What rooting, jailbreaking and emulation change

All three break the same chain of trust in different places. On a standard device, the bootloader verifies the operating system, the operating system enforces app sandboxes, and the hardware keystore (Android Trusted Execution Environment or StrongBox, Apple Secure Enclave) holds keys that no process can read. A modified device breaks one or more of these links.

Condition	What is changed	Security guarantee lost	Typical reason
Rooted Android	A process can obtain superuser (UID 0) privileges, usually after unlocking the bootloader and patching the boot image	App sandbox isolation, protection of other apps' private storage, integrity of system binaries	Customisation, ad blocking, custom ROMs, testing, malware with a privilege escalation exploit
Unlocked bootloader (not rooted)	The device will boot images not signed by the manufacturer	Verified boot assurance; key attestation reports the device as unlocked	Developers, custom ROM users
Jailbroken iOS or iPadOS	An exploit chain disables code signing enforcement and sandbox restrictions, allowing unsigned code and tweaks to run	Mandatory code signing, App Store review as a gate, sandbox limits	Customisation, piracy, security research, spyware installation
Emulator or virtual device	The "device" is software on a host computer that can inspect and alter memory, sensors and network traffic	Real hardware keystore, genuine sensor data, physical presence of a person	App development and testing, automated abuse at scale (account creation, bonus abuse, click fraud)
Instrumented or hooked app	A runtime framework injects code into the app process, often on a rooted or jailbroken device	Integrity of the app's own logic, including its root checks	Reverse engineering, bypassing certificate pinning, cheating, fraud

The OWASP MASVS-RESILIENCE category frames this directly: it covers controls that ensure the app is running on a trusted platform, detect or prevent tampering at runtime, and preserve the integrity of the app's intended functionality. It also states that the absence of these measures is not in itself a vulnerability, which matters for how you prioritise. Platform trust is a defence in depth layer on top of correct storage, crypto, authentication and network controls, never a substitute for them.

Risks to users

Most people who root or jailbreak a phone are not attackers, but the device quietly loses protections they rely on.

Malware with full privileges: on a rooted device a malicious app that is granted root can read other apps' data, intercept input and hide itself. Android banking trojans already abuse accessibility services and overlays on unmodified phones; root makes that much easier. See the Android Banking Trojans Guide.
Stalkerware and spyware: someone with physical access can jailbreak or root a device to install monitoring software that would never pass store review. If a person suspects this, the Mobile Spyware Infection Response Playbook covers the next steps.
Delayed or blocked updates: jailbreaks and custom ROMs often depend on staying on a specific vulnerable version, so the device misses security fixes for months.
Weaker key protection: keys may still be generated in hardware, but a rooted system can misuse them on the user's behalf, and software-only keystores on older or modified builds can be extracted.
Loss of services: banking, payment, streaming and enterprise apps may refuse to run, and Play Integrity based checks will fail. Apple's support guidance warns that unauthorised modification of iOS bypasses security features and can cause problems with the device.

Risks to apps and the services behind them

For an app owner the question is what an attacker can do when they control the device the app runs on. A rooted test phone or an emulator is the normal workbench for reverse engineering and for scaling fraud.

App type	Abuse enabled by a compromised or virtual device	Where the real control belongs
Banking and payments	Hooking the app to bypass device binding, replaying or altering transaction requests, overlay and accessibility abuse, running many accounts in emulators	Server-side transaction risk scoring, attested device binding keys, step-up authentication for payees and limits
Enterprise apps under MDM or MAM	Extracting cached corporate data and tokens from app storage, faking compliance state, bypassing copy and paste restrictions	Compliance evaluated from attestation, Conditional Access, short-lived tokens, remote wipe of app data
Games and loyalty schemes	Memory editing, speed hacks, automated farming, bonus and referral abuse	Server-authoritative game state, rate limits, device recall signals
Streaming and paid content	Bypassing licence checks, capturing decrypted content	Hardware DRM levels, server licence checks, app licensing verdicts
Apps with embedded API keys	Extracting keys and secrets from the binary or memory, then calling the backend directly	No long-lived secrets in the app, per-install credentials bound to attested keys

The last row is the identity angle. Any API key, client secret or refresh token shipped in or cached by a mobile app is a non-human credential that an attacker on a rooted device or emulator can lift. The Mobile Apps Hard-Coded AWS Keys 2022 research found cloud credentials embedded in widely used Android and iOS apps; extracting them requires nothing more than the app package. Attestation reduces who can call your API, but it does not make an embedded secret safe. See the Mobile App Security Guide.

Why client-side detection is not enough

Traditional root and jailbreak detection runs inside the app: look for su binaries, known jailbreak files, writable system paths, debugger attachment or emulator properties. OWASP lists the absence of these checks as weaknesses (MASWE-0051 Root/Jailbreak Detection Not Implemented, MASWE-0064 Debugger Detection Not Implemented, MASWE-0065 Dynamic Analysis Tools Detection Not Implemented). They add friction, but they run on the very platform they are judging. Apple's App Attest documentation makes the same point in general terms: an app cannot trust its own logic to check its legitimacy, because a compromised app can falsify the results.

The answer is to move the decision. The app asks a platform service to produce a statement signed by Google or Apple, sends that statement to your backend, and your backend decides. The attacker can still refuse to send it or send a stale one, so the server must require fresh attestation tied to a one-time challenge and treat absence as a risk signal.

Google Play Integrity API

Play Integrity replaced the SafetyNet Attestation API, which Google deprecated in 2022 and fully turned down in January 2025; calls to the old attest method now always fail. Play Integrity returns a signed and encrypted token that your server decodes into several verdicts.

Verdict field	Value	What it tells you
appIntegrity.appRecognitionVerdict	PLAY_RECOGNIZED / UNRECOGNIZED_VERSION / UNEVALUATED	Whether the binary and signing certificate match what Google Play distributes; repackaged apps show UNRECOGNIZED_VERSION
accountDetails.appLicensingVerdict	LICENSED / UNLICENSED / UNEVALUATED	Whether the signed-in account installed or bought the app on Play; sideloads show UNLICENSED
deviceIntegrity.deviceRecognitionVerdict	MEETS_BASIC_INTEGRITY	Passes basic checks only; bootloader may be unlocked and the device may not be certified
	MEETS_DEVICE_INTEGRITY	Genuine certified Android device; on Android 13 and later, hardware-backed proof of a locked bootloader and certified OS image
	MEETS_STRONG_INTEGRITY	Device integrity plus, on Android 13 and later, security updates within the last year for all partitions; on Android 12 and lower check sdkVersion as well
	MEETS_VIRTUAL_INTEGRITY	Only for apps on Google Play Games for PC: an Android emulator with Play services that passes integrity checks
environmentDetails.appAccessRiskVerdict	KNOWN_ or UNKNOWN_ INSTALLED, CAPTURING, CONTROLLING, OVERLAYS	Other apps that could capture the screen, draw overlays or control the device (opt-in)
environmentDetails.playProtectVerdict	NO_ISSUES to HIGH_RISK, POSSIBLE_RISK when Play Protect is off	Play Protect state and whether harmful apps were found (opt-in)
recentDeviceActivity.deviceActivityLevel	LEVEL_1 to LEVEL_4	How many integrity requests the device made for your app in the last hour, a signal for automation (opt-in)

An empty deviceRecognitionVerdict means the device met none of the labels, which is what a typical rooted phone with an unlocked bootloader or a generic emulator returns. On Android 13 and later the optional basic and strong labels are only returned when the app is licensed, so sideloaded builds behave differently in testing.

Standard or classic requests: standard requests take a few hundred milliseconds after a warm-up and include automatic replay protection; classic requests take seconds, need your own nonce logic and are meant for the highest-value actions.
Verify on the server: check requestDetails (package name, requestHash or nonce, timestamp) against your own request before trusting any verdict, and do not cache verdicts.
Quota: the default is 10,000 requests per day across all installs, raised on request, so plan for scale before enforcement.
One signal among several: Google says the API works best alongside other signals and not as the sole anti-abuse mechanism, and recommends gathering telemetry in non-enforcement mode first.

Android key attestation

Key attestation is lower level and does not depend on Play. When an app generates a key in the Android Keystore, it can request an X.509 certificate chain describing that key. If the chain verifies to a Google Hardware Attestation Root and no certificate appears on the revocation list at android.googleapis.com/attestation/status, you know the key lives in secure hardware and has the properties described. The attestation extension records the security level (Software, TrustedEnvironment or StrongBox) and a root of trust that includes whether the bootloader is locked and the verified boot state. Google advises validating on a separate trusted server, using its verification library, parsing only the first key attestation extension in the chain and failing closed. Google also notes that a new attestation root begins signing chains on 1 February 2026, so verifiers must trust both roots. The Hardware key attestation guide covers the wider topic.

Apple App Attest and DeviceCheck

App Attest, part of the DeviceCheck framework, uses a hardware key generated in the Secure Enclave for each user account on each device. Apple's servers certify that the key belongs to a valid instance of your app on genuine Apple hardware.

The app checks DCAppAttestService.shared.isSupported. If false, both app and server must change behaviour rather than fail silently.
The app calls generateKey and stores the returned key identifier; the private key never leaves the Secure Enclave.
Your server issues a one-time challenge of at least 16 bytes. The app hashes it with SHA-256 and calls attestKey, then sends the attestation object and key ID to the server.
The server verifies the attestation (Apple describes this in "Validating apps that connect to your server") and stores the public key.
For sensitive requests the app calls generateAssertion over a fresh challenge plus the request data, and the server verifies the signature and counter.

Keys survive app updates but not reinstallation, device migration or restore from backup, so expect legitimate re-attestation and limit new key generation to those events. Apple notes that keeping the key count low helps detect some kinds of fraud. App Attest proves the app instance and its key are genuine; Apple's documentation does not describe it as a jailbreak detector, so treat a successful attestation as necessary but not sufficient and keep your own risk logic. For managed corporate devices, Apple's Managed Device Attestation serves the MDM side; see the Apple Declarative Device Management and Managed Device Attestation Guide.

Choosing a response: decision guidance

Signal	Low-risk action (browse, read)	Medium-risk action (change profile, add device)	High-risk action (new payee, large payment, export data)
MEETS_STRONG_INTEGRITY or valid App Attest assertion	Allow	Allow	Allow with normal step-up
MEETS_DEVICE_INTEGRITY only	Allow	Allow	Allow, consider extra step-up
MEETS_BASIC_INTEGRITY only (likely unlocked or uncertified)	Allow with limits	Step up	Step up and lower limits, or deny
No device label, UNRECOGNIZED_VERSION, or attestation missing	Allow with limits or CAPTCHA	Deny or route to support	Deny
appAccessRiskVerdict shows CONTROLLING or OVERLAYS	Allow	Warn user	Hold or step up out of band

Consumer apps: blanket blocking frustrates enthusiasts, users of alternative Android builds and people in markets with uncertified handsets. MASVS itself warns about platform lock-in and false positives excluding legitimate users. Tie strictness to the value of the action.
Regulated financial apps: stricter enforcement on payment initiation is usually justified, but keep a supported path (web banking, branch, phone) for customers whose devices fail.
Corporate-owned devices: block. There is no business reason for a managed device to be rooted or jailbroken, and the MDM agent's own reporting depends on platform trust.
Personally owned devices (BYOD): block access to corporate data rather than the device itself, using app protection policy and Conditional Access.
Small organisations: MDM compliance flags plus Play Integrity device integrity and App Attest at login cover most of the risk. Large consumer platforms add device recall, activity levels and a fraud engine.

MDM compliance policy settings

Most MDM products expose similar settings; Microsoft Intune's, as Microsoft names them, are a concrete reference:

Platform	Setting	Options
iOS and iPadOS (Device health)	Jailbroken devices	Not configured, Block (marks jailbroken devices as not compliant)
iOS and iPadOS (Device health)	Require the device to be at or under the Device Threat Level	Not configured, Secured, Low, Medium, High (from a mobile threat defence service)
iOS and iPadOS	Minimum OS version	Version number; non-compliant devices are prompted to upgrade
Android Enterprise (Device health)	Rooted devices	Not configured, Block
Android Enterprise (Google Play Protect)	Play Integrity Verdict	Not configured, Check basic integrity, Check basic integrity & device integrity
Android Enterprise (Google Play Protect)	Check strong integrity using hardware-backed security features	Not configured, Check strong integrity (only when basic or device integrity is required)
Android Enterprise	Minimum security patch level	Date in YYYY-MM-DD format

Compliance state only protects data when something enforces it, typically Conditional Access that blocks non-compliant devices from email, files and SaaS. For the enrolment and policy design side, see the Mobile Device Management Security Guide and the Android Enterprise Security Guide.

How to implement

Threat model the app: list the actions an attacker on a compromised or virtual device would target (login, device binding, payments, data export, API calls with embedded keys) and the value of each.
Remove secrets first: take long-lived API keys and client secrets out of the app; issue per-install credentials bound to a hardware key after attestation.
Integrate attestation in report-only mode: add Play Integrity standard requests and App Attest on sensitive calls, verify on the server, and log verdicts without acting on them for several weeks.
Measure the population: work out what share of genuine sessions fail each label, by OS version, device model and country, before setting thresholds.
Introduce tiered enforcement: start with the highest-risk actions and the clearest signals (UNRECOGNIZED_VERSION, empty device verdict), using step-up or limits before outright denial.
Add client-side checks as friction: root, jailbreak, debugger, hooking and emulator detection plus anti-tampering, aligned to MASVS-RESILIENCE, reported to the server rather than only enforced locally.
Set MDM compliance: pilot Block for rooted and jailbroken devices and a Play Integrity requirement on a test group, confirm Conditional Access behaviour, then widen.
Plan rollback and outages: keep a server-side switch to drop to report-only if a platform service fails or a vendor update causes false failures, and handle UNEVALUATED and serverUnavailable explicitly.

Detection and measurement

Log every verdict: store the attestation outcome, labels, app version, OS version and action requested, so fraud and security teams can correlate failures with account takeover or abuse.
Watch for absence: a client that stops sending attestation, or sends tokens with stale timestamps or mismatched nonces, is a stronger signal than a single failed verdict.
Track emulator-scale patterns: many accounts per device, or LEVEL_4 activity.

Metric	What it shows
Share of sessions with MEETS_DEVICE_INTEGRITY or valid App Attest	Coverage and the size of the population you would affect by enforcing
False-failure rate (genuine users failing, from support contacts and manual review)	Whether thresholds are too strict
Fraud loss or abuse events per 10,000 sessions, split by verdict	Whether the signal actually predicts abuse
Share of managed devices non-compliant for root or jailbreak, and time to remediation	MDM policy health
Long-lived secrets remaining in mobile builds	Progress on removing extractable credentials

Common failure patterns

Enforcing on the client only: the app checks for root and closes itself, but the backend accepts any request, so an attacker simply patches out the check or calls the API directly.
Trusting a verdict without checking the request binding: accepting a Play Integrity token without validating package name, nonce or requestHash and timestamp lets attackers replay a token from a clean device.
Still calling SafetyNet: code paths that depended on the old attestation API now always fail, and some apps silently treat the failure as a pass.
Blocking everything that is not strong integrity: older but genuine phones and devices on Android 12 or earlier lose access, support costs rise and customers move to less protected channels.
Treating attestation as authentication: a genuine app on a genuine device can still be operated by a fraudster with stolen credentials or a coached victim; attestation does not replace user authentication or transaction monitoring.
Shipping embedded secrets and relying on attestation to protect them: the secret leaks from the package regardless of what the device verdict says.

Framework mapping

Framework	Reference	Relevance
OWASP MASVS	MASVS-RESILIENCE-1 (the app validates the integrity of the platform), with RESILIENCE-2 to 4 for anti-tampering, static and dynamic analysis	App-level requirement set for platform trust
NIST SP 800-53 Rev 5	AC-19 Access Control for Mobile Devices; SI-7 Software, Firmware, and Information Integrity; IA-3 Device Identification and Authentication; CM-7 Least Functionality	Control baseline for organisations and app backends
NIST CSF 2.0	PR.AA-03 (users, services and hardware are authenticated); PR.PS-01 configuration management; PR.PS-02 software maintained; DE.CM-09 runtime environments monitored	Programme-level outcomes
MITRE ATT&CK for Mobile v20	T1404 Exploitation for Privilege Escalation; T1626 Abuse Elevation Control Mechanism; T1633 Virtualization/Sandbox Evasion; T1630 Indicator Removal on Host	Attacker behaviours that rooting, jailbreaking and emulation awareness relate to
ISO/IEC 27001:2022 Annex A	A.8.1 User endpoint devices	Policy for devices accessing organisational information

The MITRE ATT&CK for Mobile Guide explains the mobile matrix in more depth.

Practitioner checklist

Inventory every long-lived secret in your mobile builds and replace it with per-install credentials bound to an attested key.
Integrate Play Integrity standard requests and App Attest assertions on sensitive actions, verified on the server with nonce or requestHash checks.
Remove any remaining SafetyNet Attestation code paths and confirm failures are not treated as passes.
Run report-only for several weeks and measure false failures by OS version, device model and country.
Define a tiered response table (allow, limit, step up, deny) per action value and get fraud, product and support to agree it.
Add client-side root, jailbreak, hooking, debugger and emulator checks as reported signals aligned to MASVS-RESILIENCE.
Set MDM compliance to block rooted and jailbroken corporate devices and require Play Integrity device integrity, enforced through Conditional Access.
Keep a server-side kill switch to fall back to report-only during platform outages.
Give users whose devices fail a clear message and an alternative channel.

Rooted, jailbroken and emulated devices: what changes, what breaks, how to respond