Scams & Phishing News Google And Microsoft Warn Passkeys May Not Stop Hackers

[Brownie2019]

Content source

https://www.forbes.com/sites/zakdoffman/2026/05/11/google-and-microsoft-warn-passkeys-may-not-stop-hackers/

Passkeys are supposed to replace passwords and stop phishing attacks. But Google and Microsoft warn that passkeys alone are not enough if weaker recovery methods remain attached to accounts. “Each account is only as secure as its weakest credential,” Microsoft says, warning that passwords and SMS recovery options can become a new attack surface even after passkeys are deployed.

“Passkeys are an easier and safer way to access online accounts compared to passwords,” Google says, “and even traditional multi-factor methods.” But passkeys are not 100% safe on their own. In a new warning, Google says “even when you normally use a passkey, it’s important to secure your account with two-step verification (2SV)." You need this in case “someone tries to impersonate you and claims to have lost your passkey."

Read more:

Google And Microsoft Warn Passkeys May Not Stop Hackers

Your passkey alone is not enough — here's what you must do to secure your accounts.

www.forbes.com

 

[Bot]

Read more:

Google And Microsoft Warn Passkeys May Not Stop Hackers

Your passkey alone is not enough — here's what you must do to secure your accounts.

www.forbes.com

Passkeys do reduce phishing risk very effectively, but the quoted point is reasonable: account security is usually limited by the weakest recovery path, not just the primary sign-in method.

What passkeys improve

• They are resistant to typical phishing sites because the credential is tied to the legitimate site/app.
• They remove password reuse and many credential-stuffing attacks.
• They are generally safer and easier for most users than passwords alone.

What they do not automatically fix

If an account still allows weaker fallback methods, those can become the target instead:

• SMS recovery, which can be exposed to SIM-swap or number-recycling issues
• Email-based recovery, if the email account itself is weak or already compromised
• Knowledge-based recovery questions, which are often guessable or obtainable
• Legacy password login paths that remain enabled
• Support-driven account recovery processes that rely on weak identity checks

So the general principle is correct: adding passkeys does not magically secure an account if weak recovery options remain attached.

About the “passkeys are not enough” wording

That needs a bit of nuance.

Passkeys are a strong authentication method. The bigger issue is usually account recovery design, not that passkeys themselves are weak. In practice, if a service allows an attacker to bypass the passkey with a much weaker recovery route, the service has reduced the benefit of passkeys.

Practical takeaway

For users, the best approach is:

• Use passkeys where supported
• Remove or minimize weaker fallback methods if the service allows it
• Secure the recovery email account just as strongly
• Prefer app-based or hardware-based second factors over SMS where possible
• Review account recovery options and backup codes
• Keep device security strong, since passkeys depend heavily on trusted devices and platform security

One caution about the article

I cannot verify the full context of the Forbes piece from the quote alone, so I would be careful about any headline-level framing. But the core security idea is sound: passkeys significantly improve login security, while weak recovery paths can still undermine the account.

Bottom line

Passkeys are still one of the best improvements to consumer authentication in years. They are not “defeated” by default, but they are only as effective as the surrounding recovery and fallback mechanisms.

 

[Wrecker4923]

In a new warning, Google says “even when you normally use a passkey, it’s important to secure your account with two-step verification (2SV)." You need this in case “someone tries to impersonate you and claims to have lost your passkey."

The best recovery method is to use your account passkey on a different device to complete a recovery step.

As a back-up, Microsoft says a process that pushes users to provide ID and a face scan is best. “As NIST recommends, high-assurance recovery requires government-issued ID and biometric verification.”

Microsoft’s advice is aimed at enterprise users — Google’s primarily at home users.

Google tells users to add 2SV to “prevent hackers from accessing your account with an additional layer of security." But given an attacker can use Google’s account recovery process, pretending to be you and claiming a passkey has been lost, the form of 2SV becomes more critical than ever. There are two types you should use. Google Prompts and an Authenticator (which can be an app on your phone).

So, the account recovery path is currently typically your email and your 2FA, right? So, make sure your email account is recoverable, and your "2FA" is secure (FIDO2 > TOTP authenticator > Another Email > Recovery code).

 

[oldschool]

2FA is a bit different for Google users enrolled in Advanced Protection.
Gemini says:

Yes, Google Advanced Protection uses 2-Step Verification (2SV), but it significantly restricts the methods you can use to ensure maximum security. While standard Google accounts allow verification via SMS codes or app-based prompts, Advanced Protection requires the use of a physical security key or a passkey for sign-in. [1, 2, 3, 4]

Key Differences in Verification Methods
When you enroll in Advanced Protection, certain traditional 2-factor methods are disabled to prevent phishing and unauthorized access: [1, 2, 3, 4]

• Security Keys Required: You must use a FIDO-compliant physical security key (like the Titan Security Key) or a passkey stored on your device.
• Disabled Methods: Standard methods like SMS codes, phone call codes, and traditional Google Authenticator codes are completely disabled as sign-in options.
• Account Recovery: If you lose your keys, the recovery process is much stricter and takes several days to verify your identity, preventing hackers from using social engineering to regain access to your account. [1, 2, 3, 4, 5, 6, 7]

Enrollment Requirements
To set up Advanced Protection, Google recommends having the following ready:

• Primary and Backup Keys: You are encouraged to register at least two security keys (one for daily use and one as a backup kept in a safe place).
• Passkeys: You can also use your phone’s built-in screen lock (fingerprint, face, or PIN) as a passkey for enrollment. [1, 2, 3]

Generally, I dislike regular 2FA and never enable it in accounts but it's unavoidable in certain "on access" situations.

 

[cartaphilus]

In a totally unrelated related way a proctologist friend of mine told me that your "starfish kiss" pattern is unique to a person. I don't know if it's true or not but if true then that would totally revolutionize TSA check ins......oh and of course you are no longer limited to finger prints, palm scans or iris scans.



"Sir you have been randomly selected for enchanted screening, please bend over so we can confirm your aprint"

 

[Victor M]

Generally, I dislike regular 2FA

Are you avoiding it because of the inconvenience? Most security do have some inconvenience to it.

 

[lokamoka820]

2FA is a bit different for Google users enrolled in Advanced Protection.
Gemini says:


Generally, I dislike regular 2FA and never enable it in accounts but it's unavoidable in certain "on access" situations.

Although I also don't like unrecoverable security features in the event that I lose access to the device or app, I started using 2FA this year after discovering that I could back up the 2FA codes seeds.

 

[oldschool]

Are you avoiding it because of the inconvenience? Most security do have some inconvenience to it.

I've enabled Google's Advanced Protection since it was introduced but I'm not convinced about the value of typical 2FA. Everything is exploitable one way or another. I choose the level of inconvenience that I find suitble.

 

[Victor M]

but I'm not convinced about the value of typical 2FA

I think that if one can avoid being low hanging fruit, then one should have 2FA. At least you avoid credential stuffing attacks. Different security require different hacks. Your choice of Graffene OS shows you are aware of cell phone based 2FA hacks. But now that you have Graphene OS, don't you feel safer ? I think you can run Google Authenticator / MS Authenticator. Everything is exploitable as you say, but some hacks require more effort, more knowhow, more equipment.

 

[Victor M]

AI ANSWER. But it is Good and Informative. Everything is exploitable just like @oldschool said. Here is 8 attacks on 2FA.


Q: I have heard that there are some attacks that can attack 2FA protected accounts. How do those work?


Thought for 12s
Yes. 2FA helps a lot, but it does not make accounts immune. Most “2FA bypass” attacks do not break cryptography. They attack the user, device, session, recovery path, or login flow.

The main ones:

1. Real-time phishing / adversary-in-the-middle​

This is the big one.

The attacker creates a fake login page that looks like the real site. You enter:

1. username
2. password
3. 2FA code or approve a push prompt

But the fake site is acting as a relay to the real site in real time.

So when you type the TOTP code, the attacker immediately submits it to the real service. If login succeeds, the attacker gets the authenticated session cookie.

Key point: the attacker does not need to know your future 2FA codes. They only need to use the current one quickly.

This works against:

• SMS codes
• email codes
• authenticator-app TOTP codes
• push approvals, if the victim approves the attacker’s login

It is much weaker against:

• FIDO2/WebAuthn security keys
• properly implemented passkeys

because those are bound to the real website origin. A fake domain cannot usually get a valid authentication response for the real domain.

2. Session-cookie theft​

After you log in successfully, the website gives your browser a session cookie. That cookie proves you are already authenticated.

Malware, a malicious browser extension, infostealer malware, or local compromise can steal that session cookie. The attacker then imports/reuses it and appears logged in without needing the password or 2FA code.

This is why 2FA does not fully protect a compromised endpoint.

Defenses:

• avoid browser extensions you do not absolutely need
• use separate browser profiles for sensitive accounts
• use phishing-resistant MFA
• log out of high-value accounts when done
• revoke sessions after compromise
• harden the endpoint, not only the account

3. MFA push bombing / prompt fatigue​

The attacker already has the password. They repeatedly try to log in, causing push notifications:

“Approve sign-in?”

Eventually the victim clicks approve to make it stop, or because they think it is a glitch.

This is common with push-based MFA.

Better systems use:

• number matching
• location/device display
• requiring the user to type a number shown on the login screen
• blocking repeated push attempts
• phishing-resistant security keys instead of push approvals

4. SIM swap / phone-number takeover​

If SMS is used for 2FA, the attacker can try to take over the victim’s phone number by convincing the carrier to move the number to a new SIM/eSIM.

Then SMS codes go to the attacker.

This is why SMS 2FA is considered one of the weaker forms of 2FA. It is still better than no 2FA, but it is not strong protection against targeted attackers.

5. Account recovery bypass​

Sometimes the 2FA is strong, but the recovery path is weak.

Example:

• “Forgot password?”
• recovery email compromised
• phone number taken over
• security questions guessed
• helpdesk/social engineering
• backup codes stolen
• old logged-in device still trusted

The attacker does not defeat 2FA. They bypass it by using account recovery.

For important accounts, recovery mechanisms need to be protected as carefully as the main login.

6. OAuth / consent attacks​

Instead of stealing your password, the attacker tricks you into granting a malicious app access to your account.

For example, a fake “document viewer” or “security scanner” asks for permission to read email, contacts, files, or cloud storage.

You may successfully pass 2FA, but then you authorize the attacker’s app. After that, the attacker uses the granted token/API permission.

This is common in Microsoft/Google cloud environments, but the general idea applies elsewhere too.

7. Compromised trusted device​

Many services have “remember this device” or “trusted browser” settings.

If the attacker gets access to a device/browser that is already trusted, they may not need to pass 2FA again.

This can happen through:

• stolen laptop
• remote-access malware
• browser profile theft
• backup extraction
• cloud-synced browser data
• compromised password manager session

8. Weak backup codes​

Many 2FA systems provide backup codes. If those are stored in plaintext in email, cloud notes, screenshots, or a Downloads folder, the attacker can use them.

Backup codes are effectively alternate passwords. They need to be printed, stored offline, or kept in a highly protected password manager.

Ranking of 2FA strength​

From weaker to stronger:

1. Email code — weak if email is compromised
2. SMS code — vulnerable to SIM swap and carrier abuse
3. TOTP authenticator app — good, but phishable in real time
4. Push approval — convenient, but vulnerable to prompt fatigue unless number matching is used
5. FIDO2/WebAuthn security key or passkey — strongest common option; resistant to ordinary phishing because it is bound to the real site domain

The main takeaway: 2FA is strongest when it is phishing-resistant. TOTP is good against password reuse and credential stuffing, but it does not fully stop a real-time phishing proxy. For high-value accounts, use FIDO2 security keys or passkeys, disable SMS recovery where possible, protect recovery email, and periodically revoke old sessions.

==========================================
As you all know, I shamelessly promote FIDO / Yubikeys. Only costs $25 each. Cheaper than an AV subscription. Lasts years.
Join Google Advanced Protection. Sign up with Yubikey. Use "Sign in with Google" everywhere. You get 2FA protection everywhere where Google Sign-in is supported.

 

[HarborFront]

AI ANSWER. But it is Good and Informative. Everything is exploitable just like @oldschool said. Here is 8 attacks on 2FA.


Q: I have heard that there are some attacks that can attack 2FA protected accounts. How do those work?


Thought for 12s
Yes. 2FA helps a lot, but it does not make accounts immune. Most “2FA bypass” attacks do not break cryptography. They attack the user, device, session, recovery path, or login flow.

The main ones:

1. Real-time phishing / adversary-in-the-middle​

This is the big one.

The attacker creates a fake login page that looks like the real site. You enter:

1. username
2. password
3. 2FA code or approve a push prompt

But the fake site is acting as a relay to the real site in real time.

So when you type the TOTP code, the attacker immediately submits it to the real service. If login succeeds, the attacker gets the authenticated session cookie.

Key point: the attacker does not need to know your future 2FA codes. They only need to use the current one quickly.

This works against:

• SMS codes
• email codes
• authenticator-app TOTP codes
• push approvals, if the victim approves the attacker’s login

It is much weaker against:

• FIDO2/WebAuthn security keys
• properly implemented passkeys

because those are bound to the real website origin. A fake domain cannot usually get a valid authentication response for the real domain.

2. Session-cookie theft​

After you log in successfully, the website gives your browser a session cookie. That cookie proves you are already authenticated.

Malware, a malicious browser extension, infostealer malware, or local compromise can steal that session cookie. The attacker then imports/reuses it and appears logged in without needing the password or 2FA code.

This is why 2FA does not fully protect a compromised endpoint.

Defenses:

• avoid browser extensions you do not absolutely need
• use separate browser profiles for sensitive accounts
• use phishing-resistant MFA
• log out of high-value accounts when done
• revoke sessions after compromise
• harden the endpoint, not only the account

3. MFA push bombing / prompt fatigue​

The attacker already has the password. They repeatedly try to log in, causing push notifications:


Eventually the victim clicks approve to make it stop, or because they think it is a glitch.

This is common with push-based MFA.

Better systems use:

• number matching
• location/device display
• requiring the user to type a number shown on the login screen
• blocking repeated push attempts
• phishing-resistant security keys instead of push approvals

4. SIM swap / phone-number takeover​

If SMS is used for 2FA, the attacker can try to take over the victim’s phone number by convincing the carrier to move the number to a new SIM/eSIM.

Then SMS codes go to the attacker.

This is why SMS 2FA is considered one of the weaker forms of 2FA. It is still better than no 2FA, but it is not strong protection against targeted attackers.

5. Account recovery bypass​

Sometimes the 2FA is strong, but the recovery path is weak.

Example:

• “Forgot password?”
• recovery email compromised
• phone number taken over
• security questions guessed
• helpdesk/social engineering
• backup codes stolen
• old logged-in device still trusted

The attacker does not defeat 2FA. They bypass it by using account recovery.

For important accounts, recovery mechanisms need to be protected as carefully as the main login.

6. OAuth / consent attacks​

Instead of stealing your password, the attacker tricks you into granting a malicious app access to your account.

For example, a fake “document viewer” or “security scanner” asks for permission to read email, contacts, files, or cloud storage.

You may successfully pass 2FA, but then you authorize the attacker’s app. After that, the attacker uses the granted token/API permission.

This is common in Microsoft/Google cloud environments, but the general idea applies elsewhere too.

7. Compromised trusted device​

Many services have “remember this device” or “trusted browser” settings.

If the attacker gets access to a device/browser that is already trusted, they may not need to pass 2FA again.

This can happen through:

• stolen laptop
• remote-access malware
• browser profile theft
• backup extraction
• cloud-synced browser data
• compromised password manager session

8. Weak backup codes​

Many 2FA systems provide backup codes. If those are stored in plaintext in email, cloud notes, screenshots, or a Downloads folder, the attacker can use them.

Backup codes are effectively alternate passwords. They need to be printed, stored offline, or kept in a highly protected password manager.

Ranking of 2FA strength​

From weaker to stronger:

1. Email code — weak if email is compromised
2. SMS code — vulnerable to SIM swap and carrier abuse
3. TOTP authenticator app — good, but phishable in real time
4. Push approval — convenient, but vulnerable to prompt fatigue unless number matching is used
5. FIDO2/WebAuthn security key or passkey — strongest common option; resistant to ordinary phishing because it is bound to the real site domain

The main takeaway: 2FA is strongest when it is phishing-resistant. TOTP is good against password reuse and credential stuffing, but it does not fully stop a real-time phishing proxy. For high-value accounts, use FIDO2 security keys or passkeys, disable SMS recovery where possible, protect recovery email, and periodically revoke old sessions.

==========================================
As you all know, I shamelessly promote FIDO / Yubikeys. Only costs $25 each. Cheaper than an AV subscription. Lasts years.
Join Google Advanced Protection. Sign up with Yubikey. Use "Sign in with Google" everywhere. You get 2FA protection everywhere where Google Sign-in is supported.

But then there's still no access of phone using a physical security key during start up. So access is still the phone's weakest point

 

[Victor M]

But then there's still no access of phone using a physical security key during start up. So access is still the phone's weakest point

Are you thinking about using Google Authenticator / MS Authenticator scenario ? If you are, I am not using either, I use Google Sign-in for web sites and insert Yubikey into my laptop's usb slot.

 

[HarborFront]

Are you thinking about using Google Authenticator / MS Authenticator scenario ? If you are, I am not using either, I use Google Sign-in for web sites and insert Yubikey into my laptop's usb slot.

I'm referring to phone use case

Like when after pressing the power on button the phone starts up and requires one to key in password before the phone can be accessed

Password/pattern/biometric scan etc signatures are all stored on the device. The physical security key is separately owned by you.

Here, no physical security key can be used. I believe if one loses the physical security key no recovery is possible even by the manufacturer since the physical key belongs to you.

Physical security key is mainly used to access apps/websites after the phone has started. I believe PC/laptop behaves similarly

 

[Victor M]

I believe Windows PC/laptop behaves similarly

Correction if I may. PC can use Yubikey to startup - there is a free Yubico Yubikey Login app. Also Windows itself can use Yubikey to login IF you have Entra ID - the $30/month/PC option.

 

[Wrecker4923]

They attack the user, device, session, recovery path, or login flow.

The main ones:

Another one is no effective rate-limiting/account reset on the OTP-based 2FAs against brute-forcing. Microsoft had this problem before. I’ve seen it (or evidence of it) with TOTP, email, and push authenticators that include OTP backup.

Push authenticators without OTP backup and FIDO2 don’t have this problem. Push authenticator has fatique attack problem.

Passkeys and FIDO2 2FA are what we should aim for.

 

[Victor M]

Password/pattern/biometric scan etc signatures are all stored on the device.

I am not aware of any security deficiency of password/patter/biometric logins of phones. Wjy do I want a Yubikey for phone login? Attacker can shoulder surf your password/pattern login, but biometric login factor is 'something that you are'. If you have biometric login on your phone, it is safer than my iphone.

 

[cartaphilus]

I've enabled Google's Advanced Protection since it was introduced but I'm not convinced about the value of typical 2FA. Everything is exploitable one way or another. I choose the level of inconvenience that I find suitble.

Now I wonder what will overrule the other:

1) enable google account next of kin with time out of 6 months
2) use the advanced 2FA account method and lose a key or both keys and thus access to your account.

Assuming every other device is logged out and you unable to log in then after 6 months eventuality 1 is executed and your next of Kin accounts will receive your credentials.

 

[HarborFront]

Correction if I may. PC can use Yubikey to startup - there is a free Yubico Yubikey Login app. Also Windows itself can use Yubikey to login IF you have Entra ID - the $30/month/PC option.

According to AI

Search Assist

Yes, you can use a YubiKey to log into a Windows PC, but it requires specific setup and is typically supported for local accounts, not Microsoft accounts. Make sure to install the Yubico Login for Windows software to enable this feature.

 

[simmerskool]

Yes, you can use a YubiKey to log into a Windows PC, but it requires specific setup and is typically supported for local accounts, not Microsoft accounts. Make sure to install the Yubico Login for Windows software to enable this feature.

Yubico Login for Windows: Requirements -- "Systems that are running any of the following operating systems, fully updated and for as long as they are supported by Microsoft: Windows 11" (just learned according to chatgpt 70% of windows users now running win11 -- I thought there were more win10 users)

Yubico Support Guest Portal

support.yubico.com

 

[oldschool]

MS's warning is quite different from Google's. G's only applies to common 2FA and not to Advanced Protection.

Google and Microsoft warn that passkeys alone are not enough if weaker recovery methods remain attached to accounts.

Advanced Protection uses a passkey, either the device login, PIN, fingerprint, etc or a passkey on a separate hardware device. 2FA isn't availble with AP and AP doesn't allow weak recovery methods like accounts with regular 2FA do.