Mobile Security Architecture

Key Control Areas

• Certificate Pinning and Transport Security (SC-08, SC-17, SC-23, SC-13, IA-05): Transport security for mobile applications requires more than standard TLS. SC-08 mandates transmission confidentiality and integrity -- for mobile, this means TLS 1.3 with strong cipher suites and strict certificate validation. SC-17 addresses PKI certificate management, which for mobile includes certificate pinning: the app embeds expected server certificate public keys or hashes and rejects connections to servers presenting different certificates, defeating man-in-the-middle attacks via rogue CAs or compromised certificate authorities. Implementation options include public key pinning (preferred for rotation resilience), certificate pinning (simpler but breaks on rotation), and Certificate Transparency log monitoring. SC-23 ensures session authenticity across intermittent mobile connections -- session tokens must survive network transitions (Wi-Fi to cellular) without re-authentication. SC-13 mandates approved cipher suites; mobile apps must enforce minimum TLS versions and disable fallback to deprecated protocols. IA-05 covers authenticator management for client certificates in mutual TLS deployments. Key risk: certificate pinning failures during CA rotation can brick apps at scale -- pin backup keys and implement pin list update mechanisms via a secure out-of-band channel.
• Secure Enclave and Hardware-Backed Cryptography (SC-12, SC-13, IA-07, SI-07, SC-28): Modern mobile devices provide hardware security modules that offer a qualitatively different level of key protection. SC-12 governs cryptographic key establishment and management -- for mobile, this means generating keys inside the Secure Enclave (iOS) or StrongBox/TEE (Android) where keys are hardware-bound and non-extractable. Even a full OS compromise cannot extract enclave-held keys; cryptographic operations execute inside the secure processor. SC-13 mandates approved algorithms: ECDSA P-256 for signing and ECDH for key agreement are the standard enclave-supported algorithms. IA-07 addresses cryptographic module authentication -- the enclave authenticates the calling application before performing operations, preventing unauthorised apps from using stored keys. SI-07 covers integrity verification: Apple's DeviceCheck and App Attest APIs provide hardware-backed attestation that the app binary is genuine and running on a non-compromised device. SC-28 addresses protection at rest: enclave-encrypted data is protected even if the device storage is directly accessed (e.g., via JTAG or chip-off forensics). Architecture decision: prefer Secure Enclave/StrongBox for all sensitive key material; fall back to software KeyStore only when hardware backing is unavailable, and document the reduced assurance.
• Biometric Authentication and Local Identity (IA-02, IA-05, IA-07, IA-12, AC-07): Biometrics on mobile devices provide convenient local authentication bound to hardware security. IA-02 covers user identification and authentication -- biometric authentication (Face ID, Touch ID, fingerprint via BiometricPrompt) verifies the device owner's identity locally before releasing enclave-held keys or authorising sensitive operations. IA-05 governs authenticator management: biometric templates are stored in the secure enclave, never accessible to the OS or applications; the app only receives a success/failure signal. IA-07 ensures the biometric module itself is authenticated and tamper-resistant. IA-12 addresses identity proofing: biometric enrollment is a device-level operation tied to the device owner's identity; the app relies on the platform's enrollment integrity. AC-07 handles unsuccessful authentication attempts: configurable lockout thresholds prevent brute-force attacks on biometric fallback mechanisms (PIN, password). Architecture considerations: never use biometrics as the sole factor for high-value operations -- pair biometric unlock with a server-side token or session that the biometric gates access to. Provide non-biometric fallback (PIN/password) for accessibility. Handle biometric enrollment changes (new fingerprint added) as a security event that may require re-authentication with the server.
• Mobile Payment Security and PCI DSS Scope (SC-12, SC-13, SC-28, AC-03, AU-02, CM-08): Mobile payment applications that store, process, or transmit cardholder data fall within PCI DSS scope. SC-12 and SC-13 mandate encryption of cardholder data using approved algorithms -- for mobile payments, this typically means tokenisation: the actual PAN (Primary Account Number) is replaced with a device-specific token before any network transmission, and the real PAN exists only within a tightly scoped CDE boundary on the device or in the payment processor's environment. SC-28 protects stored payment credentials at rest using enclave-backed encryption. AC-03 enforces access to payment functions -- payment flows should be isolated from general app functionality, with separate API endpoints, authentication tokens, and audit trails. AU-02 defines auditable events for payment transactions: amount, timestamp, token (never PAN), merchant, authorisation result, and any fallback to non-tokenised flow. CM-08 tracks payment-related components including third-party SDKs (payment gateways, card scanners, NFC libraries) that enter PCI scope. Architecture approach: minimise PCI scope by using hosted payment fields (payment processor's iframe/WebView) so the app never handles raw card data. For NFC tap-to-pay, rely on platform payment frameworks (Apple Pay, Google Pay) that manage HCE (Host Card Emulation) within the platform's PCI-validated infrastructure. For hybrid apps handling cardholder data, the WebView displaying card entry fields is in-scope -- ensure no JavaScript bridge can extract card data into the native layer.
• Application Integrity and Resilience (SI-07, SI-06, CM-14, SA-11, CM-07): Client-side integrity is a defence-in-depth layer, not an absolute guarantee -- a sufficiently resourced attacker with physical device access can bypass any client-side check. The goal is to detect commodity malware, automated attacks, and unsophisticated tampering. SI-07 covers software integrity verification: runtime checks should verify the app's code signature, detect repackaging (modified APK/IPA), and identify code injection via dynamic libraries. SI-06 provides security functionality verification: the app should verify that its security functions (encryption, pinning, authentication) are operating correctly and have not been hooked or replaced. CM-14 requires signed components: ensure all app binaries, frameworks, and embedded libraries are code-signed and that signatures are verified at launch. SA-11 covers developer security testing: integrate static analysis (SAST), dynamic analysis (DAST), and mobile-specific tools (MobSF, objection, frida-based tests) into the CI/CD pipeline. CM-07 enforces least functionality: disable debugging interfaces, remove logging of sensitive data, strip debug symbols from release builds, and disable WebView debugging in production. Jailbreak/root detection should be layered: check for known jailbreak artefacts, attempt to write outside the sandbox, detect Substrate/Frida hooks, and verify kernel integrity. Respond proportionally: degrade gracefully (disable payment features) rather than crashing, which creates denial-of-service against legitimate users on managed jailbroken devices.
• Data Protection, Privacy, and Regulatory Compliance (SC-28, PT-02, PT-04, PM-25, AC-04, AC-06): Mobile applications collect rich contextual data -- location, device identifiers, contacts, photos, health data -- that demands rigorous privacy engineering. SC-28 protects sensitive data at rest: use platform encryption (Data Protection/file-based encryption) and supplement with app-level encryption for high-sensitivity data using enclave-held keys. PT-02 establishes authority to process personal data: request only necessary permissions (camera, location, contacts) and only at the point of use, not at app launch. PT-04 covers consent: implement transparent consent flows that explain why each permission is needed and allow granular opt-out. PM-25 mandates data minimisation: avoid collecting device identifiers (IDFA/GAID) unless essential for functionality; use ephemeral identifiers where possible; anonymise analytics data before transmission. AC-04 controls information flow: sensitive data should not leak through pasteboard, app switcher screenshots, keyboard caches, backup files, or system logs. AC-06 enforces least privilege: the app should request the minimum permission set and degrade gracefully when permissions are denied. Regulatory considerations: GDPR requires privacy by design (Art. 25) and data protection impact assessments for high-risk processing; CCPA/CPRA grants consumers deletion rights that the app must honour; Apple App Tracking Transparency (ATT) and Google's Privacy Sandbox impose platform-level consent requirements for cross-app tracking.

When to Use

Enterprise mobile banking and financial services applications requiring PCI DSS compliance and strong authentication. Healthcare mobile applications handling PHI under HIPAA or patient data under GDPR. Any mobile application processing payment card data via NFC, camera-based card scanning, or manual entry. Government and defence mobile applications with high assurance requirements. Consumer applications handling sensitive personal data (health, financial, identity documents) where a breach would cause significant harm. Mobile applications deployed in high-threat environments where targeted attacks on mobile devices are likely (executive communications, journalism, human rights).

When NOT to Use

Simple content-consumption apps with no sensitive data processing or user authentication -- the overhead of enclave-backed cryptography and integrity checks is disproportionate. Applications targeting very old OS versions (pre-iOS 13, pre-Android 8) where hardware security features are unavailable or limited. Rapid prototyping and MVP phases where security architecture investment should be deferred until product-market fit is validated (but plan for retrofit). Progressive Web Apps (PWAs) that cannot access native platform security APIs -- these should use the Web Crypto API pattern (SP-039) instead. Applications where all sensitive operations are server-side and the mobile client is a thin presentation layer with no local data storage or processing.

Typical Challenges

Certificate pinning is the most operationally fragile control: CA rotations, CDN provider changes, and certificate renewals can break pinned connections, causing app-wide outages that require app store updates to fix. Pin backup keys and implement server-driven pin list updates. Secure Enclave key access requires biometric or device passcode authentication, which creates UX friction -- balance security with usability by caching authentication state for short durations. PCI DSS scope for mobile is poorly understood: many organisations incorrectly believe tokenisation removes them from scope entirely, when in reality the tokenisation process itself, the token vault mapping, and any moment where raw cardholder data exists in memory are in-scope. Hybrid apps (WebView-based) create complex security boundaries: the JavaScript bridge between web and native contexts is a high-value attack surface that must be carefully audited. Cross-platform frameworks (React Native, Flutter) abstract platform security APIs, sometimes with reduced capability or delayed support for new platform features. Application integrity checks generate false positives on legitimate enterprise-managed devices with MDM profiles, developer mode enabled, or accessibility services running -- tune detection to distinguish attacker behaviour from legitimate enterprise configurations.

Threat Resistance

This pattern provides layered defence against the mobile threat landscape. Man-in-the-middle attacks are countered by TLS 1.3 with certificate pinning (SC-08, SC-17), preventing interception even when the attacker controls the network infrastructure (rogue Wi-Fi, compromised carrier). Cryptographic key extraction is resisted by hardware-backed key storage (SC-12, SC-13) -- keys in the Secure Enclave/StrongBox cannot be extracted even with full OS compromise. Biometric bypass and credential theft are mitigated by hardware-rooted biometric authentication (IA-02, IA-07) that binds identity verification to the physical device. Payment data leakage is prevented by tokenisation and CDE boundary enforcement (SC-28, AC-03), minimising the window where raw cardholder data exists. Reverse engineering and binary tampering are detected by integrity checks (SI-07, CM-14), raising the cost of attack for banking trojans and repackaged malware. Jailbreak/root exploitation is detected and mitigated through platform integrity verification (SI-06), with proportional response that degrades sensitive features without denying service. Privacy violations and over-collection are prevented by data minimisation (PM-25, PT-02) and least-privilege permission requests (AC-06). The residual risks are: a sufficiently resourced attacker with physical device access can eventually bypass all client-side controls (the 'evil maid' problem for mobile); supply chain attacks on mobile SDKs can compromise the app at build time; and platform zero-day vulnerabilities can undermine the hardware security assumptions.

Assumptions

The target mobile application runs on iOS 15+ and Android 10+ (API 29+), providing access to modern platform security APIs including Secure Enclave, StrongBox, BiometricPrompt, App Attest, and file-based encryption. The backend infrastructure supports TLS 1.3, token-based authentication (OAuth 2.0 with PKCE), and can validate device attestation tokens. For payment scenarios, a PCI DSS-compliant payment processor or gateway is available to handle tokenisation. The organisation has mobile device management (MDM) or at minimum app-level configuration management for enterprise deployments. Developers have access to mobile-specific security testing tools in the CI/CD pipeline.

Developing Areas

• Passkeys (FIDO2/WebAuthn on mobile) are displacing traditional passwords and OTP-based MFA. Platform authenticators (Face ID, fingerprint) create passkeys stored in the Secure Enclave with cloud sync via iCloud Keychain or Google Password Manager. This collapses the authentication stack: biometric verification, hardware-backed key, and phishing resistance in a single gesture. Adoption is accelerating but cross-platform passkey portability remains fragmented.
• Post-quantum readiness for mobile is an emerging concern. Current enclave-supported algorithms (ECDSA P-256, ECDH) are vulnerable to future quantum computers. NIST PQC standards (ML-KEM, ML-DSA) are not yet supported by mobile hardware security modules. Organisations should implement crypto-agility: abstract cryptographic operations behind interfaces that can swap algorithms when platform support arrives. See SP-040 Post-Quantum Cryptography.
• On-device machine learning creates new data protection opportunities: processing sensitive data (health metrics, face recognition, voice analysis) entirely on-device avoids transmitting raw data to servers. Apple's Core ML and Google's ML Kit provide on-device inference. However, model updates, federated learning telemetry, and crash reports can leak information about user data -- privacy engineering must extend to the ML pipeline.
• Supply chain security for mobile SDKs is a growing attack vector. Banking trojans distributed through compromised advertising SDKs, analytics libraries with hidden data exfiltration, and dependency confusion attacks on package managers (CocoaPods, Maven) have all been observed in the wild. SR-03 supply chain controls must extend to mobile SDK vetting, version pinning, and runtime SDK behaviour monitoring.