Android App Security and Compliance for US Enterprise: What CTOs Need Before Launch in 2026

68% of enterprise Android apps in production fail at least one item on a 12-point Android security checklist. The most common failures are not exotic — they are hardcoded API keys, cleartext HTTP on internal endpoints, and keys stored in app files instead of the Android Keystore.

The Android security baseline

Android security for enterprise apps is more complex than iOS security for a specific reason: Android's open model allows device customization, sideloading, and rooting in ways iOS prohibits. An enterprise app running on a standard Play Store-installed device has a different security surface than one running on a rooted device or a device with a modified OS.

Enterprise Android security therefore requires two layers: securing the app itself against the full range of Android deployment scenarios, and using platform attestation to detect and respond to compromised device states.

The security requirements increase with data sensitivity. A field operations app that manages work orders has different requirements than a healthcare app that logs patient data or a financial services app that executes transactions. The 12-point checklist below represents the baseline for any enterprise Android app handling sensitive data.

Failing any item on this checklist is a compliance risk, a security risk, or both. Most failures are identified in security audits after the app is in production — at the point where remediation requires significant rework. Building to the checklist from the start is cheaper.

The 12-point checklist

The 12 items every enterprise Android app must address before launch.

1. Android Keystore for all cryptographic keys. API keys, authentication tokens, encryption keys, and certificate private keys stored outside the Keystore are extractable from rooted devices.

2. Network Security Config with TLS enforcement. The app's network_security_config.xml must disable cleartext HTTP traffic and enforce certificate pinning for sensitive endpoints. Cleartext HTTP on any endpoint — including internal test endpoints that stayed in production — is a compliance failure.

3. Play Integrity API attestation. Device-level integrity checking that blocks access from rooted devices, tampered app installations, and uncertified devices. Required for financial services and healthcare apps.

4. FLAG_SECURE on sensitive screens. Prevents screenshots and screen recordings of screens displaying sensitive data. Required for any screen showing health records, financial data, or authentication credentials.

5. Root detection with multiple signals. Play Integrity API plus additional checks (RootBeer, file-system indicators) to detect rooted devices. Multiple signals are required because single-signal root detection is bypassable.

6. Biometric API for hardware-backed biometrics. BiometricPrompt with BIOMETRIC_STRONG class authentication uses hardware-backed biometric verification. This is different from screen-lock PIN authentication (BIOMETRIC_WEAK class). Enterprise apps requiring strong authentication must use the correct BiometricPrompt class.

7. Encrypted local storage for sensitive data. Sensitive data stored on the device must be encrypted. EncryptedSharedPreferences and EncryptedFile (Jetpack Security Crypto) provide encryption backed by the Android Keystore. Plain SharedPreferences and unencrypted files are not acceptable for sensitive data.

8. Clipboard restriction for sensitive fields. Android's clipboard can be read by any app with clipboard access. Sensitive input fields — passwords, card numbers, health data — must disable copy-paste or clear clipboard content after a short timeout.

9. Certificate pinning for critical API endpoints. Certificate pinning prevents man-in-the-middle attacks by rejecting TLS certificates that are valid but not from the expected issuer. Required for financial transaction endpoints and health data APIs.

10. Obfuscation and tamper detection. ProGuard or R8 code obfuscation makes reverse engineering harder. Play Integrity API detects modified APKs. Together they raise the bar for attackers attempting to analyze or modify the app.

11. Secure deep link handling. Android deep links that are not properly validated can be exploited for redirect attacks or unauthorized data access. All deep link entry points must validate the incoming data before acting on it.

12. Third-party SDK audit. Every third-party SDK in the app has access to data within its scope. Analytics SDKs that collect device identifiers, advertising SDKs that track user behavior, and crash reporting SDKs that capture app state each create data sharing obligations. Enterprise apps in regulated industries must audit every SDK for compliance implications.

Hardware-backed security

Android devices manufactured after 2018 include hardware-backed security in the form of a Trusted Execution Environment (TEE) or dedicated security chip (StrongBox Keymaster). The Android Keystore uses these hardware components to store cryptographic key material in a protected environment that the main processor cannot access directly.

The security property that matters for enterprise: keys stored in the Keystore cannot be extracted even if the device is rooted and the attacker has full file system access. The key material never leaves the hardware security boundary. Cryptographic operations using the key are performed inside the TEE; the key itself is never exposed to the Android OS.

Keys stored in app files, SharedPreferences, or Android's EncryptedSharedPreferences without proper Keystore backing are extractable from a rooted device. An attacker with root access and forensic tools can extract these keys in minutes.

For enterprise apps that authenticate users to sensitive systems, the difference between Keystore-backed key storage and file-based key storage is the difference between security that holds under attack and security that fails immediately upon device compromise.

Wednesday implements Android Keystore for all key material by default. No client code stores sensitive keys outside the Keystore boundary.

Device integrity attestation

The Play Integrity API provides three verdicts that enterprise apps can evaluate before allowing access to sensitive features.

App integrity: was this app installed from the Play Store or from an untrusted source? Sideloaded apps can be modified. An app that passes the app integrity check is the genuine, unmodified Play Store version.

Device integrity: does this device meet Google's certification requirements? Uncertified Android builds — custom ROMs, heavily modified manufacturer builds — may have weakened security properties. A device that fails the integrity check may have been modified to bypass security controls.

Account integrity: does the user's Google account on this device appear to be genuine? Signals include account age and activity. This verdict is less commonly used in enterprise apps but matters for preventing automated abuse.

Enterprise apps for financial services or healthcare should evaluate Play Integrity attestation at login and before sensitive transactions. The check adds a network round trip but is completed in under 500 milliseconds. For a transaction that involves financial or health data, the latency cost is acceptable.

The Play Integrity API replaced SafetyNet in 2024. Apps still using SafetyNet must migrate to Play Integrity. SafetyNet is deprecated and will be removed from Google Play Services.

Data at rest and in transit

Two categories of data require specific Android security treatment.

Data at rest: all sensitive data stored on the device. This includes database contents, cached API responses, downloaded documents, offline data for field apps, and app preferences containing tokens or identifiers. Sensitive data at rest must be encrypted using keys stored in the Android Keystore.

Jetpack Security Crypto provides EncryptedSharedPreferences and EncryptedFile, both backed by Keystore keys. Room does not provide built-in encryption — SQLCipher or Android's encrypted storage APIs must be added for encrypted database storage. Wednesday uses SQLCipher for sensitive database content in regulated industry apps.

Data in transit: all network communication. Android's Network Security Config allows the app to declare its network security requirements in a configuration file. The configuration should: disable cleartext HTTP for all domains, enforce TLS 1.2 minimum (TLS 1.3 preferred), and optionally pin certificates for critical endpoints.

Certificate pinning adds a maintenance burden — the pinned certificate must be updated before it expires, with a fallback pin in place during transition. Wednesday manages certificate pinning expiration as part of ongoing maintenance for engagements where pinning is implemented.

Compliance-specific requirements

HIPAA mobile requirements beyond the 12-point baseline: explicit session timeout (industry standard is 15 minutes of inactivity for healthcare apps), audit logging of who accessed what PHI and when (stored in an immutable log that is transmitted to a server, not stored only on device), and BAA requirements for any third-party SDK that processes PHI.

SOC 2 Type II for mobile apps: the auditor will ask for evidence of access control implementation, encryption at rest and in transit, vulnerability management (how often dependencies are updated, how security patches are applied), and incident response procedures for mobile-specific incidents (stolen device, compromised credentials).

PCI DSS for payment card apps: no card numbers stored on device, TLS 1.2 minimum for all payment data transmission, screenshot prevention on payment screens, and vulnerability scanning of the app binary. PCI DSS Level 1 merchants require quarterly ASV scans that include mobile app testing.

Financial services (GLBA, state privacy laws): data minimization (do not collect more than required), retention limits (purge locally stored data after defined periods), breach notification procedures, and third-party SDK disclosure for any SDK that collects user data.

Android Enterprise data separation

For BYOD deployments where corporate apps run alongside personal apps on employee-owned devices, Android Enterprise work profile mode provides cryptographic data separation.

The work profile is a separate Android user profile with its own encrypted storage. Apps in the work profile cannot access data from personal apps. Personal apps cannot access data from work apps. The Android OS enforces this separation at the filesystem and API level.

For enterprise apps handling sensitive data on BYOD devices, the work profile model eliminates the most common BYOD data leakage risk: a personal app (analytics SDK, cloud backup, photo sharing) accessing corporate data stored in app files.

Wednesday designs work profile compatibility into enterprise Android apps for clients with BYOD policies. The implementation affects how the app handles cross-profile communication, authentication state, and data storage location.

Wednesday's Android security framework

Wednesday's Android security framework covers all 12 checklist items by default for enterprise clients. No additional scoping is required to get the baseline — it is included.

The framework is implemented as a code template and review checklist. New Android projects start from the secure template, which includes Network Security Config, Keystore key generation, EncryptedSharedPreferences, Play Integrity integration, FLAG_SECURE on sensitive screen templates, and ProGuard/R8 obfuscation.

AI code review rules include Android security patterns: Keystore usage vs file storage, cleartext HTTP detection, unsafe deep link handling, and clipboard data exposure. Security issues are flagged at code review, not in a post-development audit.

Wednesday has delivered Android apps for HIPAA healthcare clients (zero patient logs lost, offline-first architecture, full audit logging), PCI-adjacent fintech clients (zero crashes after rebuild, secure network architecture), and enterprise clients with SOC 2 requirements. The compliance documentation — architecture diagrams, security control evidence, encryption scheme documentation — is delivered as part of the engagement.