← Patterns / SP-050 Draft

Mobile Security Architecture

Mobile applications operate in a fundamentally different trust model from server-side systems. The device is physically possessed by the user -- and potentially by an attacker. The application binary is distributed to millions of devices outside the organisation's control. The operating system mediates all hardware access through permission models that the user controls. Network connectivity is intermittent and traverses untrusted infrastructure. These constraints demand a security architecture that assumes the client environment is hostile while still delivering a seamless user experience. This pattern addresses six interconnected security domains: transport security with certificate pinning, hardware-backed cryptography via secure enclaves, biometric authentication for local identity, mobile payment security within PCI DSS scope, application integrity and resilience against tampering, and data protection with privacy controls. Each domain maps to specific NIST 800-53 controls while acknowledging the mobile-specific implementation techniques that NIST covers at the principle level. The architecture centres on defence-in-depth. Transport security (TLS 1.3 with certificate pinning) protects data in transit. The platform's hardware security module (Apple Secure Enclave, Android StrongBox/TEE) protects cryptographic keys -- keys generated in the secure enclave never leave it, even the OS kernel cannot extract them. Biometric authentication (Face ID, Touch ID, fingerprint, iris) gates access to enclave-protected keys, creating a hardware-rooted chain of trust from biometric sensor to cryptographic operation. For payment applications, this chain extends to PCI DSS compliance: cardholder data is encrypted with enclave-held keys, tokenised before transmission, and the payment flow is isolated within a defined Cardholder Data Environment (CDE) boundary. Application integrity checks detect jailbroken/rooted devices, debugger attachment, and binary tampering -- not as absolute defences (a sufficiently motivated attacker can bypass any client-side check) but as layers that raise the cost of attack and detect commodity malware. Privacy controls enforce data minimisation, restrict identifier usage, and provide transparency through consent mechanisms aligned with GDPR, CCPA, and app store policies. The pattern applies to native iOS and Android applications, cross-platform frameworks (React Native, Flutter, Kotlin Multiplatform), and hybrid WebView-based applications. Architecture decisions differ by deployment model: native apps have full access to platform security APIs; cross-platform frameworks access them through bridges with varying fidelity; hybrid apps must carefully manage the boundary between WebView and native contexts to prevent JavaScript bridge exploitation.
Release: 26.02 Authors: Spinoza, Vitruvius Updated: 2026-02-24
Assess
ATT&CK This pattern addresses 461 techniques across 13 tactics View on ATT&CK Matrix →
MOBILE SECURITY ARCHITECTURE SC-08 SC-12 SC-13 | IA-02 IA-07 | SI-07 SC-28 | PT-02 | SR-03 CM-14 | AU-02 RA-05 MOBILE APPLICATION LAYER Application UI Native / React Native / Flutter Screenshot Protection SC-04 AC-04 CM-07 Authentication Module Biometric + Token + Passkey OAuth 2.0 + PKCE IA-02 IA-05 AC-07 SC-23 Integrity & Resilience Root/Jailbreak Detection Binary Tamper Check SI-07 SI-06 CM-14 Data Privacy & Consent Minimisation · Permissions GDPR Art.25 · ATT PT-02 PT-04 PM-25 AC-06 SDK & Dependency Supply Chain CocoaPods · Gradle · npm · Component Inventory SAST · DAST · SCA · MobSF SR-03 SR-04 SA-11 CM-08 RA-05 TLS 1.3 + CERTIFICATE PINNING SC-08 SC-17 AC-17 MOBILE PLATFORM SECURITY Secure Enclave / StrongBox Hardware-Backed Key Storage ECDSA P-256 · Non-Extractable App Attest · Play Integrity SC-12 SC-13 IA-07 SC-28 Biometric Authentication Face ID · Touch ID · Fingerprint BiometricPrompt · LocalAuth Enclave-Gated Key Release IA-02 IA-05 IA-12 AC-07 BACKEND SERVICES API Gateway Token Validation · Rate Limiting Device Attestation Check AC-03 SC-07 SI-10 Identity Provider OAuth 2.0 + PKCE Step-Up Auth · MFA IA-02 SC-23 Security Monitoring & Audit Transaction Logging · Anomaly Detection · Fraud Signals Device Integrity Monitoring · Incident Response AU-02 AU-12 SI-04 PCI CARDHOLDER DATA ENVIRONMENT Payment Processor Tokenisation Service PAN → Token Mapping Apple Pay / Google Pay HCE SC-12 SC-13 SC-28 Hosted Card Fields Processor iframe / WebView App Never Handles PAN SAQ A-EP Scope Reduction AC-03 AU-02 Vulnerability & Update Management Forced App Updates · OS Version Enforcement Dependency Scanning · Quarterly Mobile Pen Test SI-02 SA-22 CM-06 CM-02 ENCRYPTED LOCAL STORAGE · FILE-BASED ENCRYPTION · KEYCHAIN / KEYSTORE SC-28 SC-12 SC-13 MP-06 SA-08 AT-02 SP-050: Mobile Security Architecture 38 NIST 800-53 Rev 5 controls across 13 families · Authors: Spinoza, Vitruvius · Draft · 2026-02-24 Control flow Data flow XX-00 NIST control (click to view) Zone boundary PCI CDE scope Resilience opensecurityarchitecture.org Related: SP-003 Privacy Mobile · SP-024 iPhone · SP-026 PCI Full · SP-029 Zero Trust · SP-032 Modern Auth · SP-033 Passkey · SP-039 Client-Side Encryption Aligned with: NIST SP 800-53 Rev 5 · OWASP MASVS v2.1 · PCI DSS v4.0.1 · NIST SP 800-124 Rev 2 · Apple Security Framework

Click any control badge to view its details. Download SVG

Key Control Areas

Certificate Pinning and Transport Security

SC-08SC-17SC-23SC-13IA-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-12SC-13IA-07SI-07SC-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-02IA-05IA-07IA-12AC-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-12SC-13SC-28AC-03AU-02CM-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-07SI-06CM-14SA-11CM-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-28PT-02PT-04PM-25AC-04AC-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.

Related Patterns

Patterns that operate within or alongside this one. Click any to view.

SP-003 Privacy Mobile Device Pattern SP-024 iPhone Pattern SP-026 PCI Full Environment SP-029 Zero Trust Architecture SP-032 Modern Authentication SP-033 Passkey Authentication SP-039 Client-Side Encryption and Data Privacy
AC: 5AT: 1AU: 2CM: 4IA: 4MP: 1PM: 1PT: 2RA: 1SA: 3SC: 8SI: 4SR: 2
AC-03 Access Enforcement
AC-04 Information Flow Enforcement
AC-06 Least Privilege
AC-07 Unsuccessful Login Attempts
AC-17 Remote Access
AT-02 Security Awareness
AU-02 Auditable Events
AU-12 Audit Record Generation
CM-06 Configuration Settings
CM-07 Least Functionality
CM-08 Information System Component Inventory
CM-14 Signed Components
IA-02 User Identification and Authentication
IA-05 Authenticator Management
IA-07 Cryptographic Module Authentication
IA-12 Identity Proofing
MP-06 Media Sanitization and Disposal
PM-25 Minimization of Personally Identifiable Information Used in Testing, Training, and Research
PT-02 Authority to Process Personally Identifiable Information
PT-04 Consent
RA-05 Vulnerability Scanning
SA-08 Security Engineering Principles
SA-11 Developer Security Testing
SA-22 Unsupported System Components
SC-04 Information Remnance
SC-07 Boundary Protection
SC-08 Transmission Integrity
SC-12 Cryptographic Key Establishment and Management
SC-13 Use of Cryptography
SC-17 Public Key Infrastructure Certificates
SC-23 Session Authenticity
SC-28 Protection of Information at Rest
SI-02 Flaw Remediation
SI-06 Security Functionality Verification
SI-07 Software and Information Integrity
SI-10 Information Accuracy, Completeness, Validity, and Authenticity
SR-03 Supply Chain Controls and Processes
SR-04 Provenance