We sat down with Cornell researcher Alaa Daffalla to talk through her latest research into what actually happens after a passkey account is compromised, why resetting the password isn't always enough anymore and where current recovery processes are falling down.
A lot of the conversation around Passkeys has focused on how much stronger they are than passwords. But Alaa Daffalla decided to look at another side of the problem.
What happens when somebody has already got in?
If an attacker gets temporary access to an account and adds their own Passkey, can the real user actually work out what has happened and remove them?
Alaa and the team tested this with 31 people using test accounts across Google, PayPal and LinkedIn.
In the scenario the attacker got one-time access to the account password and used it to add their own Passkey. The participant then had to work out what had happened and secure the account.
The result was pretty shocking.
“No participant was able to completely secure the account without assistance from the researchers.”
Not one of the 31 could do it without being nudged or reminded by the research team. The interesting part though was where people were going wrong.
People changed the password and thought they were done
This for me was the biggest takeaway from the research.
If you think your account has been compromised, what is probably the first thing you do?
Change the password!
We have basically trained people for years that this is how you secure a compromised account. The problem is Passkeys change that.
If an attacker gets access to your account and adds their own Passkey, changing the password doesn't necessarily remove that Passkey. So the attacker could still have another way back in.
Alaa said this was the part people failed at most.
“Mostly people failed at... identifying or removing the adversarial passkey.”
Participants would reset the password and then basically think everything was okay as people are used to thinking the password is the thing protecting the account. Reset that and the problem is fixed.
But once you add Passkeys into the mix there are now potentially other credentials sitting on the account as well.
Recovering an account can now mean:
Reset the password
Find all the Passkeys
Work out which Passkey isn't yours
Remove it
Review active sessions
Remove any attacker sessions
That's quite a lot more than just changing the password.
The security wizard actually made people think they had finished
The Google example was probably the most interesting. Participants received a security email telling them a new Passkey had been added to the account.
If they clicked through the email, Google took them through its security recovery process. That process got them to reset the password and then took them through the Security Checkup.
The problem was that at the time of the research the Security Checkup didn't actually get the user to review the Passkeys on the account.
So someone could:
Receive an alert about a new Passkey
Follow Google's security process
Reset their password
Reach the end
And still have the attacker's Passkey sitting on the account.
Alaa described these as false finishes.
“They think their account is secure. I reset the password. Everything must be great right now. But what they don't realize is that the passkey is still configured.”
The user hasn't ignored the warning and they actually followed the process they were given. It just didn't fully deal with the thing that caused the alert.
Years of anti-phishing training caused another problem
Another thing I found interesting was that a lot of participants didn't click the links in the security emails at all and normally we would probably say that's good security behaviour.
People have spent years being told:
Don't click links in unexpected security emails.
And that training has obviously worked.
“For most participants, they're not actually clicking on email links because they were concerned about phishing, which is fairly legitimate.”
The problem is once they don't click the link, they then have to find all the security settings themselves.
Where are my Passkeys?
Where are my active sessions?
Where is my login history?
Which device is mine?
A lot of participants struggled with that and the problem is pretty obvious….We have trained people not to trust links in emails.
But some recovery processes still rely heavily on the user clicking one to get to the right place So you probably need another way for people to get there.
For example, if somebody logs into their account after a security alert, show an obvious banner telling them exactly what happened and where they need to go.
Or give them a simple path such as:
Settings → Security → Passkeys
That way somebody who doesn't trust the email can still find the right place themselves.
Finding the Passkey was only half the problem
Finding the Passkey page doesn't necessarily mean the person knows what they are looking at.
One example Alaa showed me was Google's interface showing iCloud Keychain. Participants could see entries there, but some didn't really understand what they represented.
One participant thought a Passkey entry was basically one Passkey that worked across two devices. It took a nudge from the researcher before they realised one of the entries was linked to a device they didn't recognise.
Alaa probably summed the problem up best:
“Users still don't understand what passkeys are and how to manage them.”
And Passkeys syncing across devices makes this even harder.
A Passkey might have originally been created on one device and then synced somewhere else. So just showing the device where it was originally created doesn't necessarily tell the user everywhere that credential can now be used.
Alaa has looked at device information in previous work as well and Things like device identifiers can potentially be spoofed.
So even if the account tells somebody: This login came from an iPhone
The user can look at that and think: I have an iPhone. That must have been me.
When it wasn't.
Nobody has really worked out Passkey recovery yet
I asked Alaa whether part of the problem was simply that the industry hasn't really worked out what good Passkey recovery looks like yet. Her answer was basically yes.
FIDO has guidance around things like Passkey enrolment, authentication and management.
But when Alaa's team looked at it, they couldn't find the same thing for what happens when an attacker has registered a Passkey on somebody else's account.
“For account remediation, definitely no guidance out there. Everyone is just doing their own.”
And you can see that in the research with Google, LinkedIn and PayPal all having very different processes.
Some focus mostly on resetting the password.Others make you manually find the Passkey settings. Some don't clearly explain which sessions need to be removed.
So we have put a lot of effort into standardising how Passkeys should authenticate somebody.
But not really the same effort into:
What do we do when the wrong person registers one?
That's a pretty big gap.
Sometimes deleting everything isn't the right answer either
Another thing participants did was what Alaa called a scorched earth approach.
They weren't confident which Passkey belonged to the attacker so they deleted everything.
For most people that probably sounds like the safest thing to do.
But part of Alaa's research looks specifically at people experiencing intimate partner violence and in those situations things can be a lot more complicated.
If an abusive partner has access to an account and you suddenly remove their access, they know you have discovered it and that can potentially make the situation worse.
So sometimes somebody may want to understand and document what is happening without immediately removing the person.
That's obviously a very specific threat model but the wider point is interesting.
Account recovery doesn't always mean:
See something bad → delete it immediately.
Google has already started changing the process
I asked Alaa whether she had noticed anything change since they completed the research and interestingly she had.
Google's recovery flow now appears to include a Passkey section that wasn't there during the study. She has also noticed Google adding a cooldown period in some cases when a new Passkey is created from another device.
So the new Passkey can't necessarily just be used immediately.
Alaa was very clear though that Google didn't contact them and say these changes were made because of the research so we can't make that direct connection.
They are interesting changes though because they directly touch some of the problems Alaa found such as more Passkey visibility during recovery and more friction around adding a new one.
So what can Identity teams actually do?
I asked Alaa the obvious question.
This research is interesting, but if I'm running Identity for a company, what can I actually go and change?
She was careful here because the team is still researching what the best recovery process should look like, So there isn't a perfect framework yet.
There were though a few obvious things companies could change now.
Tell the user exactly what happened. If a new Passkey was added, say that.
If the alert is about a Passkey, deal with the Passkey. Don't just reset the password.
Don't assume everyone will click the security email. Give them a clear path inside the account.
Give people a checklist. Tell them exactly what needs checking before they are finished.
Give more information about sessions. Help people work out if a session was actually theirs.
The second point sounds almost too basic but Alaa was pretty clear on it.
“If I add a passkey and then you're sending me a notification about a new added passkey, please make sure that I'm actually addressing this concern in whatever remediation tools options you're presenting to me.”
Which is really the whole problem with the false finish.
If the warning is about a Passkey, don't let the user finish the recovery process without dealing with the Passkey.
Alaa's research found people either stopped too early or basically searched through the whole account trying to work out what else they needed to do. A simple checklist would at least tell them when they are actually finished.
The biggest takeaway for me
I don't think the takeaway from Alaa's research is that Passkeys are bad.
It is more that authentication has moved forward very quickly and account recovery hasn't necessarily caught up.We have spent years training users that when something goes wrong: Change your password.
That is becoming less true. There might now be multiple Passkeys. Multiple sessions. Synced credentials. Different Passkey providers.
And potentially another credential sitting on the account that changing the password doesn't touch.
So if you are rolling Passkeys out, there are probably four things worth checking:
If someone maliciously adds a Passkey, does our recovery process actually get the user to remove it?
Could resetting the password make the user think the incident is finished when it isn't?
If somebody refuses to click the security email, can they still easily find everything they need?
Can a normal user actually understand which Passkeys and sessions belong to them?
For me the issue is pretty simple.
We are making authentication much stronger, but if somebody gets the wrong Passkey onto the account we still aren't making it easy enough for a normal person to work out what happened and remove it. That probably needs to catch up pretty quickly.
Research and Resources
Alaa shared the following resources around the research: