> ## Content Index
> Fetch the complete content index at: https://corti.com/llms.txt
> Use this file to discover other available public pages before exploring further.

# Why My Email Accounts Now Require a YubiKey
- URL: https://corti.com/why-my-email-accounts-now-require-a-yubikey/
- Published: 2026-10-28T09:04:02.000Z
- Updated: 2026-10-28T09:04:02.000Z
- Author: Sascha Corti

I have moved every one of my email accounts to hardware security keys. Signing in now requires a YubiKey: plugged into USB or tapped against the phone over NFC. SMS codes, authenticator-app codes and push approvals are no longer my second factor on those accounts.

The cost is real. I have to carry a physical key at all times, and a new laptop or phone means touching the key before I can read my mail. This post explains why I think that trade-off is worth it for email specifically, how a hardware key differs from the alternatives, and the one operational trick that makes the setup survivable: **register two keys, and lock one of them away**.

## Why email is the account worth over-protecting

Email is the recovery channel for almost everything else. A "Forgot password?" link on most sites sends a reset link or code to the registered address. Whoever controls the inbox can therefore reset the password of every account that does not add its own independent second factor.

That makes the mailbox a root of trust, not just a place where messages live. Compromising it typically gives an attacker:

- **Password resets** for shopping, social, cloud and utility accounts registered to that address.
- **Email-based one-time codes**, which many services still accept as a second factor or as a recovery method.
- **Account inventory**: years of sign-up confirmations, invoices and notifications showing exactly which services exist and where to aim next.
- **Trusted identity** for social-engineering contacts, colleagues and support desks from a real address.

Hardening every downstream account helps, but the cheapest high-leverage control is to make the root very hard to take. That is the account where I accept the most friction.

## What the YubiKey actually does: FIDO2 and WebAuthn

A YubiKey used for sign-in is a FIDO2 authenticator, and the browser talks to it through the W3C WebAuthn API. The security comes from three properties that no shared-secret method has.

1. **Asymmetric keys, generated per site.** At registration the key generates a fresh key pair for that one relying party. The site stores only the public key. There is no shared secret on the server that a database breach could leak and replay.
2. **Challenge-response.** At sign-in the server sends a random challenge. The authenticator signs it with the private key after a touch (user presence) and, if configured, a PIN or biometric (user verification). Each signature is valid for that challenge only, so nothing reusable crosses the wire.
3. **Origin binding.** Every credential is scoped to a relying party ID such as `google.com`. The browser, not the user, checks the page's origin, puts it into `clientDataJSON` together with the challenge, and the authenticator data carries a hash of the RP ID. A look-alike domain cannot request or obtain a signature for the real site.

![](https://corti.com/content/images/2026/10/graphic.png)

The proxy can relay every pixel of the real page, but the browser reports the proxy's origin, so the key has no credential to use and no signature exists to forward.

The third property is the one that matters most in practice. NIST's 2024 supplement to SP 800-63B defines an authenticator as phishing-resistant when it binds its output to a communication channel or a verifier name, and FIDO's domain binding meets that definition ([Yubico summary of the NIST guidance](https://www.yubico.com/blog/new-nist-guidance-on-passkeys-key-takeaways-for-enterprises/?ref=corti.com)).

On a YubiKey, the private key is generated and used inside the key's secure element and is not exportable. That is the hardware part of the story, and it is what separates a security key from software-based credentials.

## How a hardware key compares to the alternatives

Only origin-bound FIDO credentials stop real-time phishing; among those, only a hardware key keeps the private key on one dedicated, non-exportable device. Everything else either hands the user a secret they can be tricked into typing, or lets the credential live wherever a cloud account syncs it.

| Method                          | What proves possession                   | Stops adversary-in-the-middle phishing                               | Where the secret lives                                  | Main residual risk                                                        |
| ------------------------------- | ---------------------------------------- | -------------------------------------------------------------------- | ------------------------------------------------------- | ------------------------------------------------------------------------- |
| Password only                   | Nothing                                  | No                                                                   | Your memory and the server's hash                       | Phishing, reuse, credential stuffing                                      |
| Password manager                | Nothing (a vault, not a factor)          | Partly: autofill refuses look-alike domains, but you can still paste | Encrypted vault, usually synced                         | The vault account; manual copy-paste on a phishing page                   |
| Authenticator app (TOTP)        | Seed on your phone                       | No: the 6-digit code is relayed within its validity window           | Shared seed on phone and server                         | Relay phishing, seed theft, seed stored in the same vault as the password |
| Push approval                   | Your phone                               | No: the prompt is triggered by the attacker's relayed login          | Phone app + vendor backend                              | Relay phishing, prompt fatigue                                            |
| Synced passkey                  | Any device signed in to the sync account | Yes                                                                  | Platform or password-manager keychain, synced via cloud | Takeover of the sync account; key material on every synced device         |
| Hardware security key (YubiKey) | One physical token                       | Yes                                                                  | Secure element on the key, not exportable               | Loss of the key, which the second key covers                              |

**Authenticator apps** were a large step up from SMS, but TOTP is still a shared secret turned into a short code that the user types. Reverse-proxy phishing kits such as Evilginx sit between the victim and the real login page, forward the password and the code as they are entered, and keep the resulting session cookie ([Sophos](https://www.sophos.com/en-us/blog/stealing-user-credentials-with-evilginx?ref=corti.com)). The user did everything right except look closely at the domain.

**Password managers** are excellent at producing unique passwords and at refusing to autofill on the wrong domain. That domain check is a real anti-phishing control, but it is advisory: when autofill "doesn't work", a hurried user copies the password manually. Storing TOTP seeds in the same vault also collapses two factors into one compromise.

**Hardware keys** remove the human decision from the domain check. The browser binds the request to the origin, and the key will not produce a signature the attacker can use elsewhere. There is no code to read out, forward or paste.

## A passkey is the same technology, minus the dedicated "what I have"

A passkey is a FIDO2/WebAuthn credential. So is the credential on my YubiKey. Same registration ceremony, same challenge-response, same origin binding, same phishing resistance. The difference is only where the private key lives and whether it can move.

- **Synced passkey** (iCloud Keychain, Google Password Manager, a third-party password manager): the private key is encrypted and replicated through a cloud account to every device signed in to it. The device unlock (Face ID, fingerprint, PIN) gates its use.
- **Device-bound passkey** (a YubiKey, or a platform authenticator that does not sync): the private key is generated on one piece of hardware and never leaves it. A YubiKey can store passkeys itself; keys on firmware 5.7 or later hold up to 100 discoverable credentials, up from 25 ([Yubico](https://yubico.com/blog/empowering-enterprise-security-at-scale-with-new-product-innovations-yubikey-5-7-and-yubico-authenticator-7?ref=corti.com)).

To be precise about factors: in the usual MFA accounting, the passkey credential itself counts as "something you have", with the biometric or PIN as the second factor. But for a synced passkey, the "thing" is a copy that any device enrolled in the sync account can hold. What I actually possess is a cloud account, not an object. NIST reflects this in its assurance levels: synced passkeys can meet AAL2, while device-bound passkeys in dedicated hardware can reach AAL3 ([Yubico on the NIST supplement](https://www.yubico.com/blog/new-nist-guidance-on-passkeys-key-takeaways-for-enterprises/?ref=corti.com)).

So a passkey on my phone removes phishing, but it does not give me a physical factor that exists exactly once. A YubiKey does.

For email there is a second, structural reason to prefer hardware. The account that syncs my passkeys is often the email account itself (or is recovered through it). Protecting the mailbox with a credential that lives inside the mailbox provider's sync fabric is a circular dependency. A hardware key breaks that loop: its trust anchor sits on my keyring and in a safe, not in any account.

## The trick: two keys, one of them locked away

A hardware key that exists exactly once is also a single point of failure. Lose it, break it, or drop it in the lake, and the strongest possible sign-in becomes the most effective possible lockout. The fix is redundancy: **every account gets two keys registered, and only one of them leaves the house.**

- **Primary key** on my keyring, used daily over USB-C or NFC.
- **Backup key** registered to exactly the same accounts, stored in a safe and never carried.

Apple builds this into the product: Security Keys for Apple Account requires at least two FIDO Certified keys, allows up to six, and warns that losing all trusted devices and keys can lock you out permanently ([Apple Support](https://support.apple.com/en-us/102637?ref=corti.com)). Google's Advanced Protection Program accepts two passkeys or security keys as primary and secondary factors ([Google](https://landing.google.co.jp/intl/en%5Fca/advancedprotection/faq?ref=corti.com)). Proton allows up to four security keys and says multiple keys reduce lockout risk ([Proton](https://proton.me/support/2fa-security-key?ref=corti.com)). A Microsoft account can save a passkey directly to a physical security key ([Microsoft Support](https://support.microsoft.com/topic/e92cd3e0-11fa-4630-a5ea-3ccc0396b3d9?ref=corti.com)). Where a provider does not enforce a second key, I register two anyway.

![](https://corti.com/content/images/2026/10/yubikey.png)

The operational rules that make this work:

1. **Enrol both keys in the same session.** The backup only helps if it is registered everywhere the primary is. Adding a new account means taking the backup out of the safe, registering both, and putting it back.
2. **Keep an inventory.** A short list of which accounts each key is registered on makes the yearly check ("does the backup still sign in everywhere?") quick.
3. **Set a FIDO2 PIN on both keys.** A found key without the PIN is far less useful for accounts that require user verification.
4. **Buy compatible hardware.** Both keys need connectors for every device I sign in from; USB-C plus NFC covers Macs and iPhones.
5. **When the primary is lost:** sign in with the backup, revoke the lost key on every account, and register a replacement immediately. Until then I am running on one key, which is exactly the state this setup exists to avoid.

## The weak links that remain

An account is only as strong as its weakest accepted sign-in or recovery path. Adding a YubiKey while leaving older methods enabled mostly adds convenience for the attacker, who simply picks the weaker option. After enrolling the keys, check every account for these:

- **Fallback 2FA methods.** If TOTP or SMS stays enabled next to the key, a phishing kit just asks for that instead. Proton, for example, offers the authenticator-app tab at sign-in when that method is also enabled ([Proton](https://proton.me/support/2fa-security-key?ref=corti.com)). Remove every weaker second factor the provider lets you remove.
- **Trusted devices.** Some ecosystems accept an already signed-in device instead of a key. With Apple's security keys, a trusted Apple device brought near the new device is an accepted alternative ([Apple Support](https://support.apple.com/en-us/102637?ref=corti.com)). That makes the passcode of every trusted device part of the account's security.
- **One-time security codes.** Google's Advanced Protection lets Workspace admins allow one-time codes generated with a key or passkey for platforms without key support, and Google itself notes this weakens security ([Google Workspace Admin Help](https://knowledge.workspace.google.com/admin/security/advanced-protection-program-faq?ref=corti.com)).
- **Recovery codes.** They bypass the key by design. Keep them offline, for example printed and stored with the backup key, not in a synced note.
- **App passwords and legacy protocols.** Where a provider still offers app-specific passwords for IMAP/SMTP clients, those authenticate without the second factor. Revoke them and use clients that support modern sign-in.
- **Stolen sessions.** FIDO2 protects the sign-in ceremony, not a session cookie that infostealer malware lifts from an already logged-in browser. Endpoint hygiene still matters.

## Is the hassle worth it?

For email, yes. The friction is concrete and small: a key on the keyring, a touch on every new device, a trip to the safe when I add an account. The benefit is that the account which can reset almost every other account no longer accepts anything that can be phished, relayed or typed into the wrong page.

Passkeys are the right default for most people and most accounts, and they share the same cryptographic core. For the root of my digital identity I want one more property: the credential exists on a specific object I hold, plus a second one I have locked away.

## Sources

- [About Security Keys for Apple Account](https://support.apple.com/en-us/102637?ref=corti.com) (Apple Support)
- [Advanced Protection Program FAQ](https://landing.google.co.jp/intl/en%5Fca/advancedprotection/faq?ref=corti.com) (Google)
- [Advanced Protection Program FAQ for admins](https://knowledge.workspace.google.com/admin/security/advanced-protection-program-faq?ref=corti.com) (Google Workspace Admin Help)
- [Set up 2FA with a security key](https://proton.me/support/2fa-security-key?ref=corti.com) (Proton)
- [New NIST guidance on passkeys](https://www.yubico.com/blog/new-nist-guidance-on-passkeys-key-takeaways-for-enterprises/?ref=corti.com) (Yubico)
- [YubiKey 5.7 and Yubico Authenticator 7](https://yubico.com/blog/empowering-enterprise-security-at-scale-with-new-product-innovations-yubikey-5-7-and-yubico-authenticator-7?ref=corti.com) (Yubico)
- [Stealing user credentials with evilginx](https://www.sophos.com/en-us/blog/stealing-user-credentials-with-evilginx?ref=corti.com) (Sophos)
- [Web Authentication Level 2: Relying Party Identifier](https://www.w3.org/TR/webauthn-2/?ref=corti.com#relying-party-identifier) (W3C)