Passkeys in Banking: What They Actually Fix, and What They Quietly Don't
06 Aug 2026 Banking Cyber

Passkeys in Banking, Part 1: What They Actually Fix, and What They Quietly Don’t

Sponsored
Learn English Online with a Private Teacher
Simple lessons · For you and your children · From €14 per lesson
Start Today →
👁50views

Passkeys replace shared passwords with device bound public key pairs, eliminating credential stuffing, phishing via fake domains, and breach driven account takeover. However, a Unit 42 disclosure demonstrates account takeover without breaking cryptography, exploiting gaps between specification assumptions and ecosystem behavior. Any fallback path to older authentication methods preserves the very attacks passkeys are meant to retire.

CloudScale AI SEO: Article Summary
  • 1.
    What it is
    Passkeys replace shared passwords with device bound public key pairs, eliminating credential stuffing, phishing proxies, and breach driven account takeover. The article explains the mechanism and examines where specification meets real world implementation gaps.
  • 2.
    Why it matters
    Understanding both the strengths and the gaps matters for anyone planning a banking passkey rollout, because fallback paths preserve old attack classes even when passkeys are deployed.
  • 3.
    Key takeaway
    Passkeys retire entire attack classes only where authentication is genuinely passkey only, because any fallback or recovery path keeps those attacks alive.
~18 min read
Related Articles
🎧 Listen to this article

Passkeys are the most consequential change to consumer authentication in twenty years, and they are also being oversold, because the gap between the marketing and the implementation detail is exactly where fraud losses will land.

The industry framing is simple enough. Public key cryptography replaces the shared secret, so there is nothing to phish, nothing to reuse and nothing to dump from a breached database. That framing is broadly correct, but a research disclosure from Palo Alto Networks Unit 42 on 3 August 2026, titled Pass the Passkey: A Novel Attack Surface in Passwordless Authentication, offers a useful corrective, because it demonstrates account takeover against accounts protected by passkeys without breaking a single cryptographic primitive. Every one of its attacks lives in the space between the assumptions of the specification and the way the ecosystem actually behaves.

For anyone planning a passkey rollout on a banking channel, both halves of that picture matter.

1. First, what a passkey actually is

The benefits only make sense once the mechanism is clear, so it is worth spending a paragraph or two on it, because almost every risk discussed later in this article turns on a detail of how it works.

A password is a shared secret. You know it, the bank keeps a stored representation of it, and anyone who obtains that secret can impersonate you from anywhere in the world. Sharing is the entire point of a password and it is also its fatal weakness, and that single property sits at the root of most account takeover.

A passkey replaces the shared secret with a pair of mathematically related keys created together on your own device at the moment you enrol. One of them, the private key, never leaves the secure storage of your device and is never seen by the bank at any point. The other, the public key, is sent to the bank and stored there, and it is not a secret at all, because on its own it cannot be used to log in to anything. When you later sign in, the bank sends your device a fresh piece of random data known as a challenge. Your device signs that challenge using the private key, and the bank checks the resulting signature against the public key it already holds, which proves that the signature could only have been produced by the matching private key. Nothing reusable ever crosses the network, so an eavesdropper who captures the whole exchange gains nothing they can use a second time.

Three pieces of vocabulary recur throughout the rest of this article. The bank is the relying party, meaning the party that relies on the outcome of the authentication. The software or hardware that holds your private key and performs the signing is the authenticator, which on a modern phone or laptop is usually built into the operating system and unlocked by your fingerprint, face or device PIN. The open standard that governs the whole exchange is WebAuthn, published by the World Wide Web Consortium, and it is the document that ultimately decides what a bank is and is not permitted to accept.

2. What passkeys genuinely fix

A breach of your authentication database stops being a catastrophe. Because the private key is never transmitted to the relying party, everything the bank stores is public by design. An attacker who exfiltrates the entire table obtains a collection of public keys that cannot be used to authenticate as anybody. This retires a set of attacks that have dominated fraud losses for two decades, including credential stuffing, which is the practice of taking username and password pairs leaked from one breached company and replaying them automatically against hundreds of others in the knowledge that a substantial proportion of people reuse their passwords. The secondary market that trades those leaked pairs has nothing to sell where passkeys are in use.

A passkey will not work on a fake website, no matter how convincing it is. When the credential is created, it is permanently tied to the exact web address of the site that created it, a property known as origin binding. A passkey enrolled at your real banking domain simply will not respond to a request from a look alike domain, and this happens automatically inside the browser and the operating system without the customer needing to notice anything, spot anything or make a judgement call. That matters because the current generation of phishing does not merely collect credentials on a fake page. It uses what is called a phishing proxy, a server that sits invisibly between the customer and the real bank and passes traffic through in both directions, so the customer sees genuine content, completes the login, enters the one time password sent to their phone, and the attacker silently collects a working session. Evilginx is the best known of these toolkits and it has made a mockery of authentication based on one time passwords. Origin binding breaks it, and with it goes the target surface for SIM swap, interception of SMS messages, push fatigue attacks that bombard a customer with approval prompts until one is accepted, and the social engineering of one time codes over the telephone.

That last claim carries an important condition. Those attacks lose their target only where authentication is genuinely passkey only, because they remain entirely available wherever a fallback or recovery path preserves the older mechanisms. This is not a footnote, since it is the whole difference between deploying passkeys and actually retiring an attack class, and I return to it at some length below.

Security stops costing the customer time. Passkeys collapse two steps into one, since a single fingerprint or face check simultaneously proves possession of the device and verifies the person holding it, which replaces the sequence of typing a password and then waiting for and retyping an SMS code. That should translate into more logins completed rather than abandoned, fewer customers giving up part way through enrolment, and materially lower demand for password resets, which is typically among the larger line items in the contact centre of a retail bank. Those are reasonable expectations rather than established facts, however, and every bank should measure them in its own base rather than assume them.

The economics of unsanctioned data aggregation change. Some third party providers obtain a customer’s banking data by a technique called screen scraping, in which the customer hands over their banking username and password to the provider, who then logs in as the customer, reads the pages and extracts the data. A passkey cannot be handed over in that way, because the private key is not extractable and not transferable in normal use, so making passkeys mandatory removes the credential sharing model on which scraping depends and pushes aggregators towards a sanctioned interface instead. That is a genuine strategic lever for a bank, although it is one that increasingly requires a regulatory answer alongside the technical one, since blocking scraping without offering a supported alternative is a different sort of problem.

None of this is marginal, because passkeys retire whole categories of attack rather than making existing defences slightly better. The interesting question is what moves into the space they vacate.

3. The risks have migrated rather than disappeared

Passkeys do not so much remove risk as move it, and the five sections that follow are where it lands. Not one of them is a weakness in the underlying cryptography, which is precisely what makes them worth a bank’s attention, because every one of them is a place where somebody made an implementation decision that could have been made differently.

4. The synchronisation fabric is the new attack surface

Most consumer passkey deployments are designed around synchronised credentials, replicated across a customer’s devices by Google Password Manager, iCloud Keychain or a third party manager. Synchronisation is what makes passkeys usable at scale, and it is also what makes them a fundamentally different security proposition from a hardware security key, a distinction that most risk assessments still conflate. Both the FIDO Alliance and NIST draw the line explicitly, and NIST excludes syncable authenticators from its highest assurance level, AAL3, precisely because their keys are exportable by design.

The Unit 42 research targets the synchronised passkey implementation of Google on Chrome for Windows, on machines fitted with a Trusted Platform Module, which is a dedicated security chip that stores cryptographic keys in a way intended to prevent software from ever reading them. The research also assumes that malware is already resident on the machine and running with the ordinary privileges of the logged in user. Three findings matter.

Chrome stores synchronised credential metadata in an unencrypted local database file, which unprivileged malware reads directly to obtain a clean index of every service where the customer uses a passkey, complete with usernames and credential identifiers. That amounts to target selection intelligence handed over at no cost, including a list of which banks a customer holds relationships with.

The first attack exploits the way Chrome handles its device identity key. Rather than keeping the key resident in the Trusted Platform Module, Chrome exports it as a wrapped blob to a local state file, and malware lifts that blob and reinvokes it through the standard Windows cryptography interfaces, producing a valid assertion from the Google Cloud Authenticator with no user consent, no biometric check and no device unlock. Crucially, this path leaves the User Verified flag unset.

The variant that the researchers call Silver is worse. Deleting the local passkey state forces the device to onboard again, and on Windows Chrome defers creating the user verification key until the second use of a passkey, which leaves a window in which that key is merely pending. The attacker registers a public key of their own as the user verification key, and because the Cloud Authenticator does not attest that a newly registered user verification key originated in secure hardware, it is accepted. The result is reusable and fully automated authentication with the User Verified flag set, executed from the environment of the attacker while the device of the customer sits offline entirely.

The variant they call Golden extracts the thirty two byte Security Domain Secret that encrypts every synchronised passkey on the account. It was briefly being written in plaintext to the Chrome device log, and Google removed it from the logs after disclosure, but the secret still transits client memory during onboarding and can be dumped from there. There is currently no mechanism to rotate or revoke it, so every existing and future synchronised passkey on that account remains protected by a key the attacker now holds, which means that detection does not enable remediation.

Two observations follow. All three attacks require the machine to have been compromised already, so this is research into what becomes possible after compromise rather than a way in from outside, and that caveat is thinner than it sounds, because malware of the sort that harvests credentials from customer machines, commonly called an infostealer, is not an exotic threat in retail banking but something much closer to the baseline condition we should assume.

5. Your entire second factor is one bit

This is the finding I would act on tomorrow, and it is worth being careful about the mechanism. The result of local user verification reaches the relying party as a single signed bit in the authenticator data. It is not a Boolean supplied by the client that an attacker can flip in transit, because it is covered by the assertion signature, so the problem is twofold: whether the authenticator set it honestly, and whether the relying party bothers to check it at all. WebAuthn is unambiguous that an operation specifying required must fail if the signed User Verified flag is absent.

A relying party is supposed to set user verification to required and also verify the flag in the response, and yet Unit 42 found relying parties that requested user verification and then never validated what came back, eBay among them, since remediated, while GitHub, tested the same way, correctly rejected the assertion.

An unvalidated flag silently collapses passkey authentication to a single factor while your architecture diagrams and your compliance attestations both continue to describe it as multiple factors. It is a defect of a single line with a catastrophic blast radius, and it is invisible to any test that only checks whether legitimate logins succeed.

6. Clone detection has largely gone

The signature counter in WebAuthn was intended to provide a weak signal that a credential had been cloned, in the sense that the same private key was in use by more than one instance of an authenticator. Synchronised passkeys commonly return a constant value, often zero, so that signal largely disappears. The stated position of Google is that globally consistent counters are impractical across independent clients on many devices, which is reasonable enough, but the consequence stands, and anything you planned to build on that counter now has to come instead from telemetry about devices and behaviour.

To be precise about what this does not mean, the signature counter is not the replay defence in WebAuthn. Replay of a captured assertion is prevented separately, by requiring a fresh and sufficiently random challenge generated by the server and then confirming that the returned challenge matches it, so a stale assertion fails on the challenge whatever the counter happens to say.

7. Recovery becomes the real perimeter

An authentication mechanism is only ever as strong as the path around it, so once the passkey itself is hard the attacker turns to the flows for enrolment and recovery, and it is worth noticing that both the Silver and the Golden variants begin by deliberately triggering the onboarding process again. If a lost device flow resolves to an SMS one time password and three knowledge based questions, then the passkey is decoration. Every unexpected prompt for a recovery personal identification number during what should be routine authentication is therefore a signal worth alarming on.

8. Downgrade paths, session gaps and the long tail

A fallback method is a fallback for the attacker as well. Researchers have demonstrated practical downgrades in which a phishing proxy spoofs an unsupported browser, the identity provider disables passkeys in response, and the customer is then steered towards a weaker method, so if passkeys are optional you have added a mechanism without having removed a risk.

Separately, a passkey assertion protects the ceremony in which it is used and does not automatically protect every request that follows, so theft of tokens after authentication remains entirely untouched, and the controls that address it are distinct rather than interchangeable. Browser sessions need something along the lines of Device Bound Session Credentials, which binds a supported browser session to a device key held in hardware. Clients calling programmatic interfaces can constrain tokens to the sender, either through Demonstrating Proof of Possession or through mutual transport layer security, so that the token is bound to a key the client holds. Native banking applications should combine proof of possession bound to hardware with attestation of the application and of the integrity of the device, which is a signal of provenance rather than a protocol for binding sessions in its own right. None of this removes the need for careful cookie handling, short token lifetimes and monitoring of behaviour after login.

The long tail is also real in a South African retail context, where shared devices, inexpensive Android handsets with inconsistent support for platform authenticators, and customers without an account in any synchronised ecosystem all mean that an approach relying on passkeys alone will, for now, exclude people.

9. What a bank should actually do

Almost none of what follows is glamorous, and that is rather the point, because the weaknesses described above were not failures of imagination so much as failures of verification. Somebody assumed a flag was being checked, or that a key could not leave a device, or that a recovery path would only ever be walked by the customer it was built for, and the assumption went untested for long enough to become architecture.

The list below is ordered roughly by the protection each item buys relative to the effort it costs. The first is the one to look at before any of the others, since it can be broken entirely silently, it will never show up as a failed login, and it can be tested in an afternoon.

  • Set user verification to required and validate the signed flag that comes back. Test this adversarially and assume it is broken until it has been proven otherwise.
  • Use attestation of the authenticator, or assurance signals from the provider, where your threat model justifies them, while understanding the boundary. Attestation is the mechanism by which an authenticator makes a verifiable statement about what it is and how it protects keys, so that a bank can decide whether to trust it. Ordinary WebAuthn attestation describes the authenticator that created your credential, and it does not necessarily prove that the internal device identity and user verification keys belonging to a provider of synchronised passkeys were securely generated or registered, while attestation may in any case be absent, anonymised or deliberately restricted for reasons of privacy. The gap that Unit 42 found in the Silver variant sits inside the credential manager, so that control ultimately belongs to the provider rather than to you, which is itself a reason to weight your choice of provider carefully.
  • Consider credentials bound to a single device for genuinely high assurance use cases, while accounting for the risks around recovery, device replacement and the exclusion of customers.
  • Do not treat a passkey login as authorisation for a payment. For material transactions, perform a fresh approval ceremony that cryptographically binds the amount, the beneficiary and the transaction context to what the customer actually saw and approved. Secure Payment Confirmation at the W3C follows this model. European readers will recognise the principle as the dynamic linking requirement of the second Payment Services Directive, and the underlying control is worth adopting whether or not that regime applies to you.
  • Bind the session using the mechanism appropriate to the channel, which means Device Bound Session Credentials for browsers and either Demonstrating Proof of Possession or mutual transport layer security for clients calling interfaces. Assurance at the moment of login is worthless if the resulting token turns out to be portable.
  • Require a browser to be registered before a passkey is vended into it, and keep the artefact that identifies the browser strictly separate from the artefact that carries session authority, since one is long lived and should carry no authority while the other carries authority and should be short lived. A rotating browser identifier also restores the clone signal that section 6 showed the signature counter no longer provides. Part two of this series, Securing Passkey Enrolment with Browser Registration, works this through in detail.
  • Harden recovery and treat repeated onboarding as a security event rather than as a support workflow.
  • Assume the endpoint is compromised, and keep intelligence about devices, protections against access to process memory, and analytics on behaviour firmly within the control set.
  • Make passkeys mandatory over time, and make every fallback as strong rather than merely more convenient.

10. The verdict

Passkeys are worth doing, because they eliminate real classes of attack, they improve the experience of the customer, and they shift the economics of credential theft in favour of the defender, which is a rare enough combination that it should not be undersold.

They are nonetheless one layer rather than a perimeter. The Unit 42 work is valuable precisely because it does not break the cryptography, since it shows that trust placed in a client device, inconsistency in the validation performed by relying parties, and softness in the flows for recovery are quite enough on their own. Those are problems of implementation, which makes them our problems rather than problems with the specification.

So deploy passkeys, validate the flag, watch the recovery path, and do not tell the board that phishing has been solved.

The most useful of those implementation decisions concerns the moment a passkey is issued in the first place, since whoever controls the enrolment flow controls the account. That argument is developed in part two of this series, Securing Passkey Enrolment with Browser Registration, which sets out how a browser can be made to earn the right to hold a credential before it is given one.

11. References

You Might Also Like