Comprehensive System Security Plan and Architecture Definition: SecureAuth Mobile Authenticator

1. Executive Summary

1.1 Program Overview and Strategic Imperative

In an era where digital identity has become the perimeter of the enterprise, the security of authentication mechanisms is paramount. The SecureAuth Mobile Authenticator program represents a critical infrastructure component designed to bridge the gap between user convenience and rigorous cryptographic verification. As a software token application developed using the React Native framework, the program's primary mandate is to generate Time-based One-Time Passwords (TOTP) and HMAC-based One-Time Passwords (HOTP) in strict accordance with RFC 6238 and RFC 4226 standards. However, the operational reality of deploying such a high-value target on consumer-grade mobile devices introduces a complex threat landscape that extends far beyond simple algorithm implementation.

This System Security Plan (SSP) serves as the foundational documentation for the SecureAuth program, articulating the security architecture, risk management framework, and operational controls necessary to safeguard the confidentiality, integrity, and availability of user identity tokens. The choice of React Native as the development framework offers significant advantages in code reusability and cross-platform consistency between iOS and Android ecosystems. Yet, this architectural decision introduces distinct security challenges—specifically, the reliance on a JavaScript execution environment, the potential for bridge-based attacks, and the dependency on a vast, often volatile, open-source supply chain.¹

The urgency of this documentation is underscored by the evolving sophistication of attacks targeting multi-factor authentication (MFA) systems. Adversaries have graduated from simple credential stuffing to sophisticated overlay attacks, token extraction via malware, and supply chain interdiction. Consequently, this report adopts a "Defense-in-Depth" philosophy, aligning with the OWASP Mobile Application Security Verification Standard (MASVS) Level 2 requirements, which are tailored for applications handling highly sensitive data such as financial identifiers and cryptographic secrets.³ Furthermore, the architecture is designed to meet the rigorous control requirements of NIST Special Publication 800-171, ensuring the protection of Controlled Unclassified Information (CUI) within non-federal systems, a critical consideration for enterprise deployments.⁵

1.2 Risk Profile and Compliance Posture

The operational risk profile of the SecureAuth application is classified as High. A compromise of this application does not merely result in the loss of a single user session; it creates a systemic failure point that can bypass the second factor of authentication across a user’s entire digital footprint, from banking to enterprise email access. The threat model analyzed in this report identifies critical vectors including root/jailbreak exploits, memory dumping, screen recording malware, and malicious QR code injection.¹

From a compliance perspective, the application processes data that falls under the purview of the General Data Protection Regulation (GDPR) and various state-level privacy statutes. While the application is designed to function primarily offline, the handling of "Account Metadata"—such as email addresses embedded in issuer strings—constitutes the processing of Personal Identifiable Information (PII). This report details the comprehensive privacy-by-design strategies implemented to ensure lawful processing, data minimization, and the facilitation of data subject rights, ensuring that security controls do not infringe upon user privacy.⁷

2. System Identification and Architectural Scope

2.1 System Description and Purpose

The SecureAuth Mobile Authenticator is a standalone mobile application designed to function as a software security token. Its primary function is to act as a secure vault for shared secrets—cryptographic seeds established between the user and a Relying Party (e.g., Google, Amazon, Enterprise VPN)—and to utilize these secrets to generate ephemeral, time-sensitive passcodes. The system replaces legacy hardware tokens, offering a cost-effective and user-friendly alternative that leverages the trusted execution environments present in modern smartphones.⁹

The application is built upon a hybrid architecture. The user interface and business logic are written in TypeScript using React Native, allowing for rapid iteration and a unified codebase. However, the critical security functions—specifically key storage and cryptographic operations—are offloaded to native modules written in Swift (for iOS) and Kotlin (for Android). This hybrid approach necessitates a security model that bifurcates trust: the JavaScript environment is treated as untrusted for the purpose of long-term secret storage, while the native layer serves as the "Fort Knox" for cryptographic material.¹

2.2 System Boundaries and Interfaces

Defining the system boundary is a prerequisite for accurate threat modeling and auditing. The boundary of the SecureAuth system is defined as follows:

• Mobile Client Application: The compiled application binary (APK/AAB for Android, IPA for iOS) residing on the end-user's device. This includes the bundled JavaScript code, assets, and native libraries.

• Local Secure Storage: The hardware-backed storage mechanisms (Android Keystore and iOS Keychain) utilized to persist secrets. This is considered the internal "secure zone" of the application.

• Input Vectors: The device camera (utilized for QR code scanning) and the touchscreen/keyboard (utilized for manual entry and PIN input).

• Output Vectors: The device screen (for displaying OTPs) and the system clipboard (for copying codes).

• Cloud Interface (Optional): The secure, encrypted channel used to synchronize backup archives to the user’s personal cloud storage (e.g., iCloud Drive, Google Drive).

External Dependencies: The system interacts with, but does not control, the Mobile Operating System (OS) and the Relying Parties that generate the initial QR codes. The security model assumes the Relying Parties generate cryptographically strong random seeds, but it does not assume the OS is free of malware, necessitating overlay protections and root detection mechanisms.¹¹

2.3 Asset Inventory and Classification

A granular understanding of the data assets processed by the system is essential for applying appropriate security controls. The assets are classified based on the potential impact of their compromise on confidentiality, integrity, and availability.

The protection of A-01 (Shared Secret Keys) is the overarching security objective. If these keys are exfiltrated, the integrity of the 2FA system is totally compromised, as the attacker can generate valid codes offline without further interaction with the victim's device.¹²

3. Security Architecture and Design Principles

The architectural philosophy of the SecureAuth program is grounded in the principle of Zero Trust. We assume that the network is hostile, the device may be compromised by malware, and the physical possession of the device by the user cannot be guaranteed at all times.

3.1 Defense-in-Depth Strategy

The system implements a multi-layered defense strategy, ensuring that the failure of a single control does not result in a catastrophic breach.

1. Layer 1: Platform Security: The application relies on the OS-level sandboxing (UID isolation on Android, App ID isolation on iOS) to prevent other applications from reading its data.

2. Layer 2: Application Hardening: The binary is obfuscated, and runtime integrity checks are performed to detect tampering or debugging attempts.

3. Layer 3: Data Encryption: All sensitive data at rest is encrypted using keys that are bound to the device's hardware security module (HSM/Secure Enclave). This ensures that even if the file system is dumped (e.g., via a root exploit), the data remains unintelligible without access to the hardware key.¹

4. Layer 4: Authentication: Access to the application's UI requires biometric authentication or a PIN, preventing unauthorized use by an attacker who has physical access to an unlocked device.

3.2 React Native Architecture and the Bridge

React Native operates by running a JavaScript thread that communicates with the main UI thread via a "Bridge." This architecture presents specific security nuances that must be addressed.

• The Bridge Bottleneck: In older React Native architectures, data passed over the bridge is serialized into JSON strings. If a large number of secrets were loaded from storage and passed to the JS thread for rendering, these secrets would exist in plaintext within the bridge's message queue, potentially vulnerable to memory scraping attacks.

• JSI and C++ TurboModules: To mitigate this, SecureAuth utilizes the modern JavaScript Interface (JSI). JSI allows the JavaScript engine to hold references to C++ Host Objects. This means the cryptographic keys can remain in the native memory space (C++), and the cryptographic operations (like HMAC-SHA1 calculation) can be invoked synchronously without serializing the key itself across the bridge. This significantly reduces the attack surface by minimizing the time sensitive data spends in the managed JavaScript heap, which is subject to garbage collection and harder to scrub.¹³

• Hermes Engine: The application utilizes the Hermes JavaScript engine. Hermes compiles JavaScript to bytecode at build time. While primarily a performance optimization, this provides a layer of obscurity, as the deployed artifact does not contain human-readable JavaScript source code, raising the bar for reverse engineering compared to standard JS bundles.¹⁴

3.3 Hardware-Backed Security Integration

The cornerstone of the architecture is the reliance on the device's Trusted Execution Environment (TEE).

• Android Keystore System: The application generates a symmetric AES-256 key inside the Android Keystore. This key is flagged as non-exportable. When data needs to be encrypted or decrypted, the data is sent into the Keystore/TEE, processed, and the result is returned. The key itself never exposes its material to the application memory. We utilize the StrongBox backing where available, which uses a dedicated security chip separate from the main SoC.¹

• iOS Keychain Services: Similarly, on iOS, the SecItemAdd and SecItemCopyMatching APIs are used to interface with the Keychain. Items are stored with the accessibility attribute kSecAttrAccessibleWhenUnlockedThisDeviceOnly. This attribute is critical: it ensures the data is encrypted with a class key that is effectively thrown away when the device is locked, and the ThisDeviceOnly flag prevents the items from migrating to a new device via iCloud Restore, preventing a "clone via backup" attack vector.¹⁰

4. Threat Modeling and Risk Assessment

A rigorous threat modeling exercise is essential to identify potential vulnerabilities before they can be exploited. This section applies the STRIDE methodology (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) to the SecureAuth system, with a specific focus on the React Native context.¹⁶

4.1 Threat Landscape Analysis

Mobile devices are hostile environments. The threats facing a 2FA app are distinct from web applications.

• Privileged Escalation (Root/Jailbreak): A significant percentage of users intentionally root their devices. However, malware can also exploit OS vulnerabilities (like "Dirty COW" or generic kernel exploits) to gain root privileges without user consent. A root-enabled process can bypass standard file permissions and read the private data directories of other apps.¹⁸

• Overlay Attacks (Cloaking): On Android, malicious apps can draw views on top of legitimate apps. An attacker could draw a fake "Login" screen over the Authenticator app to steal the backup password, or draw a transparent button over the "Delete Account" button to trick the user into data loss.¹

• Clipboard Hijacking: Users frequently copy OTPs to paste them into browser windows. Malware monitoring the clipboard can read these codes. While OTPs are transient, near-real-time theft allows an attacker to use the code before it expires.

4.2 STRIDE Analysis Matrix

Threat Type	Scenario	Impact	Mitigation Strategy
Spoofing	An attacker creates a look-alike app and publishes it to the App Store, tricking users into entering their secrets manually.	High	Brand monitoring, App Store policing, and implementing "App Links" / "Universal Links" verification.
Tampering	An attacker modifies the app binary on a jailbroken device to bypass biometric checks.	Critical	Implementation of Runtime Application Self-Protection (RASP) checks. Code signing verification at launch.
Repudiation	A user claims they did not authorize a backup that was subsequently leaked.	Low	Local immutable audit logging of critical actions (e.g., "Backup enabled at").
Info Disclosure	Vector A: Secrets stored in AsyncStorage are read by a file explorer.	Critical	A: Prohibit AsyncStorage for sensitive data. Use Keychain/Keystore.
DoS	A malicious QR code contains a 10MB payload, causing the parser to crash or hang the UI thread.	Medium	Strict input length validation on QR payloads. Exception handling in the parsing logic to prevent app crashes.
Elevation	An attacker exploits a vulnerability in a React Native dependency (e.g., CVE-2025-11953) to execute code on the developer's machine and inject malware into the build.	High	Secure Software Supply Chain controls. Dependency pinning, SCA scanning, and isolated build environments.20

4.3 Detailed Attack Vectors and Validations

4.3.1 The "AsyncStorage" Trap

One of the most common vulnerabilities in React Native apps is the misuse of AsyncStorage for sensitive data.

• The Mechanism: AsyncStorage is an unencrypted, persistent, key-value storage system that is global to the app. On iOS, it is implemented as a manifest file; on Android, it uses SQLite or XML files.

• The Vulnerability: These files are readable by anyone with physical access to an unlocked device (via USB debugging) or by any process with root access. Furthermore, these files are included in cleartext in standard device backups (iTunes, Google Drive Backup).

• Validation: To verify this vulnerability, a tester can simply run adb shell run-as com.secureauth.app cat /data/data/com.secureauth.app/files/AsyncStorage. If any secrets appear, the app fails the security audit immediately.

• Remediation: The SecureAuth architecture explicitly forbids the use of AsyncStorage for anything other than non-sensitive UI preferences (e.g., "Dark Mode: On"). All secrets are routed to react-native-keychain.¹⁰

4.3.2 The QR Code Poisoning

QR codes are essentially untrusted user input.

• The Threat: An attacker can generate a QR code that encodes a malicious URL (e.g., javascript:exploit()) or an excessively long string designed to trigger a buffer overflow in the underlying C++ image processing library.

• Analysis: The react-native-vision-camera library is used for scanning. It captures the frame and passes it to a barcode scanning processor.

• Mitigation: The application implements a "Sanitization Layer" immediately after scanning.

  1. Scheme Check: The URI must start with otpauth://.

  2. Type Check: The host must be totp or hotp.

  3. Parameter Validation: The secret parameter is validated against a Base32 regex. The period parameter must be a valid integer (defaulting to 30).

  4. No Execution: The scanner extracts the string as data only. It never passes the string to a WebView or eval() function, neutralizing XSS vectors.⁶

5. Security Controls: Data at Rest

Safeguarding data at rest is the primary defense against device loss and malware extraction. This section details the storage hierarchy and cryptographic implementation.

5.1 Storage Hierarchy Comparison

The following table contrasts the storage options considered during the architectural phase, justifying the selection of Native Keychain/Keystore.¹⁰

5.2 Android Keystore Implementation Details

On Android, the implementation uses the Android Keystore System.

• Key Generation: A 256-bit AES key is generated with the PURPOSE_ENCRYPT | PURPOSE_DECRYPT flag.

• User Authentication Requirement: The key is configured with setUserAuthenticationRequired(true). This means the key cannot be used unless the user has authenticated via biometric or device credential (PIN/Pattern) within the last x seconds. This binds the encryption key to the user's presence, not just the device's existence.

• Hardware Backing: We request setIsStrongBoxBacked(true). If the device has a dedicated Titan M or Secure Element chip, the key is generated and stored there. This provides resistance against side-channel attacks and cold boot attacks.¹

5.3 iOS Keychain Implementation Details

On iOS, the Keychain Services API is utilized.

• Item Class: Secrets are stored as kSecClassGenericPassword.

• Access Control: The kSecAttrAccessible attribute is set to kSecAttrAccessibleWhenUnlockedThisDeviceOnly.

  • WhenUnlocked: The data is decrypted only when the device is unlocked. The class key is evicted from memory when the device locks.

  • ThisDeviceOnly: The item is not migrated to new devices via iCloud Restore. This prevents an attacker who compromises the user's iCloud account from restoring the victim's backup to a generic iPhone and accessing the OTP seeds.

• Biometric integration: For high-security modes, kSecAccessControlBiometryAny is added, enforcing FaceID/TouchID interaction for every read operation.¹⁰

6. Security Controls: Data in Transit & Network Security

While OTP generation is an offline capability, the application has network interfaces for crash reporting, telemetry (if enabled), and cloud backups.

6.1 Transport Layer Security (TLS)

All network communication is strictly enforced over TLS 1.2 or TLS 1.3.

• Android Network Security Config: The application includes a network_security_config.xml file that explicitly forbids cleartext traffic (cleartextTrafficPermitted="false"). This prevents accidental HTTP connections and protects against passive eavesdropping on hostile networks (e.g., public Wi-Fi).

• App Transport Security (ATS): On iOS, ATS is enabled with strict requirements, disallowing exception domains or weakened cipher suites.²

6.2 SSL Pinning and MITM Mitigation

Mobile applications are susceptible to Man-in-the-Middle (MITM) attacks where an attacker installs a custom Root Certificate on the victim's device (common in corporate monitoring environments or malware attacks).

• The Risk: If a user installs a malicious root CA, the attacker can intercept TLS traffic, potentially stealing the OAuth tokens used for cloud backup authentication.

• The Control: SecureAuth implements Certificate Pinning (or Public Key Pinning). The application contains a hardcoded hash of the public key of the legitimate backend server's certificate. During the TLS handshake, the app verifies that the server's presented certificate matches this pinned hash. If it does not match (even if the certificate is validly signed by a trusted root CA), the connection is terminated immediately.

• Library: This is implemented using react-native-ssl-pinning or by configuring the network library (e.g., axios or fetch) with a custom TrustManager on Android and NSURLSessionDelegate on iOS.²

6.3 Minimizing Data Exposure

• Telemetry Scrubbing: The logging framework includes a regex-based scrubber. Before any log is written to disk or sent to a crash reporting service (like Sentry), patterns resembling TOTP seeds (Base32 strings) or Account Names (email addresses) are redacted.

• No "Phone Home" for Secrets: The architecture strictly prohibits sending shared secrets to any server controlled by the developer. Secrets only leave the device if the user explicitly enables "Cloud Backup," and even then, they are encrypted client-side first.

7. Input Validation and Interaction Security

7.1 Camera and QR Code Security

The camera is a high-privilege sensor.

• Permission Management: The app requests CAMERA permission only when the user taps "Scan QR Code." It does not request it at startup. This adheres to the principle of Least Privilege.

• Library Choice: The report advises using react-native-vision-camera due to its performance and active maintenance compared to the deprecated react-native-camera.

• Privacy Masks: The camera view is strictly an overlay. The app does not save captured images to the Camera Roll or Gallery. The frame data is processed in memory and discarded immediately after barcode extraction.²⁵

7.2 Biometric Authentication Architecture

Biometrics are used to unlock the app, but implementation matters.

• LocalAuth vs. CryptoObject: A common mistake is using LocalAuthentication.authenticate() merely as a boolean switch (i.e., "If face matches, show UI"). This is bypassable on jailbroken devices by hooking the function to return true.

• Secure Implementation: SecureAuth uses the biometric prompt to unlock a CryptoObject. The biometric sensor releases a hardware-protected key that is then used to decrypt the database. If the biometric check is bypassed via hooking, the key is never released, and the database remains encrypted. This binds the authentication to the cryptography.⁹

7.3 Clipboard Management

• Risk: Users copy codes to paste them. A malicious background app can read the clipboard.

• Control: When a user taps to copy, the app writes the code to the clipboard. It simultaneously starts a background timer (using setTimeout or a background task). After 30 seconds, the app automatically clears the clipboard or overwrites it with empty data. This reduces the exposure window.¹

7.4 Screen Security

• Task Switcher Protection: When an app is backgrounded, the OS takes a snapshot to display in the "Recent Apps" list. If an OTP is on screen, this snapshot persists it to the file system.

• Mitigation:

  • Android: The flag WindowManager.LayoutParams.FLAG_SECURE is set. This prevents the OS from taking screenshots and prevents screen recording apps from capturing the app content (the screen appears black).

  • iOS: The app listens for applicationWillResignActive events. Upon triggering, it renders a "Blur View" or a static logo screen over the main UI content, ensuring the system snapshot contains no sensitive data.¹⁹

8. Supply Chain Security and Developer Environment

The software supply chain is currently the most volatile attack surface for React Native applications.

8.1 The NPM Ecosystem Risk

React Native projects typically depend on hundreds of open-source packages.

• Case Study: CVE-2025-11953: A critical vulnerability was discovered in @react-native-community/cli. This flaw allowed unauthenticated remote attackers to execute arbitrary OS commands on the developer's machine by sending a malicious POST request to the local Metro bundler server.

• Implication: An attacker could exploit this to inject malicious code into the app bundle during the build process. The developer would unwittingly sign and publish a compromised app.

• Remediation:

  1. Immediate Patching: Ensure @react-native-community/cli is updated to version 20.0.0 or later.

  2. Network Isolation: The Metro bundler should never be exposed to the public internet. It should bind only to localhost or a secure, isolated Wi-Fi network.

  3. SCA Tools: Use tools like Snyk or npm audit in the CI/CD pipeline to block builds if high-severity vulnerabilities are detected in the dependency tree.²⁰

8.2 Build Pipeline Hardening

• Ephemeral Environments: Builds should not be produced on developer laptops for production release. They should be built in ephemeral CI environments (e.g., GitHub Actions, Bitrise) that are spun up, execute the build, and destroyed. This prevents persistent malware on a developer's machine from infecting the release.

• Signing Key Protection: The Android Keystore file (release.keystore) and iOS Distribution Certificate must not be stored in the Git repository. They should be injected into the CI environment via secure secret management systems (e.g., AWS Secrets Manager, GitHub Secrets) only at runtime.¹

8.3 Code Obfuscation

• JavaScript Obfuscation: React Native bundles are readable text. The app uses metro-minify-terser or specialized obfuscators (like Jscrambler) to rename variables, flatten control flow, and insert dummy code.

• Native Obfuscation: On Android, ProGuard/R8 rules are configured to shrink and obfuscate the Java/Kotlin code. This makes static analysis significantly more time-consuming for an attacker.¹⁹

9. Compliance and Privacy Framework (GDPR & NIST)

9.1 GDPR Compliance Strategy

The SecureAuth app processes "Account Metadata" (e.g., email addresses in labels), which puts it in scope for GDPR.

• Article 5 (Data Minimization): The app does not collect phone numbers, device IDs, or location data. It collects only the secret key and the label necessary for the user to identify the account.

• Article 6 (Lawful Basis): Processing is based on Contractual Necessity (the user installed the app to perform 2FA) and Legitimate Interest (security).

• Article 17 (Right to Erasure): The app includes a "Delete Account" swipe action and a global "Reset App" setting. These actions perform a cryptographic erase of the storage slots. Since no data is synced to a developer server, this satisfies the erasure requirement completely.

• Article 32 (Security of Processing): The implementation of hardware-backed encryption (Keystore/Keychain) and biometric access controls demonstrates compliance with the requirement for "appropriate technical and organizational measures".⁷

9.2 NIST 800-171 Control Mapping

For enterprise deployments involving CUI, the app supports the following controls:

NIST Control ID	Requirement	Implementation
3.1.1	Limit system access to authorized users.	Biometric authentication / PIN required to open app.
3.1.2	Limit system access to functions...	App functionality is restricted when locked.
3.1.18	Control connection of mobile devices.	App prevents USB debugging / ADB access via android:debuggable="false".
3.13.8	Implement cryptographic mechanisms to prevent unauthorized disclosure of CUI during transmission.	TLS 1.3 with Certificate Pinning for backup sync.
3.13.11	Employ FIPS-validated cryptography.	Android Keystore and iOS Secure Enclave use FIPS 140-2 Level 2 validated hardware modules.5

10. Disaster Recovery: The Secure Backup Protocol

The most significant friction point in 2FA is device loss. If the phone is lost, the user loses access to all accounts. SecureAuth implements a "Zero-Knowledge" cloud backup system.

10.1 The Architecture of Trust

Standard cloud backups (e.g., iCloud Backup) are convenient but allow the cloud provider (Apple/Google) to theoretically decrypt the data (since they hold the keys to the backup).

SecureAuth Protocol:

1. User Input: User sets a unique "Recovery Password" inside the app. This password never leaves the device.

2. Key Derivation (KDF): The app uses Argon2id (a memory-hard KDF) to derive a 256-bit AES encryption key from this password. A random 16-byte salt is generated and stored with the backup.

   • Why Argon2id? It is resistant to GPU/ASIC cracking attacks, unlike PBKDF2 or SHA-256.

3. Encryption: The database of secrets is serialized to JSON and encrypted using AES-256-GCM with the derived key.

4. Transport: The encrypted blob is uploaded to the user's private application folder in Google Drive or iCloud.

5. Recovery: To restore, the user downloads the blob. The app prompts for the Recovery Password. The app re-derives the key and attempts decryption.

6. Security Guarantee: Since the cloud provider never receives the Recovery Password, they cannot decrypt the user's 2FA seeds. The user retains sole sovereignty over their identity data.³³

11. Conclusion and Implementation Roadmap

11.1 Summary of Residual Risks

Despite robust controls, residual risks remain:

• OS Zero-Day Exploits: If the underlying Android/iOS kernel is compromised (e.g., by state-level actors using tools like Pegasus), the sandbox protections are nullified. This is an inherent risk of mobile computing.

• User Coercion: A user can be forced to unlock their device and app biometrically.

• Phishing of Recovery Password: If the user is tricked into entering their Recovery Password on a fake website, the attacker can download the backup from the cloud and decrypt it.

11.2 Implementation Checklist

To realize the security posture defined in this SSP, the development team must execute the following:

• Phase 1: Foundation

  • Configure react-native-keychain with biometric ACLs.

  • Disable android:allowBackup in Manifest.

  • Enable FLAG_SECURE on all Views.

• Phase 2: Hardening

  • Implement react-native-ssl-pinning.

  • Configure ProGuard rules for code obfuscation.

  • Integrate Snyk/npm audit into CI pipeline.

• Phase 3: Advanced

  • Implement JSI bindings for cryptographic operations to bypass the Bridge.

  • Develop the Argon2id Zero-Knowledge backup module.

  • Perform third-party penetration testing (VAPT).²⁹

This document confirms that the SecureAuth Mobile Authenticator, when implemented according to these specifications, meets the highest standards of mobile application security, balancing usability with the imperative need to protect digital identities. The shift from "convenient" storage (AsyncStorage) to "secure" storage (Keystore), combined with a zero-trust network policy and rigorous supply chain hygiene, creates a formidable defense against modern cyber threats.