Stolen credentials remain one of the top two initial access vectors across all industries, according to the 2026 Verizon Data Breach Investigations Report—and for banks, where digital accounts provide direct financial access, they continue to drive account takeover fraud, credential stuffing, and real-time phishing campaigns at scale.
The regulatory response has been unambiguous: PSD3 and PSR1 are in active implementation across EU member states, DORA is in force, and regulators across the EU, United States, and Asia-Pacific are converging on a single requirement—phishing-resistant authentication.
FIDO2 passkeys are now the clearest path to meet that bar. But the conversation does not end at passkeys. The emergence of quantum computing means the cryptographic foundations of today’s authentication architecture face a longer-term threat that forward-thinking institutions need to plan for today. This article covers how FIDO2 passwordless authentication works in banking, what PSD3 and PSR1 require, and why post-quantum cryptography belongs in your roadmap—along with eight questions to assess where your institution stands.
Modern banking fraud rarely targets passwords in isolation. Attackers exploit the systems built around them: real-time phishing proxies intercept SMS one-time codes before users finish entering them; SIM swap attacks redirect verification messages to attacker-controlled devices; social engineering at help desk entry points bypasses primary authentication entirely. Authentication built on shared secrets creates attack surfaces that policy controls alone cannot close.
What makes banking a high-value target for credential attacks?
Account takeover fraud remains the leading vector in digital banking. Credential stuffing tools test billions of previously exposed username-password combinations against banking portals in automated campaigns. Multi-factor authentication (MFA) has raised the bar—but not all MFA is equal. SMS OTPs and push notifications remain phishable: an attacker who tricks a user into approving a real-time push notification gains access regardless of the second factor in the flow.
FIDO2 passkeys address this at the architecture level, not the policy level. By eliminating shared secrets and binding credentials to specific relying party (RP) domains, they remove the mechanism that makes phishing economically viable—there is nothing to intercept, relay, or replay.
FIDO2 is an open authentication standard developed by the FIDO Alliance in collaboration with the W3C. Its WebAuthn specification enables browsers and applications to authenticate users using cryptographic credentials—passkeys—in place of passwords.
When a user registers a passkey, the device generates a public-private key pair. The private key never leaves the device; the bank stores only the public key. During authentication, the bank sends a challenge; the device signs it with the private key; the bank verifies the signature. No secret is transmitted. Each credential is also cryptographically bound to a specific domain, so it cannot be used on a phishing site—even one that is a pixel-perfect visual replica of the legitimate banking portal.
Passkeys vs. hardware security keys: what is the right fit for your bank?
Passkeys come in two main forms. Synced passkeys replicate across a user’s devices through platform ecosystems such as Apple iCloud Keychain or Google Password Manager. They simplify recovery and are well-suited to retail customers. Device-bound passkeys are tied to a single device and never exported, providing higher assurance for privileged access, corporate banking users, or high-value transaction flows.
For institutions requiring the highest level of assurance — corporate banking, privileged administrators, or contexts mandating separation from the user’s primary device — hardware security keys offer a dedicated authenticator with no internet exposure and mandatory user presence verification for every use. The RSA iShield Key 2 Series provides FIDO2-certified hardware authentication that integrates with RSA ID Plus across cloud, hybrid, and on-premises environments—allowing banks to deploy the right authenticator for each user population from a single platform.
RSA deployed FIDO2 passwordless authentication across its own global workforce, reaching near-complete adoption on managed endpoints within twelve months. The full account — including how to handle legacy dependencies and enterprise-scale change management — is documented in the Inside RSA: Deploying FIDO and Passwordless Solutions at Scale case study, developed in collaboration with the FIDO Alliance.
FIDO2 can satisfy PSD2’s Strong Customer Authentication (SCA) requirements when correctly implemented. The authenticator device provides the possession factor; a biometric or PIN provides inherence or knowledge. Dynamic linking—binding authentication to a specific transaction amount and beneficiary—can be incorporated into FIDO2 flows, making it a complete SCA solution for both identity authentication and payment approval.
What does PSD3/PSR1 change for banking authentication?
PSD3 and its companion regulation PSR1 reached political agreement in 2025 and are in active implementation, with transition timelines extending into 2027 and 2028. Three changes are most significant for authentication teams. First, PSD3/PSR1 introduces strengthened expectations for phishing-resistant SCA—moving beyond the baseline two-factor model of PSD2 toward methods that cannot be intercepted or relayed. Second, banks face increased liability in fraud scenarios where phishing-resistant authentication was available but not deployed. Third, institutions must provide mandatory alternative authentication methods for users who cannot use the primary method, requiring a multi-authenticator architecture rather than a single-method deployment.
FIDO2 with device-bound passkeys or hardware security keys aligns directly with PSD3/PSR1’s direction. Institutions that have already deployed FIDO2 will be better positioned to demonstrate compliance—and to produce the access review records and audit documentation regulators will request. RSA Governance & Lifecycle automates access review records and compliance reports, reducing audit preparation from weeks to hours.
Quantum computing capable of breaking current asymmetric encryption is not yet commercially available. The planning problem, however, is already present. The attack strategy known as “harvest now, decrypt later”—collecting encrypted network traffic today with the intention of decrypting it once quantum capabilities mature—is already being executed by sophisticated threat actors targeting high-value institutions. For banks, where authentication traffic and long-term customer data represent targets of sustained interest, this represents a genuine risk horizon that requires action before the quantum threat materializes.
What is the “harvest now, decrypt later” threat?
Today’s standard public-key cryptography—the foundation of TLS, digital signatures, and FIDO2 credential operations—relies on mathematical problems that classical computers cannot solve at scale. A sufficiently powerful quantum computer running Shor’s algorithm could solve these problems efficiently, retroactively exposing any data encrypted under today’s standards. Institutions that store or transmit authentication-related data should assume that sophisticated adversaries may already be archiving it for future decryption.
NIST post-quantum standards and the path forward for banks
In August 2024, NIST finalized its first three post-quantum cryptography standards: ML-KEM (lattice-based key encapsulation), ML-DSA (lattice-based digital signatures), and SLH-DSA (hash-based signatures)—all designed to be secure against both classical and quantum attacks. The FIDO Alliance is actively working to incorporate PQC algorithms into the FIDO2 standard, which will allow passkeys and hardware security keys to maintain their phishing-resistance properties as quantum computing advances.
RSA ID Plus support for hybrid and on-premises deployment gives financial institutions architectural flexibility as PQC standards are incorporated into identity infrastructure. Rather than requiring a single large-scale migration, banks can harden authentication methods today and layer in quantum-resistant algorithms as FIDO Alliance PQC specifications mature. Explore RSA’s full passwordless authentication capabilities.
These questions are drawn from RSA’s enterprise deployment experience and current regulatory guidance for financial institutions. Use them to identify gaps before they become audit findings.
- Have you mapped all password dependencies in your enrollment, recovery, and policy flows — not just the primary login path?
Enrollment and account recovery flows are the most commonly overlooked password dependencies. Removing them before deploying passkeys is essential to a genuinely passwordless architecture.
- Do your current authentication methods satisfy PSD3/PSR1 SCA requirements with phishing resistance, including dynamic linking for payment authorization?
FIDO2 can satisfy SCA — but implementation details determine compliance. Confirm your setup covers both identity authentication at login and transaction signing at payment approval.
- Can your authentication architecture support multiple authenticator types across different user populations — retail, corporate, branch staff, and privileged administrators?
A single authenticator type rarely meets the needs of every user group. Multi-authenticator architecture is a planning requirement, not a future upgrade.
- Are your account recovery flows as strong as your primary authentication method?
Recovery flows are frequently the weakest link in otherwise phishing-resistant architectures. Social engineering at the help desk recovery path is a well-documented attack vector.
- Are your ICT third-party contracts for authentication services compliant with DORA Article 30 requirements — including availability guarantees, incident notification timelines, and audit rights?
Authentication services qualify as critical ICT third-party services under DORA. Contracts predating January 2025 may require amendment before your next supervisory review.
- Have you assessed the post-quantum exposure of your current authentication stack — specifically which cryptographic algorithms are in use and which will need to transition?
This is a planning exercise that should begin now, while timelines are long enough to act methodically rather than reactively.
- Does your identity platform support hybrid or on-premises deployment for operational resilience and data residency compliance?
Cloud-only authentication without hybrid failover may not satisfy DORA operational continuity requirements. Hybrid deployment is increasingly a regulatory expectation.
- Can your platform automatically generate the access review records, incident logs, and compliance reports required for DORA, PSD3/PSR1, and national regulatory audits?
Manual compliance reporting at scale is not sustainable. Automation should be an explicit selection criterion when evaluating authentication platforms.
RSA ID Plus is designed to answer yes to all eight. Explore RSA’s passwordless authentication solutions or request a consultation with the RSA identity security team.
Passwordless banking is not a single product decision — it is an architectural shift that touches authentication methods, account recovery flows, regulatory documentation, third-party contracts, and long-term cryptographic planning. FIDO2 passkeys provide the foundation: phishing resistance, strong domain-bound cryptography, and direct regulatory alignment with PSD3/PSR1 and DORA. Successful deployment requires coordinated planning across all of these dimensions.
RSA has deployed FIDO2 passwordless authentication across its own global workforce, documenting every integration challenge, legacy dependency, and change management hurdle along the way. Explore RSA’s passwordless capabilities, read the Inside RSA enterprise deployment case study, or request a consultation to assess your institution’s readiness.
Passwordless authentication in banking replaces passwords and shared secrets with cryptographic credentials that authenticate users without transmitting sensitive data. FIDO2 passkeys use public-private key cryptography: the private key never leaves the user’s device; the bank verifies a cryptographic signature. Credentials are domain-bound, eliminating phishing and credential replay as attack vectors.
When a user registers a passkey, the device generates a public-private key pair. The private key is stored securely on the device and never exported. During authentication, the bank sends a challenge; the device signs it with the private key; the bank verifies the signature against the stored public key. Each credential is cryptographically bound to the bank’s domain, so it cannot be used on phishing sites.
FIDO2 can satisfy PSD3/PSR1 Strong Customer Authentication requirements when correctly implemented. Device-bound passkeys or hardware security keys satisfy the possession factor; a biometric or PIN satisfies inherence or knowledge. Dynamic linking for payment authorization can be incorporated into FIDO2 flows. Banks should confirm their specific implementation covers both identity authentication and transaction signing.
Synced passkeys replicate across devices through platform ecosystems such as iCloud Keychain or Google Password Manager, improving usability and supporting self-service recovery. Device-bound passkeys are tied to a single authenticator and never exported, providing higher assurance for privileged access, corporate banking, or high-value transactions.
Post-quantum authentication uses cryptographic algorithms resistant to quantum computer attacks. Current FIDO2 relies on elliptic curve cryptography, which a sufficiently powerful quantum computer could break. The harvest now, decrypt later” threat means adversaries may already be archiving encrypted authentication traffic for future decryption. NIST finalized three post-quantum cryptography standards in August 2024. Banks should include PQC migration planning in their authentication roadmaps now.
DORA requires EU financial institutions to maintain operational continuity for ICT systems—including authentication services—during cyber incidents. Authentication platforms must meet DORA Article 30 requirements for ICT third-party providers, covering availability guarantees, incident notification timelines, and audit rights. DORA also requires comprehensive audit logs and tested business continuity plans covering authentication system availability.
PSD3 and PSR1 strengthen PSD2’s SCA requirements with explicit expectations for phishing-resistant authentication, increased bank liability in fraud scenarios where phishing-resistant methods were available but not deployed, and mandatory alternative authentication methods. Transition timelines extend into 2027 and 2028.
Cloud-based authentication can meet DORA’s requirements if the platform and contracts satisfy Article 30. Institutions relying solely on cloud authentication without hybrid failover may struggle to demonstrate the operational continuity DORA requires. RSA ID Plus supports cloud, hybrid, and on-premises authentication from a single platform, with hybrid failover ensuring authentication services remain available if cloud connectivity is disrupted.
