Android SDK Platform-Tools put a root of trust on every developer laptop: whoever holds an authorised ADB key, or can reach an exposed debug port, gets a shell on the phone. The package Google ships as Platform-Tools contains adb (Android Debug Bridge) and fastboot, the two tools used to install apps, pull data, flash images and unlock bootloaders. Those same capabilities are what forensic examiners, malware operators and thieves with physical access want. This guide explains how ADB and fastboot work from a security angle, how USB and wireless debugging are authorised, what bootloader unlocking and custom ROMs change, and how to block or govern debug access through device management. It is written for endpoint and mobile security engineers, MDM administrators and mobile developers. Fleet enrolment and management modes are covered in the Android Enterprise Security Guide; this page stays on the debug toolchain.
This is an independent guide from NHI Mgmt Group, based on Google's public documentation as of November 2026. It is not sponsored or reviewed by Google. Product features change, so confirm settings against Google's current documentation.
Key takeaways
- ADB is a remote shell by design. The
adbddaemon on the device runs commands sent from a host, including package installs, file transfers and an interactive Unix shell, so debug access should be treated like administrative access. - The RSA prompt is the main gate. Since Android 4.2.2 a device must be unlocked and the user must accept the host's RSA key before ADB commands run; every "Always allow" tap creates a long-lived trust relationship that needs revoking.
- Wireless debugging widens the attack surface. Android 11 and later pair over Wi-Fi with a QR or pairing code, and the legacy
adb tcpip 5555mode opens a network listener that has caused real exposure when left on. - An unlocked bootloader breaks the chain of trust. Unlocking wipes user data, but afterwards the device can boot unsigned images, reports an orange verified boot state and fails hardware-backed device integrity checks.
- Corporate devices should not allow developer options. Block debugging features and USB data transfer through Android Management API policy or your MDM, and grant exceptions only to named development devices.
What the tool does
SDK Platform-Tools is the command-line package that talks to Android devices and emulators. Two components matter for security: adb for a running Android system, and fastboot for the bootloader. Android documentation describes ADB as three parts, and each has a different exposure.
| Component | Where it runs | What it does | Security relevance |
|---|---|---|---|
| adb client | Workstation | Sends commands typed by a user or script | Any local user or malware on the workstation can drive connected devices |
| adb server | Workstation, local TCP port 5037 | Manages connections between clients and devices | One server serves every client, so a compromised host controls every authorised device attached to it |
| adbd daemon | Device | Executes commands, provides adb shell, pm and am | The target: a running adbd with an authorised key is a shell into the device |
| Emulator ports | Workstation, odd ports 5555 to 5585 | adb discovers the first 16 emulators by scanning these ports | Port 5555 is also the default for adb tcpip, so it is the port scanners look for |
| fastboot | Workstation, talks to the bootloader | Flashes partitions, locks and unlocks the bootloader | Controls whether the device boots only signed images |
How debug access is authorised
- Developer options: hidden by default since Android 4.2 (API level 17). USB debugging must be switched on there before adbd accepts USB connections.
- RSA key authorisation: on Android 4.2.2 and later the device shows a dialog asking whether to accept the host's RSA key. Android's documentation states this ensures ADB commands cannot run unless the person can unlock the device and acknowledge the dialog. The host keeps its key pair in the user's
.androiddirectory (adbkeyandadbkey.pub); the device stores accepted public keys until authorisations are revoked. - Wireless debugging: available on phones from Android 11 (API 30) and on TV and Wear OS from Android 13. The workstation pairs once using a QR code or a six-digit pairing code (
adb pair ip:port) and stays paired until the user taps Forget or Revoke adb debugging authorizations. Ticking Always allow on this network marks the network as trusted, and from adb 37.0.0 with Android 17 the device reconnects automatically on that network. Discovery uses mDNS. - Legacy TCP mode:
adb tcpip 5555followed byadb connectswitches adbd to listen on TCP port 5555. It still needs an authorised key, but it is a network service on whatever Wi-Fi the device later joins.
Bootloader unlocking and custom ROMs
AOSP requires retail devices to ship with the bootloader locked, which blocks flashing partitions. The flow to unlock is deliberate: the user enables OEM unlocking in Developer options (which sets get_unlock_ability to 1), reboots to the bootloader (adb reboot bootloader) and runs fastboot flashing unlock. The device must warn the user, then factory reset before it sets the persistent unlock flag, and should clear unused RAM to defeat leftover-memory attacks. A separate unlock_critical state covers critical partitions such as the first-stage bootloader and must need a physical button press.
Once unlocked, the device can boot a custom ROM or a modified boot image, the verified boot state becomes orange, and androidboot.flash.locked reads 0. That is the reason unlocking matters to defenders even though it wipes data: an unlocked phone can no longer prove it runs the manufacturer's certified image, so rooting tools, hooking frameworks and persistent implants become possible.
Defender use cases
Blocking ADB everywhere is not realistic: developers, QA teams, mobile forensics and some support teams depend on it. The aim is to know which use is legitimate and to make each one deliberate.
- Mobile forensics and incident response: logical acquisition over ADB (package lists,
dumpsysoutput, logcat, files the shell user can read) is a standard first step on an unlocked, consenting device. Document the host key used, record every command, and revoke authorisation afterwards. See the Mobile Forensics Guide and the Mobile Spyware Infection Response Playbook. - Malware triage: listing installed packages, granted permissions and enabled accessibility services through ADB is often the quickest way to confirm a banking trojan or stalkerware infection. See the Android Banking Trojans Guide.
- App security testing: testers install builds, read app sandboxes on test devices and capture traffic. Keep these on dedicated test devices that never hold corporate data. See the Mobile App Security Testing Guide.
- Device recovery and reflashing: fastboot is the supported route to reflash a factory image on a device you own, for example after a failed update, followed by relocking the bootloader.
How attackers use the same toolchain
| Abuse path | Precondition | ATT&CK for Mobile | Primary control |
|---|---|---|---|
| Shell access to run commands and binaries | Authorised host or exposed adbd | T1623.001 Unix Shell | Disable debugging features on managed devices |
| Malicious charging station or compromised PC installs apps over USB | USB debugging on and a key accepted | T1458 Replication Through Removable Media | Block USB data transfer; train users to refuse unexpected RSA prompts |
| Physical access attempts on a seized or stolen phone | Physical possession | T1461 Lockscreen Bypass | Strong screen lock; locked bootloader; Factory Reset Protection |
| Replacing system binaries for persistence | Root, usually after bootloader unlock | T1645 Compromise Client Software Binary | Locked bootloader plus device integrity attestation |
| Sideloading apps that bypass store review | ADB install or unknown sources allowed | T1458 | Block unknown sources and debugging; Play Protect on |
MITRE's Enterprise Policy mitigation (M1012) for Android says enterprises should block ADB by preventing users from enabling USB debugging unless specifically needed. Some malware checks the other way round: ATT&CK records that the Chameleon banking trojan checks whether a device is rooted or has ADB enabled and avoids running if so, to stay away from analysts.
Deployment and safe use
Decision guidance: who gets debug access
| Device population | Developer options | USB data | Bootloader | Notes |
|---|---|---|---|---|
| Fully managed corporate phones | Disabled by policy | File transfer blocked | Locked; require device integrity | No exceptions without a ticket and expiry |
| Personally owned with work profile | User controls the device; enforce in the work profile where supported | Block work profile file transfer | Require device integrity for access to corporate apps | Use conditional access, not device restrictions, as the main gate |
| Dedicated or kiosk devices | Disabled | All USB data blocked | Locked | Physically exposed, so treat USB ports as hostile |
| Developer and QA devices | Allowed | Allowed | Locked unless the work needs custom images | Separate group, no production data, quarterly key revocation |
| Forensic lab devices | Per case | Per case | Unchanged from seizure state | Chain of custody governs every action |
Small organisations without MDM can still write the rule down: no developer options on phones that hold work email, and a periodic manual check. Large organisations should build the developer device group as an exception population with an owner, an expiry date and a compensating control such as a dedicated Wi-Fi network for wireless debugging.
Rollout steps
- Inventory first: report, from MDM, which devices currently have developer options or USB debugging enabled and which report an unlocked bootloader or fail device integrity.
- Create the exception group: move genuine developer and QA devices into a separate policy group before tightening anything, so the change does not break builds.
- Pilot the restriction: in Android Management API, the
advancedSecurityOverrides.developerSettingsfield set toDEVELOPER_SETTINGS_DISABLEDblocks developer options, andusbDataAccesscan disallow USB file transfer or all USB data. Device policy controllers built onDevicePolicyManageruse theDISALLOW_DEBUGGING_FEATURESandDISALLOW_USB_FILE_TRANSFERuser restrictions. Other MDMs expose the same controls under their own names. Apply to a pilot ring for two weeks. - Block unknown sources alongside: set the untrusted apps policy to disallow installs and keep Play Protect app verification enforced, so turning debugging off is not undone by sideloading.
- Add integrity to access decisions: require
MEETS_DEVICE_INTEGRITY(or your MDM's equivalent compliance check) for corporate app access. On Android 13 and later this verdict needs hardware-backed proof of a locked bootloader and a certified OS image;MEETS_STRONG_INTEGRITYalso needs a security update within the last year. - Roll out by ring and keep a rollback: expand to all managed devices, keeping the previous policy version so you can revert one group if a business app depends on USB access.
- Govern the developer group: require developers to revoke ADB authorisations on a schedule, forget stale wireless pairings, and never use "always allow" on public or home networks.
Safe use on workstations
- Download only from the official source: take Platform-Tools from developer.android.com or through the SDK Manager, and keep it current. Repackaged "ADB drivers" bundles from download sites are a common malware vector.
- Protect the host key:
adbkeyis a private key that every authorised device trusts. Do not copy it into shared build agents or repositories, and rotate it when a laptop is lost or reimaged. Secret scanners should flag it. See the Certificate and Key File Formats. - Close network modes: after
adb tcpipwork, reconnect over USB and return adbd to USB mode, or reboot. Never expose port 5555 beyond a lab network. - Handle logs as sensitive:
ADB_TRACE=alltraces and logcat captures can contain tokens and personal data; review before attaching them to tickets.
Detection and hardening value
What to monitor
- MDM compliance signals: developer options enabled, USB debugging enabled, unknown sources allowed, and Play Integrity or attestation failures. Alert on a managed device that changes state.
- Integrity verdicts in your apps: an empty
deviceRecognitionVerdictmeans signs of attack such as hooking or root, or a non-genuine device.appAccessRiskVerdictvalues ending inCAPTURINGorCONTROLLINGshow apps that can see the screen or drive input, a common sign of remote-control malware. - Network exposure: scan internal and guest networks for TCP 5555 listeners and treat any finding on a non-lab segment as an incident.
- Workstation telemetry: EDR process events for
adbandfastbooton hosts outside the developer group, and file events onadbkey.
Metrics
| Metric | Target | Source |
|---|---|---|
| Managed devices with developer options enabled outside the exception group | 0 | MDM compliance report |
| Devices failing device integrity with access to corporate apps | 0 | Conditional access logs |
| Developer exception devices past their review date | 0 | Exception register |
| Hosts exposing TCP 5555 on non-lab networks | 0 | Network scans |
| Days from device loss to revocation of the owner's ADB host key on test devices | Under 7 | Incident tickets |
Framework mapping
| Framework | Reference | How it applies |
|---|---|---|
| NIST SP 800-53 Rev. 5 | CM-7 Least Functionality | Developer options and debug services are unneeded functions on production devices |
| NIST SP 800-53 Rev. 5 | AC-19 Access Control for Mobile Devices; CM-6 Configuration Settings | Mobile device restrictions enforced and verified through MDM |
| NIST SP 800-53 Rev. 5 | CM-11 User-installed Software | Sideloading over ADB or unknown sources |
| NIST CSF 2.0 | PR.PS-01; DE.CM-09 | Configuration management applied; devices monitored for adverse events |
| MITRE ATT&CK for Mobile | M1012 Enterprise Policy; T1623.001; T1458; T1461; T1645 | Threat and mitigation mapping in the tables above |
Alternatives
- MDM remote actions instead of ADB for support: most support tasks (app install, log collection, remote lock or wipe) can run through the management channel without enabling debugging. See the Mobile Device Management Security Guide.
- Emulators for development: use emulator images for most debugging, keeping physical debug devices for hardware-specific work.
- Dedicated forensic platforms: commercial and open acquisition tools often use ADB underneath, but add logging and chain-of-custody features that raw commands lack.
Common failure patterns
- "Always allow" everywhere: engineers accept every RSA prompt, so old laptops, shared PCs and build agents stay trusted by personal and test phones.
- adb tcpip left on: a device switched to TCP mode for a demo keeps listening on port 5555 on hotel and home networks.
- Unlocked test devices reused for work: a developer phone with an unlocked bootloader and a custom ROM gets enrolled in the work profile and passes basic checks because only
MEETS_BASIC_INTEGRITYwas required. - Restriction without inventory: debugging is blocked fleet-wide on a Friday, breaking a warehouse app that relied on USB and forcing a blanket rollback.
- Charging station trust: users accept an RSA prompt on a public kiosk or a colleague's PC without understanding that it grants shell access.
Practitioner checklist
- Report which managed devices have developer options, USB debugging or an unlocked bootloader today.
- Create a named developer and QA exception group with an owner and review date.
- Disable developer settings and USB file transfer by policy for all other managed devices.
- Disallow unknown sources and keep Play Protect verification enforced.
- Require device integrity (locked bootloader, certified image) for corporate app access.
- Scan networks for TCP 5555 listeners and remove them outside labs.
- Treat ADB host keys as secrets: no sharing, rotation after laptop loss, secret scanning rules.
- Download Platform-Tools only from the official Android developer site and keep it updated.
- Revoke ADB authorisations on forensic and test devices after each case or quarter.
Standards and references
- Android Developers: Android Debug Bridge (adb)
- Android Open Source Project: Locking and unlocking the bootloader
- Android Developers: Play Integrity API integrity verdicts
- Google for Developers: Android Management API enterprises.policies
- MITRE ATT&CK: Enterprise Policy (Mobile mitigation M1012)
- MITRE ATT&CK: Command and Scripting Interpreter: Unix Shell
- NIST: SP 800-53 Rev. 5
- NIST: Cybersecurity Framework 2.0
Related NHI Mgmt Group resources: Android Enterprise Security Guide · Mobile Forensics Guide · APK Signing · Mobile Malware Guide