Mobile App Passkey Architecture: Migrating from Passwords and SMS OTP to Android Credential Manager and Apple ASAuthorization

# Mobile App Passkey Architecture: Migrating from Passwords and SMS OTP to Android Credential Manager and Apple ASAuthorization

Summary: Modern mobile app passkey architecture replaces vulnerable SMS OTPs and static passwords with FIDO2/WebAuthn public-key cryptography. By binding cryptographic key pairs directly to hardware-backed keystores—Apple's Secure Enclave and Android's StrongBox—and synchronizing through end-to-end encrypted cloud keychains, engineering teams eliminate SIM-swap attacks and SMS toll fraud. This playbook provides end-to-end architectural blueprints, domain verification configs, native Swift and Kotlin implementations, cross-ecosystem recovery flows, and 2026 FinOps modeling.

---

The Impetus for Modern Mobile App Passkey Architecture

Mobile authentication architecture has reached an inflection point. For over two decades, product engineering teams treated passwords paired with Short Message Service (SMS) One-Time Passwords (OTPs) as the default compromise between security and user convenience. In enterprise SaaS, fintech, and high-volume mobile consumer platforms, that paradigm has turned into a critical security and financial liability.

Shared secrets are inherently vulnerable. Passwords suffer from credential stuffing, dictionary attacks, and server-side database exfiltration. Adding SMS OTP as a second factor was designed to mitigate credential theft, but telecom routing introduces severe attack vectors:

• Artificially Inflated Traffic (AIT) and SMS Toll Fraud: Botnets target mobile registration and password-reset endpoints, initiating surges of authentication attempts directed toward premium-rate telephony ranges controlled by colluding entities. Unmonitored SMS authentication endpoints risk severe financial exposure from toll fraud, where automated bots induce sudden traffic spikes that inflate telecommunications invoices.
• SIM Swapping and SS7 Interception: Mobile phone numbers were never engineered as cryptographic identity identifiers. Social engineering attacks against cellular carrier support personnel routinely allow attackers to redirect SMS traffic to rogue SIM cards, invalidating OTP defenses and causing unauthorized account takeovers.
• Conversion Friction and Delivery Latency: Telecom delivery is subject to transmission latency, aggregator queueing, and regional routing failures, introducing friction that directly increases funnel drop-off during user onboarding and transaction authorization.

Adopting a modern mobile app passkey architecture transitions systems to phishing-resistant fido2 mobile app authentication, replacing shared secrets with asymmetric public-key cryptography. Built on the W3C Web Authentication (WebAuthn Level 3) standard and FIDO2 specifications, passkeys generate and isolate private keys within hardware-backed security coprocessors on the user's device. The backend Relying Party (RP) server stores only the corresponding public key. Authentication succeeds through local biometric proof (Face ID, Touch ID, or Android BiometricPrompt) without transmitting secrets across the network.

---

Cryptographic Sequence and Protocol Ceremony

Passkey operations rest on two distinct cryptographic ceremonies: Registration (key creation) and Authentication (assertion verification). Both ceremonies execute between the mobile client application, the operating system's hardware-backed keystore subsystem, and the backend Relying Party server.

Hardware Keystore Isolation

Modern mobile operating systems isolate cryptographic primitives from user-space applications:

• Apple Secure Enclave Processor (SEP): A dedicated hardware coprocessor running an isolated microkernel. The SEP contains its own hardware random number generator (TRNG) and generates asymmetric P-256 (secp256r1) elliptic curve keys. The private key never enters application memory or application processor cache lines.
• Android StrongBox / Trusted Execution Environment (TEE): Android systems running hardware-isolated Keymaster or Keystore 2.0 execute cryptographic signing inside an isolated CPU enclave or discrete tamper-resistant hardware (StrongBox).

End-to-End Encrypted Cloud Keychains

While keys are generated locally, modern operating systems address device loss through multi-device synchronization. Apple syncs credentials via iCloud Keychain, protected by end-to-end encryption with escrow keys derived from user device passcodes. Android synchronizes credentials via Google Password Manager with hardware-derived passkeys backed by Google's cloud key vault.

The Cryptographic Registration and Authentication Ceremony

The following sequence details how public-key pairs are registered and authenticated between the native client, hardware keystore, cloud sync provider, and backend Relying Party server:

sequenceDiagram
    autonumber
    actor User
    participant App as Mobile App Client
    participant OS as Mobile OS Credential Manager
    participant HSM as Hardware Keystore Enclave and StrongBox
    participant Cloud as Cloud Sync Keychain
    participant RP as Relying Party Backend Server

    %% Registration Ceremony
    rect rgb(240, 248, 255)
    User->>App: Initiates Passkey Creation
    App->>RP: POST /api/v1/auth/passkey/register/options (Session Token)
    RP-->>App: 200 OK (Challenge, RP ID, User ID, ES256 Algorithm)
    App->>OS: Request Registration (CredentialManager / ASAuthorization)
    OS->>User: System Biometric Prompt (Face ID / BiometricPrompt)
    User-->>OS: Biometric Verification Approved
    OS->>HSM: Generate Asymmetric Key Pair (P-256 Elliptic Curve)
    HSM-->>OS: Private Key (Enclave-bound) + Raw Public Key
    OS->>Cloud: Encrypt & Sync Private Key via Cloud Keychain
    OS-->>App: Encoded Credential (AttestationObject, ClientDataJSON, CredentialID)
    App->>RP: POST /api/v1/auth/passkey/register/verify
    RP->>RP: 1. Verify Challenge Matches Session
    RP->>RP: 2. Validate Origin & SHA-256(RP ID)
    RP->>RP: 3. Parse Public Key (COSE) & Store CredentialID
    RP-->>App: 200 OK (Registration Complete)
    end

    %% Authentication Ceremony
    rect rgb(255, 250, 240)
    User->>App: Initiates Sign-In
    App->>RP: POST /api/v1/auth/passkey/authenticate/options
    RP-->>App: 200 OK (Cryptographic Challenge, Allowed Credential IDs)
    App->>OS: Request Assertion (CredentialManager / ASAuthorization)
    OS->>User: System Biometric Prompt
    User-->>OS: Biometric Verification Approved
    alt Key Bound to Local Hardware
        OS->>HSM: Sign Auth Data with Enclave Private Key
        HSM-->>OS: Return Assertion Signature
    else Synced Key from Cloud Keychain
        OS->>Cloud: Decrypt Synced Private Key & Sign Auth Data
        Cloud-->>OS: Return Assertion Signature
    end
    OS-->>App: Assertion (ClientDataJSON, AuthenticatorData, Signature, CredentialID)
    App->>RP: POST /api/v1/auth/passkey/authenticate/verify
    RP->>RP: 1. Lookup Stored Public Key by CredentialID
    RP->>RP: 2. Verify Challenge & Origin from ClientDataJSON
    RP->>RP: 3. Verify ECDSA Signature over AuthenticatorData + ClientDataHash
    RP->>RP: 4. Validate Sign Counter (Replay Protection)
    RP-->>App: 200 OK (Issue Access Token / Session JWT)
    App-->>User: Authenticated Dashboard
    end

Data Structures: Attestation vs. Assertion

1. ClientDataJSON: Contains the operation type (webauthn.create or webauthn.get), the cryptographically random base64url-encoded challenge issued by the server, and the verified origin URL.

2. AuthenticatorData: A binary structure containing the 32-byte SHA-256 hash of the Relying Party ID (rpIdHash), flag bytes indicating user presence (UP) and user verification (UV), a 4-byte monotonic sign counter for replay attack detection, and extension data.

3. Cryptographic Signature: Formatted as an ASN.1 DER-encoded sequence of two integers $(r, s)$ for ECDSA signatures, verifying that the private key signed the SHA-256 hash of clientDataJSON concatenated with authenticatorData.

---

Domain Verification Configuration Blueprints

The foundation of passkey anti-phishing security is domain binding. Unlike SMS OTPs or passwords that can be entered into spoofed web views or malicious third-party apps, the mobile operating system strictly validates the application's cryptographically signed identity against domain verification files hosted on the Relying Party server.

If an attacker compiles a malicious clone of your app, the mobile OS prevents it from reading, requesting, or creating credentials under your domain.

Android Digital Asset Links (assetlinks.json)

On Android, domain association is validated via Digital Asset Links. The file must be served over HTTPS at the exact path:

https://auth.example.com/.well-known/assetlinks.json

[
  {
    "relation": [
      "delegate_permission/common.handle_all_urls",
      "delegate_permission/common.get_login_creds"
    ],
    "target": {
      "namespace": "android_app",
      "package_name": "com.example.mobile",
      "sha256_cert_fingerprints": [
        "FA:C6:17:45:DC:09:03:78:6F:B9:ED:E6:2A:96:2B:39:9F:73:48:F0:BB:6F:89:9B:83:32:66:75:91:03:3B:9C"
      ]
    }
  }
]

[!IMPORTANT]

Production Signing Trap: The sha256_cert_fingerprints value must reflect the certificate that signs the APK or App Bundle delivered to end users. If your team uses Google Play App Signing, the production fingerprint is generated by Google's cloud key management, not your local upload keystore. You must extract the App Signing Certificate SHA-256 fingerprint directly from the Google Play Console under Release > Setup > App Integrity. Omitting this causes passkey creation to fail silently in production.

Apple App Site Association (apple-app-site-association)

On iOS, domain association relies on the Apple App Site Association (AASA) file. The file must be served at:

https://auth.example.com/.well-known/apple-app-site-association

{
  "webcredentials": {
    "apps": [
      "9ABC1234DE.com.example.mobile"
    ]
  }
}

The app identifier consists of your 10-character Apple Developer Team ID (9ABC1234DE) followed by the application Bundle Identifier (com.example.mobile).

Operational serving rules for AASA:

• The URL must respond with an HTTP 200 OK status without any HTTP redirects (301/302 redirects cause validation to fail).
• The Content-Type header must be application/json.
• The file must not include a .json file extension in the URL path.
• In Xcode, navigate to your target's Signing & Capabilities, add the Associated Domains capability, and declare the entry with the webcredentials prefix: webcredentials:auth.example.com.

---

Native Implementation Playbook: Android & iOS

Engineering teams must build on platform-native APIs rather than deprecated web-view wrappers or outdated legacy SDKs. Google consolidates credential handling into androidx.credentials.CredentialManager, while Apple handles authentication via the AuthenticationServices framework.

Android Implementation with CredentialManager

Implementing an android credential manager passkey workflow requires building on androidx.credentials.CredentialManager rather than deprecated Google Play Services FIDO2 APIs. Add the following dependencies to app/build.gradle.kts:

dependencies {
    implementation("androidx.credentials:credentials:1.3.0")
    implementation("androidx.credentials:credentials-play-services-auth:1.3.0")
}

The following production-ready class handles both registration and assertion ceremonies:

package com.example.mobile.auth

import android.content.Context
import androidx.credentials.CreatePublicKeyCredentialRequest
import androidx.credentials.CreatePublicKeyCredentialResponse
import androidx.credentials.CredentialManager
import androidx.credentials.GetCredentialRequest
import androidx.credentials.GetPublicKeyCredentialOption
import androidx.credentials.PublicKeyCredential
import androidx.credentials.exceptions.CreateCredentialCancellationException
import androidx.credentials.exceptions.CreateCredentialException
import androidx.credentials.exceptions.GetCredentialCancellationException
import androidx.credentials.exceptions.GetCredentialException
import kotlinx.coroutines.Dispatchers
import kotlinx.coroutines.withContext

class PasskeyAuthManager(private val context: Context) {

    private val credentialManager = CredentialManager.create(context)

    /**
     * Executes the WebAuthn public-key registration ceremony.
     */
    suspend fun registerPasskey(creationOptionsJson: String): Result<String> = withContext(Dispatchers.IO) {
        try {
            val request = CreatePublicKeyCredentialRequest(creationOptionsJson)
            val response = credentialManager.createCredential(context, request) as CreatePublicKeyCredentialResponse
            Result.success(response.registrationResponseJson)
        } catch (e: CreateCredentialCancellationException) {
            Result.failure(AuthException.UserCancelled("Passkey creation cancelled by user", e))
        } catch (e: CreateCredentialException) {
            Result.failure(AuthException.PlatformError("CredentialManager creation failed: ${e.type}", e))
        } catch (e: Exception) {
            Result.failure(AuthException.Unknown("Unexpected error during passkey creation", e))
        }
    }

    /**
     * Executes the WebAuthn assertion ceremony for authentication.
     */
    suspend fun authenticatePasskey(requestOptionsJson: String): Result<String> = withContext(Dispatchers.IO) {
        try {
            val getCredentialOption = GetPublicKeyCredentialOption(requestOptionsJson)
            val getRequest = GetCredentialRequest(listOf(getCredentialOption))
            val result = credentialManager.getCredential(context, getRequest)

            when (val credential = result.credential) {
                is PublicKeyCredential -> Result.success(credential.authenticationResponseJson)
                else -> Result.failure(AuthException.Unknown("Unrecognized credential type returned"))
            }
        } catch (e: GetCredentialCancellationException) {
            Result.failure(AuthException.UserCancelled("Passkey sign-in cancelled by user", e))
        } catch (e: GetCredentialException) {
            Result.failure(AuthException.PlatformError("CredentialManager assertion failed: ${e.type}", e))
        } catch (e: Exception) {
            Result.failure(AuthException.Unknown("Unexpected error during passkey sign-in", e))
        }
    }
}

sealed class AuthException(message: String, cause: Throwable? = null) : Exception(message, cause) {
    class UserCancelled(message: String, cause: Throwable? = null) : AuthException(message, cause)
    class PlatformError(message: String, cause: Throwable? = null) : AuthException(message, cause)
    class Unknown(message: String, cause: Throwable? = null) : AuthException(message, cause)
}

iOS Implementation with ASAuthorization

To implement an asauthorization passkey swift pipeline, iOS applications coordinate via the AuthenticationServices framework. The following service manages platform credential requests:

import Foundation
import AuthenticationServices

@MainActor
final class PasskeyAuthService: NSObject {
    
    private var continuation: CheckedContinuation<PasskeyAssertionResult, Error>?
    private var registrationContinuation: CheckedContinuation<PasskeyRegistrationResult, Error>?
    private unowned let presentationAnchor: ASPresentationAnchor
    
    init(presentationAnchor: ASPresentationAnchor) {
        self.presentationAnchor = presentationAnchor
        super.init()
    }
    
    func register(challenge: Data, userName: String, userID: Data, rpID: String) async throws -> PasskeyRegistrationResult {
        let provider = ASAuthorizationPlatformPublicKeyCredentialProvider(relyingPartyIdentifier: rpID)
        let request = provider.createCredentialRegistrationRequest(challenge: challenge, name: userName, userID: userID)
        
        let controller = ASAuthorizationController(authorizationRequests: [request])
        controller.delegate = self
        controller.presentationContextProvider = self
        
        return try await withCheckedThrowingContinuation { continuation in
            self.registrationContinuation = continuation
            controller.performRequests()
        }
    }
    
    func authenticate(challenge: Data, rpID: String) async throws -> PasskeyAssertionResult {
        let provider = ASAuthorizationPlatformPublicKeyCredentialProvider(relyingPartyIdentifier: rpID)
        let request = provider.createCredentialAssertionRequest(challenge: challenge)
        
        let controller = ASAuthorizationController(authorizationRequests: [request])
        controller.delegate = self
        controller.presentationContextProvider = self
        
        return try await withCheckedThrowingContinuation { continuation in
            self.continuation = continuation
            controller.performRequests()
        }
    }
}

extension PasskeyAuthService: ASAuthorizationControllerDelegate {
    nonisolated func authorizationController(controller: ASAuthorizationController, didCompleteWithAuthorization authorization: ASAuthorization) {
        Task { @MainActor in
            if let credential = authorization.credential as? ASAuthorizationPlatformPublicKeyCredentialRegistration {
                guard let attestation = credential.rawAttestationObject, let clientData = credential.rawClientDataJSON else {
                    registrationContinuation?.resume(throwing: PasskeyError.invalidPayload)
                    return
                }
                registrationContinuation?.resume(returning: PasskeyRegistrationResult(credentialID: credential.credentialID, attestationObject: attestation, clientDataJSON: clientData))
            } else if let credential = authorization.credential as? ASAuthorizationPlatformPublicKeyCredentialAssertion {
                guard let sig = credential.signature, let authData = credential.rawAuthenticatorData, let clientData = credential.rawClientDataJSON else {
                    continuation?.resume(throwing: PasskeyError.invalidPayload)
                    return
                }
                continuation?.resume(returning: PasskeyAssertionResult(credentialID: credential.credentialID, signature: sig, authenticatorData: authData, clientDataJSON: clientData))
            }
        }
    }
    
    nonisolated func authorizationController(controller: ASAuthorizationController, didCompleteWithError error: Error) {
        Task { @MainActor in
            registrationContinuation?.resume(throwing: error)
            continuation?.resume(throwing: error)
        }
    }
}

extension PasskeyAuthService: ASAuthorizationControllerPresentationContextProviding {
    nonisolated func presentationAnchor(for controller: ASAuthorizationController) -> ASPresentationAnchor {
        presentationAnchor
    }
}

struct PasskeyRegistrationResult {
    let credentialID: Data
    let attestationObject: Data
    let clientDataJSON: Data
}

struct PasskeyAssertionResult {
    let credentialID: Data
    let signature: Data
    let authenticatorData: Data
    let clientDataJSON: Data
}

enum PasskeyError: Error {
    case invalidPayload
}

Cross-Platform Architecture: React Native, Flutter, and Offline Sync

For teams developing cross-platform applications:

• React Native: Avoid fragile custom native bridges. Adopt audited packages such as @react-native-passkeys/core or react-native-credential-manager. These libraries wrap androidx.credentials and AuthenticationServices while passing raw WebAuthn JSON payloads straight through JavaScript threads.
• Flutter: Integrate the official passkeys or fido2 Dart plugins. Ensure platform channel serializers pass Base64URL-encoded strings directly to avoid byte-endianness corruption across memory boundaries.

Offline Operation and Push Notification Queues

Passkey authentication requires an active cryptographic challenge generated by the Relying Party server to guarantee replay protection. The challenge verification step cannot execute offline. However, mobile architects must address several operational edge cases:

1. Transient Offline Access: Applications requiring offline functionality should store authenticated session tokens (such as scoped OAuth 2.0 refresh tokens) within hardware-backed encrypted storage—EncryptedSharedPreferences backed by Android KeyStore, or iOS Keychain Services with kSecAccessControlBiometryAny access control. The passkey ceremony executes only during initial enrollment, periodic session re-authorization, or high-risk step-up events.

2. Push Notification Verification Queues: When users log in on desktop browsers, passkeys allow triggering out-of-band mobile prompts. The Relying Party dispatches a background silent push notification (via Apple Push Notification service or Firebase Cloud Messaging) to the registered mobile device. The client wakes up, queues the authorization request in an encrypted local queue, displays a local biometric prompt, signs the server challenge, and transmits the assertion back through a dedicated /api/v1/auth/passkey/push-verify endpoint.

---

Cross-Ecosystem Account Recovery & Device Switch Architecture

The primary architectural consideration in mobile passkey implementation is cross-ecosystem device migration. Within a single ecosystem, passkeys synchronize across devices: an iPhone user adding an iPad finds credentials pre-synced through iCloud Keychain. Similarly, an Android user moving across devices experiences automatic synchronization through Google Password Manager.

However, when a user switches from iOS to Android, or accesses an account from a corporate Windows workstation, cloud keychains do not communicate directly. Relying on an insecure fallback—such as sending an SMS OTP during device switches—re-exposes the system to SIM-swap vulnerabilities that passkeys are designed to prevent.

Tier 1: FIDO Hybrid Cross-Device Authentication (caBLE)

The FIDO Alliance specifies the Hybrid transport protocol (Client to Authenticator Protocol over Bluetooth Low Energy, or caBLE). If a user accesses your app on an Android tablet while holding an iPhone:

• The secondary device presents a dynamically generated WebAuthn QR code.
• The user scans the QR code with their iPhone camera.
• The devices establish a local, encrypted connection over Bluetooth Low Energy (BLE).
• The Bluetooth proximity check cryptographically proves both devices are co-located, mitigating remote phishing vectors. The private key remains within the iPhone hardware enclave; the assertion signature is transmitted directly over BLE to authorize the secondary device.

Tier 2: FIDO2 Hardware Security Keys

Power users and corporate enterprise clients should be prompted to register an external hardware token (such as a YubiKey or Titan Security Key) via NFC or USB-C. This independent hardware key provides an instant, ecosystem-agnostic fallback during complete device transitions.

Tier 3: Client-Side Asymmetric Recovery Tokens

During initial passkey enrollment, the mobile application generates a client-side recovery bundle. The backend generates a high-entropy 256-bit recovery token, hashes it using Argon2id, and stores the hash server-side. The user stores the raw token in an offline password vault or secure backup. Submitting this token allows enrolling a new device without telecom dependencies.

Tier 4: Identity-Verified Magic Links and Velocity Throttling

If a user loses all hardware tokens and switches ecosystems:

• Issue a cryptographic magic link to the user's verified, domain-authenticated email address.
• When clicked on the new mobile device, the application binds the request to the new hardware enclave before granting access.
• Velocity Throttling: If an account recovery request originates from an unrecognized device or IP subnet, the platform enforces a mandatory 24-hour hold on high-value transactions and dispatches push notifications and emails to all previously authenticated devices, providing legitimate users time to abort unauthorized takeover attempts.

For organizations seeking to design zero-trust mobile authentication pipelines without sacrificing product velocity, partnering with experienced mobile development services ensures cryptographic ceremonies, native OS bridges, and cross-platform key flows are implemented according to industry-standard secure architecture principles.

---

2026 FinOps & Security Risk ROI Analysis

Transitioning from SMS OTP to native passkeys delivers substantial operational efficiency alongside cryptographic security. In 2026, verification infrastructure costs represent a major variable operational expenditure (OpEx) for scaling mobile platforms.

Telephony Cost Breakdown: SMS Delivery vs. Passkeys

SMS verification involves compounding infrastructure expenses:

• Domestic SMS Base Costs: Enterprise SMS delivery operates on recurring per-message or per-segment carrier fees, which accumulate on every login attempt, step-up verification, and password reset.
• International Routing & Carrier Surcharges: Cross-border authentication and regional carrier surcharges significantly amplify per-message transmission costs, creating volatile unit economics as a mobile product expands globally.
• Toll Fraud (AIT) Exposure: Exposed verification endpoints remain vulnerable to Artificially Inflated Traffic, in which automated bot scripts generate high-frequency OTP dispatches to premium-rate ranges, creating immediate, unbudgeted billing spikes.
• Passkey Operational Cost: $0.00 in per-transaction carrier messaging fees. Passkey registration and assertion requests execute directly over existing standard HTTPS API endpoints, incurring only standard application server signature verification processing.

Comprehensive Authentication ROI Comparison

Illustrative 12-Month FinOps Scenario: 500,000 MAU Scale

To evaluate the operational expenditure (OpEx) divergence between carrier-dependent verification and public-key cryptography, consider an illustrative baseline model for a scaling mobile application supporting 500,000 Monthly Active Users (MAU) with an average of 3 authentication or step-up verification events per user monthly (1,500,000 events/month):

• Carrier-Dependent SMS Verification Model (Illustrative Baseline):

- Volume: 1,500,000 monthly verification events.

- Telephony Expense: Assuming an illustrative blended messaging tariff of $0.03 to $0.05 per SMS dispatch across mixed domestic and international routing, monthly telephony costs total $45,000 to $75,000 / month ($540,000 to $900,000 / year).

- Fraud Liability: Additional unbudgeted financial exposure from toll fraud during automated bot attacks on exposed endpoints.

• Native Mobile Passkey Infrastructure:

- Volume: 1,500,000 monthly verification events.

- Per-authentication carrier messaging fees: $0.00.

- Compute Profile: Standard ECDSA P-256 signature verification requires minimal CPU cycles on existing application server fleets or serverless workers, adding negligible incremental compute overhead.

• Operational Takeaway:

Transitioning authentication from carrier networks to hardware-backed asymmetric cryptography converts a recurring, volume-variable telecom cost into standard compute, while simultaneously removing delivery latency and SMS drop-off points from onboarding and checkout funnels.

---

Frequently Asked Questions

How does passkey architecture protect biometric privacy, and does the relying party backend receive biometric data?

Under the W3C WebAuthn and FIDO2 specifications, user biometric verification is isolated entirely on the client device. Operating system subsystems and hardware security coprocessors (such as Apple's Secure Enclave or Android's StrongBox/TEE) treat biometric scans (Face ID, Touch ID, or Android BiometricPrompt) strictly as a local authorization mechanism to release the private signing key. The backend Relying Party server receives only the resulting ECDSA cryptographic signature, the authenticator data flags, and client metadata—never raw biometric templates or sensor readings.

What happens to passkeys if a user's mobile device is rooted or jailbroken?

On rooted or jailbroken devices, kernel-level protections may be bypassed, but hardware-backed security coprocessors maintain cryptographic isolation. Private keys generated within the Apple Secure Enclave or Android StrongBox cannot be extracted in plaintext, even with root privileges, because the memory space of the security coprocessor is physically separated from the main application processor. However, an attacker with root access could potentially hook runtime APIs to request assertions if the device passcode is compromised. To mitigate this, enterprise apps should combine passkeys with hardware-attested integrity checks, such as Google Play Integrity API and Apple DeviceCheck.

Can a single mobile application share passkeys across multiple domain names or microservice Relying Parties?

By default, the WebAuthn specification enforces strict domain isolation: a passkey generated for auth.example.com is cryptographically tied to that exact Relying Party Identifier (rpId: "example.com"). An app cannot use a credential created for example.com to sign an assertion for partner.com. However, if your mobile application communicates with multiple subdomains (such as api.example.com, billing.example.com, and auth.example.com), you can set the rpId to the parent registrable domain (example.com). All associated subdomains sharing the parent domain can authenticate using the same passkey. For cross-domain federated identity, use OpenID Connect (OIDC) or OAuth 2.0 flows on top of a centralized passkey-authenticated identity provider.

What is the recommended fallback strategy when a user switches between iOS and Android without an existing secondary device?

When a user switches mobile platforms without an existing device available for FIDO Hybrid QR scanning, the recommended path is a multi-step recovery flow. First, verify the user's identity through a domain-authenticated email magic link combined with a secondary verification factor (such as an offline asymmetric recovery code generated during initial enrollment, or a hardware FIDO2 security key). Second, once the identity challenge is satisfied, enroll a new passkey into the new platform's native keychain (such as Google Password Manager on Android). Finally, trigger an automatic 24-hour rate limit on high-risk actions and dispatch real-time alerts to all registered email addresses and push endpoints to prevent account takeover attempts.

---

Sources

• W3C Web Authentication (WebAuthn) Level 3 Specification
• FIDO Alliance: Passkey Implementation and Design Guidelines
• Android Developers: Credential Manager API Reference
• Android Developers: Verify Digital Asset Links
• Apple Developer Documentation: Supporting Associated Domains and Passkeys
• NIST Special Publication 800-63B: Digital Identity Guidelines
• OWASP Mobile Application Security Verification Standard (MASVS)