Passkeys are often promoted as the future of authentication, offering a passwordless and phishing-resistant login experience. But while they make logins easier for consumers, their ability to seamlessly transfer between devices introduces a critical security flaw—one that makes them unsuitable for financial services and other high-assurance industries.
The problem? Passkeys cannot provide a reliable audit trail.
Passkeys and the Broken Chain of Trust
A core requirement in financial services security is the ability to track and verify every authentication attempt. Banks, fintechs, and payment providers must ensure that every login has a clear, auditable record of:
Who authenticated
Which device performed the authentication
When it happened
This traceability is critical for fraud detection, dispute resolution, and regulatory compliance under frameworks like PSD2 in Europe, MAS TRM in Singapore, and the FFIEC Authentication Guidance in the U.S.
However, because passkeys are designed to be transferable, they break this chain of trust. A user can create a passkey on one device and then access it from any other trusted device without any explicit verification of which hardware is actually being used. This means there’s no guarantee that the original, secure device was the one performing authentication.
This is especially problematic in industries where device-level security matters as much as user identity. Financial institutions, for example, are required to implement multi-factor authentication (MFA) measures that bind to a specific device to ensure a stronger level of trust. But passkeys, by design, don’t enforce this.
The Real-World Consequences of Transferable Passkeys
In practice, this weakens security. If an attacker gains access to one of a user's linked devices—whether through malware, session hijacking, or device theft—they can authenticate using a passkey without triggering any alerts that the login is coming from a different device.
Industry experts have raised concerns about the lack of strong attestation in current passkey implementations, meaning there’s no built-in way to verify that authentication is happening on a legitimate, known device.
Google, for example, still requires hardware security keys for its Advanced Protection Program (APP), which protects high-risk users. Even Google’s own security team acknowledges that passkeys don’t yet provide the same level of security as device-bound authentication methods, particularly in scenarios where strict control over login devices is necessary.
A real-world example of the risks posed by transferable authentication credentials comes from Okta’s 2023 security breach, where attackers used compromised session tokens to access accounts undetected. While session tokens aren’t the same as passkeys, the underlying issue is similar—once authentication credentials can move between devices freely, it becomes harder to enforce strong security controls.
Why Financial Services Require Device-Bound Authentication
Given the risks associated with transferable passkeys, financial institutions need stronger protections. The ability to tie authentication to a single, verifiable device is essential for ensuring compliance with industry standards and reducing fraud risk.
Device-bound authentication provides:
Verifiable Audit Trails – Ensures every login attempt is linked to a specific device, closing the accountability gap.
Stronger Fraud Prevention – Eliminates the possibility of passkeys being used on unverified devices.
Regulatory Compliance – Aligns with banking security mandates that require strict authentication controls.
This is why many security experts recommend hardware-bound credentials or other forms of device-bound authentication over passkeys in high-security environments. Even within the WebAuthn ecosystem, security keys with FIDO-certified attestation offer a higher level of security than passkeys that can roam between devices.
In Conclusion...
Passkeys may be convenient, but they introduce significant security gaps for industries that require strict authentication controls. Financial institutions, in particular, need to ensure that every login is both phishing-resistant and tied to a verifiable device—something today’s passkeys simply don’t guarantee.
As authentication standards evolve, the industry needs to recognize that security shouldn’t be sacrificed for convenience. Financial services require authentication methods that provide both strong security guarantees and regulatory compliance. Right now, passkeys aren’t up to the task.
Sources:
FFIEC Guidance on Authentication and Access to Financial Institution Services and Systems: https://www.ffiec.gov/guidance/Authentication-and-Access-to-Financial-Institution-Services-and-Systems.pdf
Google Advanced Protection Program FAQ: https://landing.google.com/advancedprotection/faq/
Google Advanced Protection Program Overview: https://landing.google.com/advancedprotection/
FFIEC Press Release on Authentication Guidance: https://www.ffiec.gov/press/pr081121.htm
Google Advanced Protection Program Support Page: https://support.google.com/accounts/answer/7539956?hl=en-419
FDIC Financial Institution Letter on Authentication and Access Guidance: https://www.fdic.gov/news/financial-institution-letters/2021/fil21055.html
Deloitte's Overview of FFIEC Guidance: https://www2.deloitte.com/content/dam/Deloitte/us/Documents/regulatory/us-ffiec-guidance-on-authentication-and-access-to-financial-institution-services-and-systems-oct21.pdf
Yubico's Information on Google Advanced Protection Program: https://www.yubico.com/works-with-yubikey/catalog/advanced-protection-program/
Consumer Financial Protection Bureau's Announcement on FFIEC Guidance: https://www.consumerfinance.gov/about-us/newsroom/ffiec-issues-guidance-on-authentication-and-access-to-financial-institution-services-and-systems/
PCMag Article on Google's Advanced Protection Program: https://www.pcmag.com/news/googles-advanced-protection-program-swaps-security-keys-for-passkeys
OCC Bulletin on Information Security: https://occ.treas.gov/news-issuances/bulletins/2021/bulletin-2021-36.html
DataGuidance on Payment Services Directive 2 (PSD2): https://www.dataguidance.com/sites/default/files/guidance-payment-service-directive-2-psd2.pdf
Mastercard's Blog on PSD2 and Strong Customer Authentication: https://openbankingeu.mastercard.com/blog/upgrading-security-with-psd-2-and-strong-customer-authentication/
Corbado's Explanation of PSD2 Authentication Requirements: https://www.corbado.com/blog/psd2-sca-requirements/psd2-authentication-requirements
OneSpan's White Paper on PSD2 and Strong Authentication Solutions: https://www.onespan.com/sites/default/files/2019-08/OneSpan-WhitePaper-A4-PSD2-Which-Strong-Authentication-Solutions-Comply.pdf
BleepingComputer Article on Okta's Support System Breach: https://www.bleepingcomputer.com/news/security/okta-says-its-support-system-was-breached-using-stolen-credentials/
TechCrunch Report on Okta's Data Breach: https://techcrunch.com/2023/11/29/okta-admits-hackers-accessed-data-on-all-customers-during-recent-breach/
Okta's Official Statement on October 2023 Security Incident: https://sec.okta.com/articles/harfiles/
KrebsOnSecurity Article on Okta's Support Unit Breach: https://krebsonsecurity.com/2023/10/hackers-stole-access-tokens-from-oktas-support-unit/
Okta's Root Cause Analysis of Support Case Management System Breach: https://sec.okta.com/articles/2023/11/unauthorized-access-oktas-support-case-management-system-root-cause/
Dataconomy's Breakdown of the Okta Data Breach: https://dataconomy.com/2023/10/23/okta-data-breach/
BleepingComputer Report on Okta's October Support System Hack: https://www.bleepingcomputer.com/news/security/okta-breach-134-customers-exposed-in-october-support-system-hack/
The Hacker News Article on Okta's Support System Breach: https://thehackernews.com/2023/10/oktas-support-system-breach-exposes.html
Comments