Passkeys have spread through consumer and enterprise authentication on one argument above all others: there is no password to phish. For banks and other regulated firms that argument has been persuasive enough that passkeys are now treated in some quarters as a complete answer to account takeover.
Conor White, president, strategic initiatives at Daon
Conor White, president, strategic initiatives at Daon, the digital identity and authentication company, does not think they are. In written answers to The Fintech Times he sets out where phishing resistance stops being the relevant defence, why the documented passkey attacks remain narrow, and why the exposure in regulated deployments sits in configuration, recovery and identity proofing rather than in the cryptography.
White starts by conceding the headline case. “Phishing resistance is the headline because phishing is still the loudest problem in authentication,” he writes. Most account takeovers begin with someone being talked into handing over a credential, and a method with no credential to hand over shuts that route down. “That part is real, and it is why passkeys have moved as fast as they have.”
The limit, in his account, is that phishing resistance protects only the credential. Take the credential away and the attacker moves to where the passkey is weak: the device it lives on, the cloud account it syncs to, and the gap between the device and the person. “A passkey proves the phone was unlocked, not who unlocked it,” he writes. None of those attacks involves a stolen secret, which is the problem phishing resistance was designed to solve. That is not, he says, a knock on passkeys, which he calls a vital element of modern identity security. Daon encourages its clients to layer them with other factors: “strong where it is strong, with something behind it for everywhere it was never designed to defend.”
Narrow attacks, and what would widen them
The documented attacks on passkeys need active malware on the device during authentication, and White does not expect the technology itself to change much. “These attacks do not break the cryptography; they go around it.” Because passkeys have no central store to raid, there is no single breach that spills millions of credentials at once, and an attacker has to invest effort one victim at a time.
Two developments would change that. One is a malware outbreak that makes “assume the device is already compromised” the baseline an enterprise designs for rather than the edge case. The other is a route in that needs no presence on the device at all, which he describes as potentially catastrophic because it would remove the single-target barrier. “Fortunately, it is not a real-world scenario today.”
He is more concerned about reach than volume. The most serious compromise scenarios are not about borrowing one login but about gaining control of the account or environment that protects multiple credentials and recovery paths. That remains a high-effort, one-victim-at-a-time attack, but it is also one “an enterprise cannot simply configure away”. The lesson Daon keeps presenting to clients is that a single strong factor, however strong, should never be the only thing between an attacker and something that matters.
Where the configuration goes wrong
Asked which configuration choices enterprises get wrong most often, White points first at user verification. A passkey can check that an authorised user of the device was present before the credential is released, but that check can be disabled, and many of the attacks being highlighted rely on it being switched off, or switched on but never actually confirmed by the server. Enable it, and require the confirmation, and most of those attacks run out of road. “Leave it off and your two factors quietly become one.”
The exposures that are harder to see are not settings at all. White uses the analogy of having a house rekeyed: a good locksmith requires proof that the customer lives there, and the customer expects the locksmith to prove their own credentials in turn. Re-registering a passkey is the same job and needs the same two checks. The person’s identity has to be established through a separate, strong assurance process before a new passkey is issued, because the cleverer attacks do not fight the passkey already in place; they wait for the moment a new one has to be generated and insert themselves into that process. A second layer confirming that a trusted device is making the request removes another route. “A passkey is a key to a lock that is extremely hard to pick, and that is all that should be expected of it. Keeping it out of the wrong hands is the task of the processes around it.”
Recovery follows the same logic. Most people picture recovery as something that starts when a customer is locked out. White argues the trustworthy flow is built at enrolment, when the firm verifies who someone is, ties that identity to a strong factor such as a server-hosted face template, registers the device and connects all of it to a single record of the person. Without that foundation, replacing a lost passkey falls back on weak factors, “usually shared secrets. An email or SMS response at best, a long-forgotten PIN or passphrase at worst.” Whoever clears that weak gate is handed a brand-new strong credential. “The strength of a recovery process was never in how it behaves at recovery. It is in whether you did the work to establish layered identity checks long before anyone needed it.”
The letter and the spirit of strong customer authentication
On strong customer authentication, White notes that similar rules exist across jurisdictions and that underneath they all ask for two things. Passkeys answer one cleanly and the other not at all.
The first is two independent factors. A passkey with user verification switched on offers something you have, in the key on the device, and something you are or know, in the check that releases it. “It is legitimately multi-factor in a single credential. On the letter of the requirement, a passkey does well.”
The spirit is another matter. What the rules are after, particularly once money is moving, is not merely that two factors were present but that the account holder was there and meant to do this. A passkey can confirm the device was unlocked by someone it trusts, “but not that the specific account holder in question approved this action, this amount, to this payee. Those are different claims, and the gap between them is exactly where fraud lives.” Closing it takes step-up authentication to re-establish that the account holder is present, and transaction signing to bind the approval to the exact action so that an altered amount or payee collapses it. “Meeting the letter is the easy part, but for a regulated firm managing high-value resources, the letter was never the point.”
Choosing the next layer
For a bank deciding which additional layer to add, and where in the customer journey, White’s answer is that the foundation comes first: verify who the person is at the start and bind that identity to a central record everything else hangs off. Factors added later, a new device or another biometric, “are only as strong as the foundational authentication factor used to bind them.”
When each layer comes into play is decided by risk rather than case by case. A passkey can secure a routine sign-in, but a large transfer, a new payee or an attempt to recover an account should trigger a stronger check that establishes account holder approval. The friction is proportionate: routine moments take little effort, and the interactions a customer would want protected add a measured amount, which he says is still less than traditional knowledge-based checks demand. On which layer to add, Daon’s customers often start with server-side face. “A server-hosted biometric template, on a system with well-implemented fraud detection, is a true cross-channel anchor to build off of.”
A correction on the premise
The Fintech Times had asked what Daon’s work with governments and law enforcement showed about passkeys that consumer rollouts do not. White corrected the premise. “We do not work with law enforcement, and while we do have government clients, their focus is on other areas of identity assurance.”
The split he does see is not consumer versus government but how much has to be proven. Many consumer services do not need to know exactly who is behind an account, and a device-bound passkey serves them well as a more secure, easier-to-use password. Regulated industries have to prove the credential belongs to a specific, real person, because the regulation they answer to demands it. At that level the passkey is the straightforward part; the work sits on either side of it, in proving identity before the credential is issued and re-establishing that proof when a device is lost. A server-hosted biometric can do that because it confirms the same person rather than whoever now holds the phone. “What changes is how deep the identity proofing underneath has to go.”
Asked which misunderstanding enterprise security teams should drop first, White names it directly: “Passkeys are all you need to secure your organisation.” A passkey is a strong authentication step, but one part of a larger effort to stop fraud. It proves a device was unlocked by someone that device trusts. “It does not fully prove the right person is there, and it does not prove they meant to do what is being done.” The teams that get this right, he says, treat the passkey as one layer, with a proven identity underneath it and a stronger check wherever the stakes climb.
Conor White was part of the core team that founded Daon. He joined the company as chief technology officer in 2001, became President of the Americas in 2015 and took the role of President, Strategic Initiatives in 2023.
