Side-loaded applications on Android-based mPOS

1. Mechanism

PCI MPoC [1, 2] specifies the requirements for accepting card payments on commercial off-the-shelf (COTS) devices — typically Android phones and tablets running a SoftPOS application. The specification scopes the merchant payment application and its operating runtime: the application must be hardened against co-resident attacks, must use platform attestation, must enforce PIN entry through a certified secure-PIN-entry mechanism, and must monitor for tamper indications.

The structural fact: the certified application runs on a shared Android instance. It does not run on a dedicated, hardened OS image. Other applications — vendor utilities, device-management agents, productivity apps the merchant installed, and, on devices where unknown sources are enabled, side-loaded APKs — share the same kernel, the same user space, and the same platform APIs.

A side-loaded APK in this environment can attempt parts of the Theme 3 mobile-runtime attack catalogue, with each attack carrying its own privilege precondition:

• Overlay injection, accessibility-service abuse, malicious IME, screen-capture, snapshot timing. These are platform-API attacks available to any installed app holding the relevant permission grant — they do not require root. They operate on the cross-app surfaces the platform exposes.
• Library injection (Frida/Xposed) and runtime memory rewriting. These require root, a debuggable target, or the attacker repackaging-and-resigning the payment APK; they are not available to a side-loaded peer of a release-build payment app on a non-rooted device.
• Debugger attachment to a release-build target. Blocked by SELinux + ro.debuggable=0 on stock Android.

PCI MPoC’s PIN-entry isolation control matters here: the standard requires PIN bytes to be entered into a Secure Card Reader for PIN (SCRP) or an attested secure CDE / monitored PIN-entry surface. Overlay/IME/accessibility attacks against that surface do not capture PIN bytes — the bytes do not flow through the cross-app surfaces a side-loaded peer can read. What the attacks can capture in practice is PAN-entry (card-not-present manual entry), amount-display values shown to the merchant, and the consent moment — important attack surface, but distinct from PIN-block recovery. PCI MPoC’s tamper-monitoring requirements are about detection of these compromises within the shared user space; preventing the host OS from running other apps is not the standard’s posture.

2. Where in the runtime it operates

Three surfaces matter:

• Install source. The Android per-app REQUEST_INSTALL_PACKAGES permission [3] (the modern replacement for the device-wide INSTALL_NON_MARKET_APPS setting deprecated at API 25 / Android 8.0) determines whether arbitrary APKs can be installed. Many mPOS deployments lock this off via Mobile Device Management (MDM); others do not. In practice, most certified mPOS programmes also require the APK to be signed with a key tied to the device manufacturer or the acquirer — there is no consumer App Store path on these devices. A merchant who side-loads is either using an MDM channel that re-uses an authorised signing key or a field-installer flow the operator has explicitly opened. A truly arbitrary APK from outside that signing chain is rejected at install on a correctly-provisioned fleet; the attack surface that remains is the legitimate signing chain plus the in-process surfaces below.
• Runtime co-residence. Once installed, an APK runs in the same Android user space as the payment app. Cross-app attacks use the platform APIs documented in Theme 3.
• Attestation chain. PCI MPoC requires hardware-backed attestation of the payment-app key. Side-loaded APKs do not forge a valid attestation chain, but they do not need to — their attacks operate inside the payment app’s address space via the cross-app surfaces.

3. Which checkpoints it bypasses

• PCI MPoC tamper-monitoring. The standard requires the payment app to monitor for indicators of compromise — root, hooking, debugger, suspicious accessibility services. The monitoring’s effectiveness depends on the implementation; detection-vs-bypass dynamics described in hook-detection-bypass apply.
• Hardware attestation on the payment-app key. Validates; the attestation does not see what other apps on the device are doing.
• Play Integrity. Returns a verdict for the calling APK (the payment app); does not enumerate side-loaded peers.

4. Which signals make it observable

device.integrity and runtime.environment. The Trusted Runtime Primitive observes:

• The list of installed packages on the device, with their install sources (getInstallSourceInfo() on Android 11+, API 30) and signature chains. Note: getInstallSourceInfo() returns information for packages the host app can already see; full package enumeration requires QUERY_ALL_PACKAGES, which Google Play Policy restricts to a small set of explicit use-case exemptions. mPOS apps typically obtain the broader visibility either through one of those Play-policy exemptions or by running in a Device Policy Controller / device-owner role under an MDM (the DPC role grants additional package-visibility APIs that bypass standard restrictions); device-owner status by itself is necessary but not sufficient. Consumer-distributed COTS apps without an exemption or DPC context see a filtered package list.
• Indicators that any installed package has been side-loaded (install source matches com.google.android.packageinstaller with the unknown sources path, or no install source recorded).
• The set of accessibility services, IMEs, and overlay-permitted packages active concurrently with the payment flow — the Theme 3 signal classes.

5. Evidence Token shape when observed

The following example is illustrative; field names, type values, and schema are defined in YEI-001 §4 (available through the spec-access process).

{
  "ev": [{
    "ts":   "2026-06-15T10:23:14Z",
    "class": "device.integrity",
    "type":  "package_inventory",
    "data": {
      "sideloaded_count": 2,
      "sideloaded_during_payment": [
        {
          "package":         "com.example.unknown",
          "install_source":  "unknown",
          "signed_by":       "F1:23:…:AB"
        }
      ],
      "mpoc_environment": "shared_android_userspace"
    }
  }]
}

The composition is the point: PCI MPoC is the certification regime; the package inventory + Theme 3 signals produced by Execution Evidence Infrastructure (EEI) — the device-identity infrastructure layer for banking and payments — are the runtime evidence the regime asks the merchant runtime to produce.

6. Cross-references

• Sibling articles: pos-tampering, os-downgrade-attacks
• Theme 3: overlay-injection, accessibility-service-abuse, library-injection-frida-xposed
• Site: /pos

7. External references

[1] PCI Security Standards Council. Mobile Payments on COTS (MPoC) Standard. www.pcisecuritystandards.org/document_library/?category=mobpayments. Cited 2026-02-20.

[2] PCI Security Standards Council. PCI MPoC Functional Requirements. www.pcisecuritystandards.org/documents/PCI_MPoC_Specification.pdf. Cited 2026-02-20.

[3] Android Developers. REQUEST_INSTALL_PACKAGES permission. developer.android.com/reference/android/Manifest.permission#REQUEST_INSTALL_PACKAGES. Cited 2026-02-20.

[4] Android Developers. QUERY_ALL_PACKAGES policy. support.google.com/googleplay/android-developer/answer/10158779. Cited 2026-02-20.