APK sideloading: how to control installs and check apps safely

Most Android malware that reaches enterprise users is installed by the user from outside Google Play, usually after a convincing message tells them to. Sideloading, installing an APK from a browser download, messaging app, file share, third-party store or USB, bypasses the store review that catches much of the harmful code, and it is the main delivery route for banking trojans and remote access malware. This guide explains how Android decides whether an install is allowed, how Google Play Protect and the new Android developer verification change the picture, which enterprise policies close the gap in each management mode, and how to vet an APK safely when a business genuinely needs one. It is for mobile and endpoint engineers, MDM administrators and SOC analysts.

Key takeaways

• Install permission is per app. Since Android 8.0 there is no single "unknown sources" switch: each installing app (browser, file manager, chat app) needs the user to grant it "Install unknown apps", which is exactly the prompt attackers coach users through.
• Managed devices can turn it off completely. On fully managed devices and work profiles, the Android Management API advancedSecurityOverrides.untrustedAppsPolicy blocks untrusted apps, and googlePlayProtectVerifyApps forces Play Protect verification on.
• Developer verification raises the bar for unverified apps. From 30 September 2026, certified Android 7+ devices in Brazil, Indonesia, Singapore and Thailand get the protections for participating stores, with global expansion planned from 2027; users installing unverified apps must go through a one-time advanced flow with a 24-hour wait.
• ADB is the exception. Google states ADB installs are not subject to verification and the waiting period does not apply, so USB debugging and developer options remain a control point for managed fleets.
• Vet, sign-check and distribute privately. When an app cannot come from Play, verify its signing certificate against the publisher, scan it, and push it as a private app through the managed store rather than asking users to sideload.

How sideloading reaches users

The behaviours that follow installation, such as abusing accessibility services and overlay screens to capture credentials and one-time codes, are covered in the Android Banking Trojans Guide and the Mobile Malware Guide. This page is about stopping or controlling the install.

How Android decides whether an install is allowed

• Per-app install permission: from Android 8.0, an app that wants to install APKs must declare REQUEST_INSTALL_PACKAGES and the user must allow it under Settings, "Install unknown apps", for that specific app. Granting it to a browser lets any page the user visits deliver an APK with one more tap.
• User restrictions: Android 8.0 removed the old "Allow unknown sources" setting; to stop unknown-source installs, device policy applies the DISALLOW_INSTALL_UNKNOWN_SOURCES user restriction. Managed profiles created on Android 8.0 and later have it enabled automatically, so a work profile that allows sideloading has had it switched off deliberately.
• Google Play Protect: on by default, it checks apps when installed and periodically scans the device, including apps from other sources. It can ask to send an unknown app to Google for a code-level evaluation, notify, disable or remove harmful apps, block known harmful apps or URLs, and stop installation of unverified apps that request sensitive permissions often used in financial scams.
• Android developer verification: developers register package names and signing keys and verify their identity. Unverified apps can be installed only through the advanced flow or ADB once protections apply. Enterprise apps distributed through the organisation's managed store do not need verification, though Google recommends registering them.
• Signature continuity: Android accepts an update only when it is signed with the same key as the installed app (or a rotated key in the APK Signature Scheme v3 lineage), so a malicious "update" from another source cannot replace a legitimate app in place.

The developer verification advanced flow

Google's FAQ describes a one-time setup for users who choose to install apps from unverified developers: enable developer mode, confirm nobody is coaching them, restart and reauthenticate (which "cuts off any remote access or active phone calls a scammer might be using"), wait a one-time one-day period, then confirm with biometrics or PIN and enable the flow for seven days or indefinitely. A warning about the unverified developer still appears at install, with an "Install Anyway" option. For defenders the useful facts are that developer mode is a precondition, which managed devices can block, and that ADB bypasses the flow entirely.

Enterprise controls by management mode

• Legacy policy names: the Android Management API replaced installUnknownSourcesAllowed with untrustedAppsPolicy in December 2019; the old TRUE mapped to ALLOW_INSTALL_DEVICE_WIDE and FALSE to ALLOW_INSTALL_IN_PERSONAL_PROFILE_ONLY. ensureVerifyAppsEnabled was replaced by googlePlayProtectVerifyApps in 2021. Old EMM templates still carry the old names, so check what is actually enforced.
• Personal side of company-owned devices: decide whether sideloading is allowed in the personal profile. Malware on the personal side cannot read work profile data directly, but it can capture what the user types into personal apps, including codes used for work sign-in.
• Private Space: on Android 15 and later, a user's Private Space can host a separate app store and hidden apps, and on company-owned work profile devices administrators can disallow it.

See the Android Enterprise Security Guide for the management modes and the Mobile Device Management Security Guide for EMM hardening.

Choosing a sideloading stance

Small organisations without an EMM can still require Play Protect to stay on through user guidance, require phishing-resistant sign-in for work apps, and tell staff that IT will never ask them to install an APK. Large organisations should make "no sideloading on managed devices" the default and track exceptions with an owner and expiry date.

Safe checks when an APK is genuinely needed

Some business apps are not on Google Play: hardware vendor utilities, regional apps, in-house builds. Treat each one as a software supply chain decision, not a user task.

1. Get it from the publisher: obtain the APK or App Bundle directly from the vendor's authenticated channel, never from an APK mirror site or a chat attachment.
2. Verify the signing certificate: run apksigner verify --print-certs on an analysis workstation and compare the certificate SHA-256 digest with a value the vendor publishes or sends through a separate channel. Record the digest; future updates must match it.
3. Check the package name and permissions: confirm the package name matches the vendor's documented one, and review requested permissions. Accessibility service, REQUEST_INSTALL_PACKAGES, SMS, notification listener and device admin requests need a business justification.
4. Scan and analyse: scan with your mobile threat defence or malware analysis service in a sandbox, and for high-risk apps run a static and dynamic assessment as described in the Mobile App Security Testing Guide.
5. Check developer registration: once developer verification is in force in your region, ask the vendor to confirm the package is registered, so users do not see unverified developer warnings outside the managed store.
6. Distribute privately: upload the app as a private app in managed Google Play (or your EMM's equivalent) and assign it to the users who need it. Users then never need install permission for a browser or file manager.
7. Own the update path: record who checks and republishes each update, and remove the app when the business need ends.

Rolling out sideloading controls

1. Baseline: export from the EMM which devices allow untrusted apps, have Play Protect verification enforced and have developer options available. Note which use deprecated policy fields.
2. Find current sideloaded apps: list installed packages on managed devices whose installer is not Google Play or the EMM, and classify them: business need, harmless, remove.
3. Publish the exceptions privately: move each legitimate sideloaded app to managed Google Play before blocking.
4. Pilot: apply untrustedAppsPolicy blocking, enforced Play Protect verification and disabled developer settings to an IT ring for two weeks; confirm line-of-business apps still update.
5. Roll out by ring: frontline and kiosk devices first, then knowledge workers, then executives (who need direct support).
6. Roll back: revert the policy for a ring in the EMM if a critical app fails; fix by private publishing, then reapply.
7. Educate: tell users that legitimate banks and IT teams do not ask them to install apps from links or enable developer mode, and that a request to do so during a call is a scam signal.

Detection and measurement

• Coverage: share of managed devices with untrusted apps blocked in the managed scope; target 100% outside approved exceptions.
• Enforcement health: share with Play Protect verification enforced and developer settings disabled.
• Exception hygiene: number of sideload exceptions with an owner and expiry, and the number past expiry.
• Private publishing rate: share of non-Play business apps delivered as private apps rather than sideloaded.
• Time to contain: from harmful app detection to device quarantine and session revocation.

Where identity fits

A sideloaded trojan rarely wants the device for its own sake: it wants the identities on it. Accessibility abuse and overlays capture passwords, one-time codes and push approvals, and malware on a phone that holds an authenticator turns that phone into an MFA bypass. Plan for it: prefer phishing-resistant passkeys bound to the device's hardware over SMS and OTP codes, require a compliant managed device for access to sensitive apps, and when a harmful app is detected treat every account used on that device as exposed, revoking sessions and refresh tokens, not only cleaning the phone. The traffic runs the other way too: anyone holding an APK can unpack it, which is how the Symantec hard-coded AWS keys research found cloud credentials in 1,859 Android and iOS apps, so never ship an APK outside the store on the assumption that its embedded keys stay private. See the OAuth for Native and Mobile Apps Guide and the Leaked Credential Response Playbook.

Common failure patterns

• Granting install permission to the browser "just once": the grant persists for that app until revoked, so every later download is one tap from installing.
• Deprecated EMM settings: templates still using installUnknownSourcesAllowed or ensureVerifyAppsEnabled report a setting that no longer has any effect.
• IT normalising sideloading: help desk staff who send APKs by email teach users that installing from a link is normal, which is the habit scammers rely on.
• Leaving developer options open: ADB installs bypass developer verification and its waiting period, so managed devices with USB debugging available keep a back door.
• Cleaning the device but not the identity: removing the trojan without revoking sessions and resetting credentials leaves the attacker with whatever was captured.
• Trusting a file name or icon: repackaged APKs use the real app's name and icon (ATT&CK T1655.001); only the signing certificate proves who built it.

Framework mapping

Practitioner checklist

• Block untrusted apps with untrustedAppsPolicy on every fully managed device and work profile, and decide the personal-side stance for company-owned devices.
• Enforce googlePlayProtectVerifyApps and replace any deprecated policy fields in EMM templates.
• Disable developer options and USB debugging on managed devices, since ADB bypasses developer verification.
• Publish every non-Play business app as a private app in managed Google Play.
• Verify each APK's signing certificate digest with apksigner against a publisher-supplied value before approval.
• Alert on apps installed by a non-Play, non-EMM installer and on new accessibility service grants.
• On a harmful app detection, revoke sessions and tokens for accounts used on the device.
• Track sideload exceptions with an owner and expiry date.
• Tell users that IT and banks never ask them to install apps from links or enable developer mode.

Standards and references

• Android Developers: Android developer verification
• Android Developers: Developer verification FAQ
• Google Play Help: Use Google Play Protect to help keep your apps safe
• Google for Developers: Android Management API release notes
• Android Developers: apksigner
• MITRE ATT&CK: Deliver Malicious Application via Other Means
• NIST: SP 800-53 Rev. 5
• OWASP: Mobile Application Security Verification Standard

Related NHI Mgmt Group resources: Mobile Malware Guide · Android Banking Trojans Guide · Android Enterprise Security Guide · Mobile Threat Defense Buyer's Guide