Native Apps: Passkeys vs. Local Biometrics

1. Introduction#

After biometrics on mobile phones became mainstream, many native apps started using features like Face ID or Touch ID (or the Android equivalent) to protect app access. A face scan or a thumb on the sensor replaces the PIN the user would otherwise type on every launch. Both passkeys and local biometrics verify the user, so they look like the same tool, but they solve different problems. This article covers:

• Passkeys vs. Local Biometrics: How local biometrics and passkeys differ in their roles and functionality?
• Add Passkeys to Apps with Local Biometrics: Does it make sense to add passkeys to apps that already use biometrics? What are the benefits?
• Banks & Regulation: Why are local biometrics especially important for banks and sensitive apps in regulated environments?

1.1 Explaining the Difference to non-technical Stakeholders#

Even people who work in identity mix the two up, and the reason is the gesture: the user puts a finger on the sensor and gets in, in both cases. So the assumption is that both are the same thing. That assumption is usually why an internal champion cannot get a passkey project approved. If the app already asks for a fingerprint, the decision maker does not see a problem left to solve.

The one sentence to repeat in the meeting:

With local biometrics nothing leaves the device, so the server learns nothing and cannot trust anything. With a passkey there is a key pair: the private key stays on the device, the server holds the public key and checks a signature bound to your domain. A look-alike site cannot produce that signature, which is where the phishing resistance comes from.

Two details to have ready. First, biometric enforcement runs in opposite directions. A native app can require the biometric itself for its local unlock, while a passkey leaves that choice to the platform, so a device PIN satisfies user verification just as well. Second, using the login on the user's other devices is a separate property, which comes from a synced credential or from scanning a QR code with the phone that holds the passkey.

Two questions that always come back. The first one is "we already have Face ID in our app, so we are done": the app biometric decides whether to unlock a session that already exists, it says nothing about who created that session, so the credential behind it, usually a password or an OTP, is still the thing an attacker goes after. The second one is "so the biometric data goes to your servers?": no, the biometric never leaves the device in either model. With a passkey it unlocks the private key locally and only the signature leaves the device, and with a local unlock nothing leaves it at all.

If you need the longer version for the same audience, passkeys explained clearly walks through the mechanism without assuming a security background.

2. How do local Biometrics protect Apps?#

Local biometric authentication methods, such as Apple's Face ID, Touch ID or Android's biometrics capabilities, use unique physical traits (e.g. facial features or fingerprints) to verify a user's identity. Unlike traditional PINs or passwords, which rely on something the user knows, biometrics rely on something inherent to the user. The user stops typing a code on every launch.

2.1 History of App Security: From PINs and Passwords to Biometrics#

Before biometrics gained mainstream traction on mobile phones, apps that protected sensitive content often asked users to enter an additional PIN or password on every launch. That was more secure and more annoying, especially for a user who had already authenticated at the start of the session. Device-based facial recognition and fingerprint scanning replaced the code with a scan or a touch. If the biometric check fails, or the user never enabled it, the fallback PIN, passcode or password is still there.

2.2 Local Verification vs. Remote Authentication#

Local biometric checks and full remote authentication are two different events. Remote authentication happens at the start of a new session and verifies the user's identity against the service's backend systems using credentials like passwords or passkeys. This step establishes trust between the user and the service.

Local biometrics, in contrast, focus on re-verifying identity during an ongoing, authenticated session. Rather than asking the user to re-enter passwords or other credentials when they briefly leave the app or lock their phone, local biometrics confirm that the same authorized user is still in control of the device. This device-centric verification never contacts a remote server, so it also works offline.

2.3 Hardware Security Modules and Non-Transferability#

Biometric data is stored and processed securely within dedicated hardware security modules - like the Secure Enclave on iOS or the Trusted Execution Environment (TEE) on Android. These trusted modules are designed to keep sensitive biometric data safe from tampering, extraction or transfer.

Because of this hardware-level anchoring, biometric verification cannot be shared across devices or services. Each device's biometric templates stay unique to that unit, so a user who upgrades to a new phone has to re-enroll from scratch. That costs one onboarding step when switching devices, and it rules out remote attacks that exploit centrally stored biometric data.

2.4 Summary: Local Biometrics#

Local biometrics verify that the person currently holding the device is the rightful, already authenticated user, without a repeated PIN or password entry, which matters for apps that hold banking, insurance or other personal details.

They run instantly on-device, work offline, and keep biometric data inside secure hardware enclaves. They cannot replace the initial remote authentication (a passkey or a password) that establishes who the user is, but they are very good at protecting every session after that.

Their limits, no portability and re-enrollment on every new device, are the price for that device-level security.

3. How do Passkeys protect Apps?#

Passkeys replace shared secrets like passwords with asymmetric cryptographic credentials. Local biometrics only re-verify a user who is already authenticated on the device, while a passkey identifies the user to a remote service, which makes the login phishing-resistant even when the user and the device are unknown to the application's backend.

3.1 From Passwords to Passkeys: Leap in Security#

Before passkeys, trust with a remote service was established with passwords, shared secrets known to both the user and the server. Passwords are simple to implement and vulnerable to phishing, credential stuffing and reuse.

Passkeys address these challenges by using a pair of cryptographic keys: a private key securely stored on the user's device and a corresponding public key registered with the service. When a login attempt occurs, the service sends a challenge that can only be solved by the user's private key. Attackers who intercept the data, or who trick the user into handing over credentials, still cannot get in.

3.2 Public-Key Cryptography and Phishing-Resistance#

Passkeys employ asymmetric cryptography:

• Private Key (Client-Side): Stored safely within the device's secure enclave, inaccessible to other apps or even the operating system itself.
• Public Key (Server-Side): Registered with the application's backend, but useless on its own without the private key. The user never sends the private key over the network and never has a "shared secret" to type, so phishing attempts fail. Attackers cannot trick users into typing something they do not know, and an intercepted public key is worthless. Standards like FIDO2 and WebAuthn keep the whole flow on cryptographic operations instead of user-entered credentials.

That matters most for services that run a website next to the native app, because the website is where phishing hits. A passkey created on a mobile device can also be used on a desktop website via Cross-Device-Authentication.

3.3 Cross-Device Portability and Cloud Synchronization#

Passkeys travel across a user's devices. Modern operating systems synchronize them via secure cloud storage (e.g. iCloud Keychain, Google Password Manager), so users can log in from a second device without registering again, including the first install of the app. A passkey is also strong, phishing-resistant multi-factor authentication on its own, which removes the second factor the user would otherwise have to type.

3.4 Summary: Passkeys#

Passkeys authenticate unknown users to remote services and resist phishing. Asymmetric cryptography and device-resident private keys remove the weaknesses of password-based systems, and the keys sync across devices while staying inside the hardware security module. That is what establishes user identity in the first place, which local biometrics alone cannot do. In a native app, the passkey creates the secure session and local biometrics keep access to it quick afterwards.

4. Detailed Analysis: Passkeys & Local Biometrics#

In native apps, passkeys and local biometrics both improve security and user experience, but they solve different problems:

• Passkeys authenticate unknown users to a remote service, often during the first login or when creating a new session.
• Local biometrics, such as Face ID or Touch ID, re-verify an already authenticated user locally, which keeps an ongoing session going.

4.1 Passkeys vs. Local Biometrics: Detailed Comparison#

The table below compares both across purpose, use case, security and portability.

At a glance: choosing an approach

Key Insights:

• Local biometrics work offline, verify the device holder, but cannot authenticate to remote services
• Passkeys establish trust with servers, work across devices, but on web cannot enforce biometric-only verification
• Combined approach recommended for regulated environments: passkeys for login, local biometrics for ongoing access

4.2 How Passkeys and Local Biometrics complement each other#

Passkeys and local biometrics are complementary. Together they provide a layered authentication experience:

1. Passkeys for Initial Authentication, Re-Login and MFA
   Passkeys establish trust between a user and a remote service. Asymmetric cryptography makes that authentication phishing-resistant across platforms and devices, so intercepted data gets an attacker nowhere. Cloud sync (e.g. iCloud Keychain or Google Password Manager) carries the credential to the user's other devices, which covers first-time sign-ins, re-installs and multi-factor authentication (MFA). The same passkey works in the mobile app and on the website, and for apps that need more than one factor it replaces the traditional second factor.
2. Local Biometrics for ongoing Verification: Once authenticated, local biometrics give quick access back to the app by verifying that the same authorized user is operating the device. Unlike passkeys, local biometric checks are device-centric and offline, and they store and process the data in secure hardware enclaves, so nothing sensitive leaves the device. Users stop re-entering credentials, which matters most in apps that hold banking or healthcare data.

Combining both gives developers a secure and user-friendly authentication flow.

4.3 What you get from combining both#

Combining passkeys and local biometrics gives you a flow that:

• Improves Security: Passkeys protect against phishing, credential stuffing and password theft, while local biometrics prevent unauthorized access to authenticated sessions.
• Enhances User Experience: Local biometrics eliminate the need to repeatedly enter passwords or passkeys after the initial authentication. In case a re-authentication is needed because of timeouts or sign-outs reauthentication is as easy as unlocking the app.
• Simplifies Multi-Device Access: Passkeys enable cross-platform authentication, while local biometrics provide convenient device-level security. If passkeys are used on the web, adding them to the native app is an important additional step to close the gap and offer a full-service passkey experience for the user.

5. Passkey Adoption Strategies for Native Apps#

5.1 Targeting a large, logged-in User Base#

Adding passkey functionality to a native app is technically straightforward. Adoption is the hard part, especially in apps with a large, established user base, because those users unlock the app with local biometrics and almost never do a full remote login. The best passkey creation moment on the web, the post-sign-in nudge, barely exists here. The alternative moments below work without breaking the biometric unlock users are used to.

As detailed in Corbado's guide to passkey creation best practices, a rollout succeeds or fails on the moments you pick to nudge users. Here is the playbook for native apps, with each trigger and what it typically converts at.

All of this needs detailed telemetry. Track how, when and where users are prompted, otherwise prompt fatigue sets in and the nudges start interfering with the biometric unlock. Log every step of the creation funnel (prompt shown, clicked, started, completed or failed), because that is the only way to tune the rollout without annoying users.

5.2 Onboarding Users to Passkeys#

New users installing the app, and existing users logging in with a password, both arrive without a passkey. Onboarding is the one moment where you can put the strongest method first.

The recommended approach is:

1. Create Passkey First: Whether a user is signing up for the first time or logging in with a password, they should immediately be prompted to create a passkey. For new sign-ups, this creates a phishing-resistant credential from day one. Modern platform features, like Apple's Passkey Account Creation API, can even create the account and the passkey in a single step using a native UI, completely bypassing traditional sign-up forms. For existing users, this prompt serves as the moment they leave passwords behind.
2. Add Local Biometrics Second: Once the passkey is created and the account is secured, if the app handles sensitive data or has features that would benefit from session protection (as outlined in our recommendations), the app should then prompt the user to enable local biometrics (e.g. Face ID/Touch ID) to protect the logged-in app content.

This order secures the account for remote authentication first and the local session second.

6. Case Studies and real-world Examples#

Two implementations show how this plays out in production: one with passkeys only, one that combines both.

6.1 Integrating Passkeys for Authentication: Kayak#

The Kayak app uses passkeys for user authentication. They sit directly in the login screen, so users can pick a passkey without remembering an email address or a password.

Once authenticated via a passkey, the user gains unrestricted access to the app without requiring reauthentication. This design is particularly suitable for Kayak, a travel app that primarily manages booking history and itineraries, which are not considered highly sensitive or critical data.

Key Highlights of Kayak's Approach:

• Passkey Login on Authentication Screen: The app immediately offers passkey login, reducing steps and enhancing user convenience.
• No Local Biometric Protection Post-Login: Given that the app doesn't handle sensitive personal data, Kayak has chosen not to implement local biometric protections, like Face ID or fingerprint lock, for the logged-in state. This decision matches the app's data security needs and keeps the app quick to open.

Apps where users perform more sensitive actions need the extra layer. GitHub uses both.

6.2 Using Biometrics for protecting App Content: GitHub#

GitHub combines passkeys for the login with local biometrics for the logged-in state. The passkey is the fast, phishing-resistant option, which matters because GitHub requires multi-factor authentication, and it takes passwords and one-time passcodes out of the flow. But for the sake of this article we will not look at their passkey implementation.

GitHub's Additional Layer of Security with Local Biometrics:
Because GitHub also offers sensitive operations like merging pull requests, GitHub allows users to enable local biometric protection if they feel it is necessary. In this example, Face ID is used to lock the app on iOS, so only the device owner can open the GitHub App. The app explicitly requests the necessary privileges from the operating system to activate biometrics and offers configurable intervals (e.g. immediate or after a defined timeout).

Key Highlights of GitHub's Approach:

• Passkey Login for MFA Compliance: GitHub uses passkeys for fast logins that still meet its multi-factor authentication standards.
• Biometric Lock for App Protection: With Face ID on the logged-in app, a stolen or borrowed unlocked phone still does not get someone into the GitHub session.

7. Banks & Regulation: Why Local Biometrics matter for sensitive Apps#

Regulated industries have one more thing to sort out. In banking and financial services, the difference between passkey authentication and local biometric verification decides how a compliance review goes. What matters there is how passkeys validate user presence and identity, and how that maps to PSD2 (Payment Services Directive 2) in Europe or a comparable framework elsewhere.

7.1 How Passkeys validate Presence and Identity#

Passkeys validate two things during authentication:

1. User Presence: They confirm that someone is physically at the device when authentication occurs.
2. User Verification: They verify the person's identity through either:
   • Biometrics (what the user is): Face ID, Touch ID, fingerprint, etc.
   • Knowledge factor (what the user knows): Device password, passcode, or PIN.

This applies to web and native implementations alike, and it is the part compliance reviews get stuck on: a passkey accepts either biometric verification or a device passcode as a valid factor, by design.

At a glance: biometric enforcement by platform

Key Technical Distinctions:

• Local biometrics (native apps): Apps directly control biometric requirements for app access and local operations via platform APIs
• Passkeys: Use hardware security modules (Secure Enclave/TEE) for private key protection, but relying parties cannot dictate whether user verification uses biometrics vs. device PIN/password
• Web limitation: Browsers control user verification modality; web apps can require userVerification but cannot enforce biometric-only
• Biometric data: Never leaves the device; stored and processed in Secure Enclave (iOS) or TEE (Android)

7.2 The Privacy and Security Gap: Why local Biometrics matter#

While accepting a device passcode isn't a security vulnerability in authentication terms, it creates privacy and access control concerns, especially for regulated applications:

• Shared Access Risk: A friend, spouse, or family member who knows the device passcode could access sensitive banking or financial apps, even though they shouldn't have that permission.
• Child Access Prevention: Without enforcing biometrics, children who know their parent's device code could inadvertently (or intentionally) access sensitive financial applications.
• Regulatory Compliance: Many financial regulations require strong user verification that can distinguish between authorized users and others who may have legitimate device access but not application access.

By enforcing local biometrics, an app accepts only biometric unlocks and closes that gap. It is a privacy and compliance control: device access does not equal application authorization.

7.3 Combined Approach: Passkeys with Step-Up Authentication and Local Biometrics#

For regulated environments, a layered authentication strategy provides both security and compliance:

Initial Authentication (New User or New Device):

1. Passkey Creation: User authenticates with a passkey on a new device or during first app installation.
2. Step-Up Methods: For enhanced security on first use, combine passkey authentication with additional verification:
   • SMS OTP
   • Liveness detection
   • Video identification
   • Other regulatory-compliant methods

This "passkey step-up" brings the initial trust establishment up to regulatory standards, which is what PSD2's Strong Customer Authentication (SCA) requirements ask for.

Ongoing Authentication (Established User):

3. Local Biometrics Enforcement: Once the initial trust is established, activate and enforce local biometric verification (e.g. Face ID, fingerprint).
4. Subsequent Access: All following app unlocks require biometric verification, which rules out passcode-based access and confirms the verified user is present.

The combination satisfies the regulator and stays usable: strong authentication on first use, biometric access every day after that.

7.4 Web Applications: Closing the Gap with Device Trust and Shared Device Detection#

Once passkeys are in a compliance review, the web implementation lands in it too, because you cannot enforce biometrics on passkeys in web. You can require userVerification, but the browser decides the modality, so the user may satisfy UV with a biometric or with a device PIN. A web-based banking application cannot control that. Device trust and shared device detection close the gap instead.

The Shared Device Challenge:

On the web, regulated environments have to prevent passkey creation on shared devices: library computers, internet cafés, kiosks. Without controls, a user creates a passkey on a device they do not own.

How Corbado addresses Web Device Trust:

Fingerprinting is not a standalone SCA element under PSD2 and should not be treated as one. Corbado uses a cookie-based device trust system combined with client environment tracking instead:

1. Shared Device Detection: A device is recognized across the accounts that sign in from it, and once more than one user account is seen on the same device, Corbado records that device as shared. The record is read back per user in Advanced User Search, together with which of that user's client environments sit on a shared device, so a kiosk or a family desktop is identifiable before you decide what to offer on it.

2. Smart Device Recognition: Rather than creating a new "device" for every login, the system recognizes when a user has updated their browser, switched to incognito mode, or is on the same physical device. That keeps the device list short and the trust signal accurate.

3. Platform-Specific Policies:

   • Mobile (iOS/Android): Immediate passkey creation allowed, as shared mobile devices are rare
   • Desktop (Windows/macOS): Waiting period before allowing passkey creation, to rule out a shared device

4. Cookie Lifetime Is a Design Constraint: Cookie-based recognition holds only as long as the browser keeps the cookie. Safari's Intelligent Tracking Protection, a cleared profile or a new browser install all drop it, and the session then looks like a first-time device. Plan for that case explicitly and let the platform policy above decide what happens next.

Deployment Models for Regulated Environments:

Corbado supports staged deployment strategies:

• SDK with Telemetry Only: Monitor device landscape and passkey readiness before full rollout
• Hybrid Approach: Combine passkey authentication with traditional methods during transition
• Full Connect Rollout: Passkey login, append and management run through Corbado Connect, with gradual rollout rules deciding per client where passkeys are offered

Additional Web Protections:

For regulated use cases, layer additional security:

• Step-Up Authentication: Require additional verification for sensitive operations on untrusted or new devices
• Cross-Channel Verification: Combine web passkey login with app push notifications for a second channel
• Continuous Monitoring: Track session behavior and re-authenticate for high-risk actions

For Regulated Use Cases:

The combination of device trust, shared device detection, and step-up mechanisms creates a compliant authentication flow for web applications. However, each regulated environment has unique requirements. For detailed guidance on implementing these controls for your specific compliance needs, contact our team to discuss your regulated use case.

7.5 Summary: Local Biometrics in Regulated Environments#

For banks and regulated applications, local biometrics are a compliance and privacy control. By enforcing biometric-only verification, organizations can:

• Close privacy gaps that arise from shared device access
• Meet regulatory requirements on who is allowed into the app
• Protect vulnerable users (children, elderly) from unauthorized access
• Maintain audit compliance with clear authentication factors
• Keep everyday access fast without sacrificing security

Passkeys for the initial authentication, step-up methods for regulatory compliance and enforced local biometrics for ongoing access add up to a compliant and user-friendly authentication setup, even in the strictest regulated environments.

8. Recommendations#

Four recommendations for the scenarios where local biometrics and passkeys usually come up:

1. For Regulated, Sensitive or High-Value Data Apps: Passkeys + Local Biometrics
   If your app deals with critical, personal, regulated, or high-sensitivity data (e.g., financial, healthcare, governmental, personally identifiable information), implement local biometrics for the re-authentication. Once users are signed in, on-device factors (Face ID, Touch ID, fingerprint scanning) protect ongoing access to sensitive features without a credential prompt. The same data sensitivity is a strong argument for implementing passkeys and enforcing the MFA requirement across all device types. This is where Corbado Connect helps, especially in a large-scale deployment where you want to reach full passkey adoption.
2. Large-Scale Consumer App: Passkey Integration Across All Devices
   Even outside of sensitive areas a passkey implementation makes sense to avoid phishing and remove the password pain. When planning a passkey rollout, make it one strategy that spans all device types, including native apps, web interfaces and other connected endpoints. Don't treat passkeys as a one-off feature; instead, integrate them consistently across mobile, desktop, and web to provide a unified and user-friendly login experience. When passkeys are already part of your web authentication, extend it to your native apps too, so users get the same login wherever your service runs.
3. Greenfield or Standalone Apps:
   For new (greenfield) applications or standalone apps without legacy authentication baggage from web, consider starting with passkeys from the beginning. The ideal onboarding flow prompts for passkey creation immediately after account setup, followed by a prompt to enable local biometrics for session protection if required. By doing so, you create a future-proof authentication scheme without any password baggage on any platform. Take a look at our Corbado Complete solution.
4. Avoid Partial Implementations for Multi-Device Ecosystems:
   If your service spans multiple device types (e.g., mobile, web, and desktop), do not introduce passkeys in only one environment. Partial implementations reduce consistency and can confuse users. Adopt passkeys uniformly instead, so the login looks the same everywhere. Rolling them out step by step or first on the largest device types and then in the native app is reasonable, but it should be done within a short time frame.

Your own mix of security, usability and compliance requirements decides which of the four applies, so check them against your use case before you commit to one.

9. How Corbado can help#

Every recommendation above depends on an assumption about the device in the user's hand: that a biometric is enrolled at all, that the app and the web login behave the same way, that the fallback is reachable. Corbado Observe, the authentication observability layer, records what each session actually reported, so those assumptions stop being assumptions.

See User Debugging in Corbado Observe →

• What the device brings to a native session. For app flows the client environment carries the device screen lock as the OS reports it, which is Face, Fingerprint, a passcode, a strong or weak Android biometric class, or none at all, alongside Bluetooth availability, the Google Play Services version, the device model and the app version. It shows up per session when you open one user's flow in User Search, which is the level a support case or a compliance question is argued at. Web sessions carry the WebAuthn capability signals instead, because section 7.4 is right that the browser owns the modality there.
• App and web measured the same way. Both are classified into the same subflows, so passkey enrollment and passkey login in the native app can be read next to the web numbers. Recommendation 4 warns against a partial implementation across device types, and this is where a partial one becomes visible.
• Which enrollment prompt worked. Passkey enrollment is broken down by the variant the user was shown, manual, automatic or conditional, each carrying its share of the flows where a passkey was offered at all, and each with its own reasons for ending early. Section 5.2 discusses when to ask existing users, and this answers which ask they accepted.

10. Conclusion#

Local biometrics and passkeys do different jobs and work well together. Local biometrics handle ongoing session verification with a fast on-device check, passkeys establish the phishing-resistant trust relationship with the remote service. Coming back to the questions from the introduction:

• Passkeys vs. Local Biometrics: How local biometrics and passkeys differ in their roles and functionality?
  Local biometrics re-verify a user who is already authenticated, confirming that the rightful owner still holds the device. Passkeys replace shared secrets like passwords and handle the initial remote authentication, which removes the phishing risk and gives the user the same login across platforms and devices.
• Add Passkeys to Apps with Local Biometrics: Does it make sense to add passkeys to apps that already use biometrics?
  Yes, it often makes sense. Biometrics alone do not establish user identity with a remote service, passkeys do. Adding passkeys next to existing local biometrics strengthens security without costing convenience: the passkey covers the first authentication and the move to other devices, the biometric covers everything after that.
• Banks & Regulation: Why are local biometrics especially important for banks and sensitive apps?
  In regulated environments, local biometrics are a compliance and privacy control. By enforcing biometric-only verification, organizations close the privacy gap from shared device access, meet requirements like PSD2, and keep out someone who knows the device passcode but should not have app access. On web platforms where biometric enforcement isn't possible, intelligent device trust and shared device detection mechanisms provide equivalent protection.

About Corbado

Corbado is the Passkey Intelligence Platform for large-scale CIAM teams running consumer authentication. We help you see what IDP logs and generic analytics tools can't: where passkeys, passwords, OTP, social login and fallback journeys succeed, stall or fail, which devices and browsers create friction, and when an OS update silently breaks login. Two products: Corbado Observe layers process mining and observability across authentication journeys. Corbado Connect adds managed passkeys with analytics built in alongside your IDP. VicRoads runs passkeys for 5M+ users with Corbado (+80% passkey activation). Talk to a Passkey Expert →

Frequently Asked Questions#

How do I decide whether my native app needs local biometrics, passkeys, or both?#

Apps handling non-sensitive data, like a travel booking app, can use passkeys alone for frictionless cross-device authentication without local biometric protection. Apps handling sensitive or regulated data, like banking or healthcare, should implement both: passkeys for initial phishing-resistant remote authentication and local biometrics to enforce biometric-only ongoing session access, closing the privacy gap created by shared device passcodes.

Why do banking regulations like PSD2 require local biometric enforcement on top of passkeys?#

Passkeys accept either biometric verification or a device PIN as valid user verification, meaning a family member or child who knows the device passcode could access a banking app. Local biometric enforcement closes this gap by ensuring only the biometric owner can access the app, satisfying PSD2 Strong Customer Authentication requirements and preventing unauthorized access from users who have legitimate device access but not application authorization.

What are the most effective moments to prompt existing native app users to create a passkey?#

The two highest-acceptance triggers are the post-sign-in nudge shown immediately after a full re-authentication such as an app reinstall and the post-transaction nudge offered after an SMS OTP action. Lower-impact options include in-app banners and settings-page prompts. Detailed telemetry tracking each funnel step from prompt shown to creation completed prevents prompt fatigue and shows where adoption is lost.

How can a web-based banking app prevent passkey creation on shared devices like library computers?#

Corbado recognizes the browser environment behind each login with a cookie-based device record and marks a device as shared once more than one user account signs in from it. That flag is read back per user in Advanced User Search, together with the client environments of that user which sit on a shared device, so passkey creation can be held back there. On desktop the default is a waiting period before a passkey is offered at all, while mobile devices are treated as personal and can create one immediately.