Passkeys for Email: Complete Guide to Secure Sign-In, Recovery, Devices, and Business Rollout Across Gmail and Outlook

Control of a mailbox is control of nearly every other account attached to it, which is why cyberattackers spend so much effort collecting email passwords. A reusable secret typed into a convincing counterfeit page hands over password resets, session recovery, and the ability to speak as the account owner. Passkeys for email target that economic incentive directly by removing the reusable secret from the exchange.

The shift is already mainstream. According to the FIDO Alliance's State of Passkeys 2026, an estimated 5 billion passkeys are now in active use worldwide, with 90% of surveyed consumers aware of the credential type and 75% having enabled one on at least one account.

Scale alone settles no operational question. Security teams still decide where credentials live, how employees recover access after losing a phone, and which cyber threats survive the move away from passwords.

This guide covers:

• How passkeys for email differ from passwords and phishable multifactor methods;
• How registration, challenge signing, and provider verification work for passkeys for email;
• Which account-takeover paths passkeys for email reduce and which remain untouched;
• How to create passkeys for email in Gmail, Outlook, and other providers;
• Where passkeys for email are stored, how they sync, and how hardware keys fit;
• How recovery, migration, and troubleshooting work when a device holding passkeys for email is lost;
• How businesses roll out passkeys for email across an employee population;
• Which privacy, availability, and usability limits apply to passkeys for email.

Credential theft still opens most inboxes, and a stolen password remains the cheapest route in. Adaptive Security turns every blocked phishing attempt into targeted practice for the employee it reached.

Book a demo

What Are Passkeys for Email and How Do They Differ From Passwords?

Passkeys for email are passwordless credentials that let users sign in with a cryptographic key pair stored on a device or passkey provider. The private key stays protected and signs a login challenge, while the email service stores the corresponding public key to verify the signature. Users unlock the credential with a fingerprint, face scan, device PIN, or security-key touch, which places a passkey in a different category from passwords, one-time codes, and traditional two-step verification.

Passkeys for Email Versus Passwords

The central difference between passkeys for email and passwords is where the secret lives. A password is a memorized string that users type into an email sign-in page for the service to verify. A passkey is a FIDO credential generated for one email account and one domain, so the service never receives the private key and the user never types it into a website.

Passkeys use public-key cryptography, also called asymmetric cryptography. During registration, the authenticator creates two mathematically related keys:

• Private key: The secret portion stored by the device or passkey provider, which signs a unique login challenge without being disclosed to the email service;
• Public key: The matching portion sent to the email service, which uses it to verify signatures created by the private key even though the public key cannot reconstruct its counterpart.

This arrangement removes the shared secret that makes passwords attractive to cyberattackers. A stolen email password can be tested against other services or entered into a counterfeit login page, whereas a passkey is bound to the legitimate relying party, meaning the email domain involved in authentication. A fake site cannot obtain a valid signature for the real service because the authenticator checks the site identity before releasing one.

NIST's 2025 Digital Identity Guidelines classify passwords and manually entered one-time passwords as methods that lack phishing resistance, while WebAuthn can provide verifier-name binding. That distinction matters for email because control of an inbox often enables password resets, session recovery, and impersonation of the account owner.

A passkey also leaves the device's unlock method in place. Face recognition, a fingerprint, a PIN, or a local password activates the authenticator rather than becoming the credential sent to the email provider. Devices normally process biometric data locally, and the email service receives only proof that the user authorized the private-key operation.

Passkeys for Email Versus Phishable MFA

Passkeys for email and multifactor authentication (MFA) overlap without being identical concepts. Traditional MFA commonly adds a second step to a password, such as a six-digit authenticator-app code, an SMS code, a push approval, or a hardware token. A passkey replaces the password itself with a cryptographic credential and uses a local unlock action to authorize it.

A one-time code is a short-lived secret that the user reads and manually enters, which means a cyberattacker can intercept or relay that entry through a phishing page in real time. A passkey exposes no reusable code at all. The authenticator signs the specific challenge issued by the legitimate email service, and the signature is tied to that service's domain.

Traditional two-step verification stops some stolen-password cyberattacks, yet it keeps the password in the workflow and often depends on a phishable second factor. Passkeys for email remove the password and bind approval to the legitimate relying party, so a passkey can supply phishing-resistant authentication on its own. An organization's identity policy, regulatory framework, or risk model can still require additional controls on top of it.

The terms behind this process describe different layers of the same system:

• WebAuthn: A web API that lets a browser or application register and use public-key credentials with an online service, managing the website-facing portion of passkey authentication;
• FIDO2: The broader open-standard family that combines WebAuthn with CTAP to support passwordless and phishing-resistant authentication;
• CTAP: The Client to Authenticator Protocol, which governs communication between a browser or operating system and an external authenticator such as a security key or a phone acting as the credential device;
• Authenticator: The component that creates, stores, and uses the private key, whether a phone, laptop, browser credential manager, hardware security key, or another approved device;
• Passkey provider: The operating system, browser, or third-party credential manager responsible for creating and managing passkeys, which can store one locally, sync it across a user's devices, or provide access to a compatible external authenticator;
• Relying party: The service requesting authentication, such as an email provider, which stores the public key and verifies the signed challenge.

In practical terms, WebAuthn gives the email website a way to request a passkey, FIDO2 defines the overall authentication model, and CTAP connects the requesting device to an authenticator that performs the private-key operation. This separation lets an email service support passkeys without receiving biometric information or maintaining a database of reusable passwords.

The distinction matters when employees reach business email from several devices. Security teams should evaluate whether the email platform supports passkeys for email, which passkey providers it permits, how account recovery works, and whether administrators can revoke registered credentials after a device is lost or an employee leaves.

Synced and Device-Bound Passkeys for Email

Passkeys for email come in two practical forms: synced passkeys and device-bound passkeys. The difference is whether the credential can be securely copied to additional devices through a passkey provider.

A synced passkey is backed up and made available across devices signed in to the same passkey provider. An employee can create a passkey on a phone and use it on a laptop after configuring the same credential manager. The private key remains protected during synchronization, and the user still unlocks it locally with a biometric, a PIN, or a device password.

A device-bound passkey stays on one device or hardware security key and never syncs through a cloud credential manager. That model tightens control over where the private key exists and suits organizations requiring hardware-backed credentials, managed devices, or stricter key-export policies. The trade-off appears in recovery, because a lost device with no additional registered authenticator forces the employee into an approved account-recovery process.

NIST's 2025 guidance on syncable authenticators requires synced authentication keys to be encrypted, protected by access controls, and secured with strong authentication for access to the synchronization service. It also draws a clear enterprise distinction: syncing improves portability, and copying a key to additional devices makes that key exportable. Security teams should pair synced passkeys with managed provider accounts, mobile-device controls, recovery notifications, and regular reviews of registered devices.

For ordinary workforce email, synced passkeys for email often carry an adoption advantage, because employees move between approved phones and computers without returning to passwords. For privileged administrators, executives, finance staff, or systems holding sensitive data, device-bound passkeys on managed hardware provide stronger lifecycle control. The right choice follows the account's exposure, the organization's device-management maturity, and the consequences of losing access.

Understanding a credential model is easy; recognizing the fraudulent prompt that bypasses it is harder. Adaptive Security drills that distinction through realistic phishing simulations across email, voice, and SMS.

Take a self-guided tour

How Do Passkeys for Email Work for Account Sign-In?

Passkeys for email replace passwords with a public-private key pair created by an authenticator on a phone, computer, or security key. Registration binds the credential to an email account and a website origin, while sign-in uses a fresh server challenge that the authenticator approves and signs. The email provider verifies the signature with the stored public key without ever receiving biometric data or the private key. Account recovery methods deserve the same protection as the passkey itself, because recovery can bypass the phishing-resistant sign-in flow entirely.

1. Registering Passkeys for Email

Passkey registration begins after the email service verifies that the user is authorized to add a credential. The user might already be signed in with a password and multifactor authentication, complete an account-recovery check, or confirm the request from an existing trusted device. This initial checkpoint prevents a cyberattacker with temporary account access from silently registering a credential under their own control.

The email service, acting as the WebAuthn relying party, creates registration instructions that include a one-time challenge. The challenge is unpredictable, tied to the current registration attempt, and sent to the browser or app rather than chosen by the user. The service also identifies the relying-party ID, normally the email provider's approved domain, and specifies whether user verification is required.

The browser checks that the request comes from the correct website origin before passing it to the operating system or external authenticator. In WebAuthn, the origin includes the scheme, host, and port, so https://mail.google.com is not interchangeable with a lookalike phishing domain. The W3C Web Authentication specification defines the relationship between the web origin, relying-party identifier, challenge, and authenticator response.

The authenticator then generates a new asymmetric key pair for the email account, and the private key remains protected by the device or passkey manager. The corresponding public key, credential identifier, and registration metadata return to the email service so it can recognize the credential during authentication.

Next, the device requests local user verification through a fingerprint, face scan, device PIN, password, or screen-lock pattern. The biometric check transmits no image or biometric template to the email provider. It only unlocks permission for the authenticator to use the private key.

The browser sends the completed registration response to the email service, which validates the challenge, origin, relying-party binding, response format, and user-verification result before storing the public key. Registration stops if any check fails. The result is a credential tied to one account and one approved service rather than a reusable secret a cyberattacker can copy into a phishing form.

Organizations should treat registration of passkeys for email as a high-value event. Require step-up verification when users add or replace passkeys, notify the account owner, record device or credential metadata, and provide a clear revocation process. A passkey strengthens the normal sign-in path, and a cyberattacker who compromises account recovery or an existing trusted session can still attempt to register a new credential.

2. Signing In With a Challenge

Passkey authentication begins when a user visits the legitimate email service and selects the passkey sign-in option. The service identifies the account through a username, an email address, or a discoverable credential request, then generates a new random challenge. That challenge must be used once and within the server's allowed time window, which blocks replay of an old successful response.

The server sends the challenge and authentication parameters to the browser, which confirms the page's origin and passes the request to the authenticator. The authenticator searches for a credential whose relying-party ID matches the email provider. A credential created for one website never becomes automatically available to another, even when the usernames and passwords would otherwise be identical.

The device presents a local approval prompt, and the user touches a fingerprint sensor, looks at a camera, enters a PIN, or unlocks the screen using the device's required method. This step proves user presence or user verification according to the email provider's policy. The biometric system makes its decision locally and returns an approval signal to the authenticator, so the email service never receives the underlying biometric data.

After approval, the authenticator signs a structured response with the credential's private key. The signed data includes the server challenge and a hash of client data covering the origin. It also includes authenticator data such as the relying-party identifier hash, user-presence or user-verification flags, and a signature counter where supported.

The browser returns the signed response to the email service, which looks up the account's registered credential by its identifier and retrieves the matching public key. The service then checks that the challenge is the one it issued, the origin is the approved email domain, the relying-party identifier is correct, the response has neither expired nor been reused, and the required user-verification flag is present.

The service uses the public key to verify the digital signature. A valid signature proves that the response came from the authenticator holding the paired private key and that the signed challenge was not altered. The server needs no knowledge of the private key, no reconstructed password, and no biometric sample, so it creates the authenticated email session once every policy check passes.

This mechanism explains why a Gmail passkey cannot authenticate to a phishing domain. A fake site can copy Gmail's logo, request an email address, and generate its own challenge, yet the authenticator sees the fake site's origin and refuses to release or use the Gmail credential there. Even when a user approves a passkey prompt on a cyberattacker's page, the resulting credential is scoped to the cyberattacker's domain instead of the real provider.

That protection depends on users reaching the legitimate service and on the email provider implementing WebAuthn correctly. Passkeys for email do not make every account-recovery message trustworthy, and they do not stop a cyberattacker from persuading someone to approve a different transaction or register a new credential. Employees need practice inspecting the site and approval context, reporting unexpected prompts, and stopping when a sign-in request falls outside the normal email workflow.

3. What the Email Provider Stores and Verifies

The email provider stores the public side of the credential rather than the secret that creates valid signatures. Its credential record normally includes the credential ID, public key, account association, relying-party information, and authenticator-related metadata. The provider may also retain display information, creation time, last-used time, and a counter for detecting unusual authenticator behavior.

The public key is safe to expose in the same way that a padlock's public verification information is safe to publish, because it cannot authenticate by itself. Only a signature created with the matching private key proves control of the credential, and that signature holds only when it covers the provider's current challenge and approved origin.

During every sign-in, the provider verifies several separate conditions instead of checking one password-like value:

1. 1Account association: The credential identifier must map to the account attempting to sign in;
2. 2Challenge freshness: The response must contain the unpredictable challenge issued for that session and must not be replayed;
3. 3Origin binding: The client data must identify the legitimate email origin in preference to a lookalike or unrelated domain;
4. 4Relying-party binding: The relying-party identifier hash must match the provider's configured domain;
5. 5User verification: The authenticator data must show that the required biometric, PIN, or screen-lock check succeeded;
6. 6Signature validity: The stored public key must successfully verify the signed response;
7. 7Authenticator state: Counters, attachment information, and other policy signals must not indicate credential misuse.

The provider can reject the response at any stage. That layered verification matters because a captured response carries none of the reusability of a password. It is a signature over one specific transaction, and altering the challenge, origin, or relying-party data invalidates it.

For enterprise email, define those procedures before deployment. Require at least two approved passkeys for email on privileged accounts, monitor new credential registration, revoke lost devices quickly, and protect fallback recovery channels with equivalent scrutiny. Connect these controls to broader phishing simulations and human-layer cybersecurity awareness training so employees rehearse the warning signs around unexpected authentication prompts and account-recovery requests.

Cryptography verifies the domain, yet nothing verifies the request an employee was asked to approve. Adaptive Security scores that judgment and assigns coaching where the weakest decisions appear.

Explore the platform

How Do Passkeys for Email Provide Phishing Protection?

Phishing protection from passkeys for email replaces a phishable password and code with a cryptographic credential unlocked on a trusted device. A fake sign-in page can capture no reusable secret, which blocks password reuse, credential stuffing, stolen one-time codes, and MFA fatigue. The control leaves separate risks in place from compromised devices, active OAuth sessions, weak recovery channels, malicious apps, and social engineering.

According to Verizon's 2026 Data Breach Investigations Report, stolen credentials were involved in 13% of all breaches as an initial access vector, down from the prior year's high. Phishing-resistant sign-in is a high-value control, and it works only when organizations protect the surrounding account lifecycle.

How Do Origin Binding and Phishing Resistance Work?

During enrollment, the email service registers a public key while the corresponding private key stays protected by the user's device, password manager, or hardware authenticator. At sign-in, the legitimate service sends a fresh challenge, and the authenticator signs it only for that service's approved web origin or relying-party identifier.

A phishing page can copy an email provider's branding and reproduce its sign-in form, and it still cannot make the passkey authenticate to the real provider from a different domain. The authenticator checks the origin before releasing a signature. The cyberattacker receives neither a password nor a replayable one-time code, and any signature works only when presented to the legitimate service for the correct challenge.

That distinction matters because passkeys for email validate both sides of the exchange. The user proves control of the authenticator, while the authenticator verifies the service requesting access. Password-and-OTP authentication generally verifies the user's submitted secrets without cryptographically binding the response to the genuine email domain, so a convincing spear phishing page can collect both the password and the current one-time code, then relay them to the real sign-in page in real time.

Passkeys also remove the secret cyberattackers most want to steal. A private key is never typed into an email, copied from a browser form, or sent to the mail provider during ordinary authentication. Biometric checks such as Face ID or a fingerprint usually unlock the credential locally, send no biometric data to the email service, and provide no substitute password that a cyberattacker can replay remotely.

The protection depends on implementation. A passkey offered alongside an active password leaves that password on the threat surface, and phishing remains possible when a user chooses password fallback on a fraudulent page. Netcraft's 2026 analysis of phishing after passkeys describes this transition problem, including continued exposure from fallback passwords, weak recovery methods, and credentials that lack phishing resistance.

Exposure at that scale is not hypothetical. The FIDO Alliance's State of Passkeys 2026 found that one in three consumers, 33%, experienced an account compromise or received a breach notification during the previous year, a level of harm that tracks how many services still depend on passwords.

Which Email Account-Takeover Paths Do Passkeys for Email Reduce?

Passkeys for email reduce cyberattacks that depend on obtaining or replaying a shared authentication secret. They also remove the need for employees to memorize another password, which changes the behavior security teams should rehearse. Employees should approve a passkey only when they intentionally initiated a sign-in, and they should report unexpected prompts, device alerts, or recovery requests.

The main cyberattack paths reduced are:

• Phishing pages: A cloned Microsoft 365, Google Workspace, or webmail page cannot use its own origin to obtain a valid passkey assertion for the real service, though a user might still disclose personal information or choose password fallback, so cybersecurity awareness training must cover the complete interaction instead of treating a passkey prompt as automatic proof of safety;
• Spear phishing: A targeted message citing a current project, executive, vendor, or invoice can still persuade a recipient to open a link, yet the link cannot directly harvest the passkey, and role-based practice remains necessary because cyberattackers can shift from credential theft to payment fraud, malicious file delivery, or consent abuse;
• Credential stuffing: Credential stuffing tests breached username-and-password pairs against many services, and passkey-only sign-in removes the reusable password pair from that path entirely;
• Password reuse: A password exposed at a shopping, social media, or contractor account cannot unlock an email account that accepts only the registered passkey, so administrators should disable or tightly restrict password fallback after enrollment instead of treating passkey availability as passkey enforcement;
• MFA fatigue: Repeated push notifications try to wear down a user until one approval is accepted, and a passkey normally requires a deliberate response on a trusted device, which removes the approval-spam pattern associated with push-based MFA;
• Stolen one-time codes: A code sent by SMS, email, authenticator app, or voice can be intercepted, phished, forwarded, or entered into a reverse-proxy session, and passkeys produce no code that the user must read aloud or type into a second website, so real-time code theft fails against the passkey ceremony itself;
• Password reset phishing: Cyberattackers frequently target reset links and account-verification pages when direct sign-in defenses improve, so recovery workflows must use equivalent assurance or the exception becomes the target.

Credential abuse survives even where those individual paths narrow. Verizon's 2026 Data Breach Investigations Report found that credential abuse appears somewhere in 39% of breaches when measured across the full cyberattack chain in preference to initial access alone, which is why passkeys belong inside an email account-takeover program instead of standing alone as a login feature.

Security teams should map every route into the mailbox, including login, enrollment, recovery, delegated access, third-party applications, and administrator override. Each of those routes needs an owner, a verification standard, and a log that someone reviews.

Passkeys for Email Versus Password Plus One-Time Code

The practical choice is broader than stronger authentication against weaker authentication. It is a trade-off among cryptographic protection, deployment control, recovery complexity, and user familiarity. The table below sets out how each method changes the email threat profile.

Passkeys for email often improve usability after enrollment because users approve locally instead of remembering a password and retrieving a code. The trade-off surfaces during device replacement, cross-platform access, shared mailboxes, travel, and account recovery. A security team that makes recovery difficult without providing a tested process will drive users toward unsafe workarounds, such as storing recovery codes in email or accepting help from an impersonated administrator.

A strong policy requires passkeys for email on high-risk accounts, eliminates password fallback where operationally practical, protects enrollment with an existing strong factor, issues clear procedures for lost devices, and monitors every recovery event. Keep a narrowly controlled break-glass path under separate administrative oversight in preference to leaving a broadly available password reset route.

What Risks Do Passkeys for Email Not Remove?

Passkeys protect the sign-in ceremony rather than everything that happens before or after it. A cyberattacker who controls an unlocked device, installs a malicious app, or captures an active browser session can act as the user without phishing the passkey at all. Endpoint protection, device encryption, screen locks, browser controls, and session monitoring must continue alongside phishing-resistant authentication.

Active OAuth sessions create a separate cyberattack path. A malicious application can request permission to read mail, send messages, or access files, and excessive consent lets a cyberattacker retain access through a token even after the original password changes. Email administrators should restrict third-party app consent, review delegated permissions, revoke suspicious tokens, and alert on unusual mail-reading or forwarding behavior.

Recovery channels remain a critical weakness. A cyberattacker who convinces a help-desk agent to replace a phone, reset an authenticator, or add a new device can bypass a well-designed passkey, and recovery email accounts, SMS numbers, backup codes, and security questions carry the same exposure. Each channel needs identity verification that does not rely solely on information available through open-source intelligence (OSINT).

Social engineering also survives the move to passkeys for email. A fake executive can ask an employee to approve a login, install a remote-support application, reveal a recovery code, or authorize an OAuth integration. Passkeys prevent cyberattackers from harvesting the cryptographic credential through a standard phishing form, and they cannot determine whether a legitimate user has been manipulated into taking a dangerous action.

Email defenses therefore need behavioral preparation alongside cryptography. Use phishing simulations for spear phishing, vishing, smishing, fake support calls, OAuth-consent lures, and recovery fraud. Teach employees to treat an unexpected passkey prompt as a reportable signal instead of a routine inconvenience, and give them a fast path to contact security.

Block the credential harvest and cyberattackers pivot to invoice fraud, consent abuse, and voice impersonation instead. Adaptive Security rehearses each of those channels and measures how employees respond.

Take a self-guided tour

How Do I Create Passkeys for Email in Gmail and Outlook?

Creating passkeys for email starts in the security settings of the account that controls the mailbox rather than inside the mail application itself. The user opens those settings, chooses the passkey option, selects a storage location, and approves the device-unlock prompt.

Google and Microsoft both support passkeys on phones, computers, synced password managers, and compatible FIDO2 security keys, while work and school accounts can restrict those options through administrator policy. Employees should create credentials only on devices they control, test sign-in immediately afterward, and keep a recovery method available.

1. Gmail and Google Workspace

For a personal Gmail account, the user opens Google Account passkey settings while signed in to the correct Google Account. Selecting Create a passkey, confirming it in the following window, and unlocking the device with Face ID, fingerprint recognition, a device PIN, a pattern, or another supported screen-lock method completes enrollment. The biometric check stays on the device instead of travelling to Google, according to Google's current passkey instructions.

Google typically saves the passkey to the credential manager associated with the device:

• Android: Google Password Manager,
• Apple devices: iCloud Keychain, when enabled,
• Windows computers: Windows Hello or a synced password manager, depending on the browser and operating system.

When the save window offers Change, Save another way, or Use another device, the user should choose the location that fits an existing recovery plan. Accepting an unfamiliar default without checking where the credential will reside creates avoidable confusion later.

A password manager works well for someone signing in across several personal devices, while a device-bound passkey keeps the credential on one phone or computer. Personal Gmail passkeys do not belong on a shared family computer, public workstation, or borrowed phone. Anyone able to unlock that device can use the passkey to reach the Google Account, including Gmail, Drive, Photos, and other connected services.

A physical security key provides an additional option. Returning to the Google passkey page, selecting Create a passkey, choosing Use another device, and selecting the security-key option starts that flow. The user then inserts a FIDO2-compatible key, enters its PIN, and touches the key or uses its fingerprint sensor.

A FIDO2 key sits separately from a passkey stored in a browser or password manager, so registering a second key and storing it securely prevents an interruption if the first one disappears.

Google Workspace applies administrator-controlled policies to the same feature. When a Gmail address belongs to an employer, school, or other organization, the account security settings show How you sign in to Google, where the Skip password when possible setting indicates whether the administrator permits passkey-only sign-in. If that setting is unavailable or disabled, the account may still allow a passkey as a second factor for 2-Step Verification, account recovery, or sensitive account actions without replacing the password at every sign-in.

Workspace administrators manage these methods through the Google Admin console. Before asking employees to register passkeys for email, administrators should review the authentication policy and confirm whether passkeys are permitted for the relevant organizational unit or group. Employees who see a policy error should contact IT in preference to repeatedly changing browser or phone settings, because the restriction reflects an identity-policy decision rather than a Gmail malfunction.

After saving the passkey, the user signs out of Gmail or opens a private browser window on the same device, enters the email address, chooses the passkey prompt, and approves the device unlock. Signing in on a computer with a passkey stored on a phone means selecting Try another way, choosing Use your passkey, scanning the QR code with the phone, keeping Bluetooth enabled when prompted, and approving the request with the phone's screen lock. A final check in Google Account security settings confirms that the credential appears under Passkeys and security keys.

2. Outlook and Microsoft 365

Microsoft personal accounts control Outlook.com mail through the Microsoft account security dashboard. The user opens Microsoft's Advanced Security Options, selects Add a new way to sign in or verify, and chooses Face, Fingerprint, PIN, or Security Key. Following the device prompt, selecting Continue or Create, and saving the passkey in the suggested location or choosing Change or Save another way completes the process.

Available locations can include Microsoft Password Manager, Google Password Manager, Apple iCloud Keychain, another synced password manager, Windows Hello, a phone, or a physical security key. Windows can request face recognition, a fingerprint, or a PIN. An iPhone or iPad can request Face ID, Touch ID, or the device passcode, while Android uses its configured screen lock.

A phone-based passkey can display a QR code that the user scans with the phone camera or Microsoft Authenticator, and Bluetooth can be required when the phone verifies a nearby computer. The unlock prompt confirms possession of the device holding the passkey, which makes a strong screen lock on that device essential.

For a Microsoft 365 work or school account, the organization's identity settings replace Outlook's mailbox settings as the correct starting point. The user opens mysignins.microsoft.com/security-info, selects Add sign-in method, and chooses Passkey for a device or password manager. Choosing Passkey in Microsoft Authenticator stores the credential in Authenticator on a mobile device.

The browser prompt, the save location, and the phone, computer, or password-manager unlock finish the registration.

The exact options depend on Microsoft Entra policy. When Passkey does not appear, the organization has either not enabled that method for the account or limited the permitted authenticator types. Employees should ask IT whether the policy allows platform passkeys, Authenticator passkeys, synced password-manager passkeys, or external FIDO2 keys.

Creating a work credential inside a personal password-manager profile causes a common failure, because a passkey created in the wrong profile can go missing during work-account sign-in.

Registering a physical security key for Microsoft 365 starts at myaccount.microsoft.com, where the user selects Security Info, chooses Add method, and selects Security key. Selecting USB device or NFC device, inserting or tapping the key, creating a unique PIN, and touching the key when requested completes enrollment. A recognizable name such as "Finance laptop key" and a final Done selection keep the credential list readable.

On Windows 11 version 23H2 or later, a sign-in window that prioritizes another device can be redirected through More choices and Security key.

Testing access at Outlook.com or through the organization's Microsoft 365 sign-in page confirms the result. The user enters the account name, chooses the passkey method, and approves the device-unlock prompt, then reviews Security Info to confirm that the new passkey or security key is listed. An approved backup method, such as a second security key or an administrator-supported authenticator, should exist before any old password or device is removed.

3. Other Email Providers and Custom Domains

Passkey support belongs to the account that authenticates the mailbox in preference to the app used to read email. When Yahoo Mail, Proton Mail, Fastmail, or Zoho Mail uses its own username-and-password system, the provider's Account, Security, Sign-in, or Two-step verification settings are where passkeys for email appear. The ability of a phone, browser, or password manager to store passkeys says nothing about whether a given provider offers them.

Each provider's current account dashboard settles the question:

• Yahoo Mail: Review Account Info and Account Security for a passkey or passwordless sign-in option;
• Proton Mail: Inspect Settings and the account's sign-in or two-factor security controls;
• Fastmail: Check Settings under Privacy & Security or Two-step verification;
• Zoho Mail: Open Zoho Accounts, then review Security and the available authentication methods.

Menu names and availability vary by region, account type, browser, and rollout status, so the provider's visible security dashboard is the final check.

iCloud Mail works differently because an Apple Account authenticates the mailbox. Management happens through Apple Account security settings and the device's passcode, Face ID, or Touch ID controls in preference to a separate iCloud Mail passkey page. On Apple hardware, iCloud Keychain synchronizes passkeys across approved devices when enabled, so confirming that the Apple Account appears in the expected device list and testing access through iCloud Mail after registration prevents surprises.

The same distinction applies to third-party mail apps. Adding a Gmail address to Apple Mail creates no Apple passkey for Gmail, because the Google Account's authentication policy still governs sign-in. Adding Outlook.com to Thunderbird creates no Thunderbird passkey either, since the Microsoft account remains the relying party.

For a company mailbox on a custom domain, identify whether Google Workspace, Microsoft 365, or another identity provider handles sign-in. Create the passkey in that provider's security portal, test a fresh sign-in, check the registered credential list, and confirm that recovery methods work before treating passkeys as the primary sign-in method. A credential that is convenient to use and impossible to recover becomes an access problem the moment the device is lost.

Enrollment instructions reach every mailbox, yet fraudulent enrollment prompts arrive through the same inbox. Adaptive Security detects and removes those messages before an employee ever sees them.

Book a demo

Where Are Passkeys for Email Stored, and Can They Sync Across Devices?

Passkeys for email can live on a phone, computer, tablet, browser-managed credential store, cloud-synced password manager, or FIDO2 hardware security key. A synced passkey is encrypted and made available across approved devices, while a device-bound passkey remains tied to one authenticator. Synced credentials prioritize recovery and convenient sign-in across operating systems, and device-bound credentials provide tighter control over where the private key exists.

A phone can also authorize sign-in on a nearby computer through a QR code and a Bluetooth Low Energy proximity check without transferring the private key to that computer. The right choice follows whether the organization prioritizes broad availability, centralized administration, strict key custody, or accessible authentication for every employee.

Synced Versus Device-Bound Storage for Passkeys for Email

A passkey provider stores passkeys for email, and the email service holds no reusable password of its own. On Android and Chrome, Google Password Manager can store and sync passkeys through the user's Google account. Apple devices use iCloud Keychain to make passkeys available across supported iPhones, iPads, and Macs.

Windows environments can use Windows Hello for device-bound credentials, browser or platform credential managers, and external providers configured by the organization. Enrollment, recovery, and synchronization behavior all depend on the operating system, browser, account policy, and identity provider in use.

Third-party password managers can act as passkey providers through an application or browser extension. That model suits workforces spanning Windows, macOS, Android, iOS, and multiple browsers, and administrators must verify platform support and account-recovery protections before approving a provider.

A FIDO2 security key takes a different approach by storing a device-bound credential on the physical key, so the passkey never appears automatically on a replacement phone or laptop. The user must have the key available whenever the organization requires it for authentication.

Synced passkeys use end-to-end encryption within the provider's synchronization design, so the provider receives no usable private-key material during ordinary syncing. The FIDO Alliance's passkey guidance explains that biometric data remains on the local device while the email service receives cryptographic proof that verification succeeded.

For most employees, synced passkeys for email reduce lockouts because a new phone, computer, or tablet can receive the credential after the user securely signs in to the same provider. The provider account itself therefore needs strong recovery controls and documented procedures for lost devices.

Device-bound credentials suit privileged accounts, regulated workflows, and administrators who must guarantee that only one specific authenticator holds the private key. Many organizations should run both approaches, assigning synced passkeys to routine email access and hardware-backed, device-bound credentials to high-impact accounts.

Cross-Device and QR Sign-In for Passkeys for Email

Cross-device sign-in addresses a practical problem. An employee creates a passkey on a phone and then needs email access from a computer where that credential does not exist. The computer displays a QR code, the employee scans it with the phone, approves the sign-in, and completes authentication without typing a password.

This flow works across phones, computers, tablets, and browsers when the email service and operating systems support FIDO cross-device authentication. Bluetooth Low Energy confirms that the phone and computer sit physically near each other, which forms part of the proximity check in preference to the cryptographic basis of authentication, and the passkey is never copied to the computer.

Bluetooth must be enabled for that proximity check. It becomes unnecessary when the passkey already sits on the device being used, such as signing in directly from an iPhone with iCloud Keychain or an Android phone with Google Password Manager.

Adoption data shows why the flow matters. The FIDO Alliance's Passkey Index 2025 reported that participating service providers made an average of 93% of accounts eligible for passkeys, with 36% of accounts actually holding an enrolled passkey and 26% of all sign-ins using one.

IT teams should therefore test QR sign-in across the combinations employees actually use. A Windows laptop paired with an iPhone, a Mac paired with an Android phone, and a managed browser can each present different prompts or policy restrictions. Recovery instructions must also cover the loss of both the synced provider and the backup authenticator.

Hardware Keys and Accessibility for Passkeys for Email

FIDO2 hardware security keys provide durable credential custody for email accounts that require tighter control. A user inserts the key into a USB port or taps an NFC-capable key to a compatible phone, then touches the key or enters its PIN depending on the model and authentication policy. Some keys support USB, NFC, or Bluetooth, and Bluetooth is unnecessary for USB or NFC authentication.

Accessibility belongs in deployment planning rather than in a communications afterthought. Employees who cannot use fingerprint or facial recognition can authenticate with a device PIN, a passcode, or a security-key PIN when the operating system supports that method. Hardware keys with tactile buttons, NFC support, or USB connectors provide alternatives for users with different motor, visual, or biometric-access needs.

Organizations should offer more than one approved method, such as a synced passkey unlocked by a PIN plus a backup hardware key. Security teams should test the complete flow with assistive technologies and document recovery procedures in language employees can follow under pressure.

Before enforcing passkeys for email, document supported providers, recovery paths, cross-device behavior, and accessibility options. A credential strategy succeeds when every employee can authenticate safely on the phone, computer, tablet, or browser the job requires, including after a trusted device is lost or replaced.

A synchronization account becomes the new perimeter, and few employees treat it that way. Strengthen that habit with Adaptive Security's role-based cybersecurity awareness training and reporting dashboards.

Explore the platform

How Do I Sign In to Email With Passkeys for Email on a Computer or Mobile App?

Signing in with passkeys for email starts on the provider's web sign-in page or inside a supported mobile app. The user selects the account and approves access with a fingerprint, a face scan, a device PIN, or a screen-lock method. On a computer, that means either the passkey stored on that machine or an approval sent from a nearby phone when the browser offers cross-device authentication.

Provider and email-client support deserve a check before any sign-in method changes, because older IMAP, SMTP, or POP software may require OAuth 2.0 or a narrowly scoped app password.

1. Use Webmail and Native Apps With Passkeys for Email

Webmail usually provides the clearest passkey experience. The user opens the provider's sign-in page in a supported browser, enters an email address if requested, and chooses Sign in with a passkey. When the passkey sits on that computer, the browser opens the device's credential prompt for confirmation through Windows Hello, Touch ID, a fingerprint sensor, facial recognition, or the local PIN.

The provider verifies the passkey while receiving neither biometric data nor the private key held on the device.

The same process works on a phone or tablet. The user opens the provider's mobile site or official email app, selects the account, and approves the passkey prompt through Face ID, fingerprint authentication, or the device passcode. Google's Android passkey guidance explains that passkeys can be saved in a password manager and used on other supported devices, so confirming which password manager holds the credential matters before replacing a phone or resetting a browser.

Speed is part of the reason employees accept the change. The FIDO Alliance's Passkey Index 2025 reported that passkeys cut sign-in time by 73% compared with other authentication methods, averaging roughly 8.5 seconds per login across contributing service providers.

One safety rule governs the cross-device flow described earlier. Before approving a scanned QR request on the phone, the user must confirm that the displayed website and account match the sign-in actually initiated. A passkey QR code arriving by email or supplied by an unverified person should never be scanned at all.

A native client such as Mailbird neither receives nor stores the passkey. Instead, it opens the provider's OAuth 2.0 authorization page, where the user authenticates with the passkey in the browser or embedded sign-in window and grants the client permission to reach mail, contacts, calendars, or sending functions. The client stores an OAuth 2.0 access or refresh token according to its integration design in preference to the passkey itself.

Reviewing requested permissions and removing the authorization once the app is retired keeps that grant list current. A supported email application integration checklist helps teams standardize this setup.

2. Check IMAP, SMTP, POP, and OAuth 2.0 Support

Email protocols determine how a client retrieves and sends messages, and they do not determine whether that client can perform a passkey ceremony. IMAP synchronizes messages, SMTP sends mail, and POP downloads messages, while OAuth 2.0 handles the authorization step that lets the provider approve protocol access without exposing the account password.

Current versions of Outlook, Apple Mail, Thunderbird, and comparable desktop clients often redirect users to the provider's OAuth 2.0 page. Completing the passkey approval there, returning to the client, and allowing account setup to finish is the expected sequence. A client that asks for the regular email password in preference to opening an OAuth 2.0 window needs an update, and its documentation should explicitly confirm support for modern authentication.

Google's Workspace authentication guidance states that username-and-password-only access for Google Workspace accounts is no longer supported as of January 2025. Legacy clients using basic authentication can therefore fail even when mailbox credentials are correct, so switching to a client with OAuth 2.0 support or asking the administrator about an approved alternative resolves the failure.

An app password serves as a fallback for an older IMAP, SMTP, or POP client that cannot use OAuth 2.0, and it replaces no part of a passkey. Google's app-password guidance requires 2-Step Verification and describes the app password as a separate 16-digit credential for applications that cannot use modern authentication. Organizations should permit one only where the provider and internal policy allow it, use a unique credential for each client, and revoke it once the device is lost, retired, or no longer needs mailbox access.

3. Verify Shared and Delegated Access

Passkeys for email authenticate a person to an account, and they grant no automatic access to every mailbox connected to that account. A delegated inbox, shared mailbox, family account, alias, or forwarding address follows the provider's permissions model. The user signs in to the primary account with a passkey, then opens the delegated mailbox only where the administrator has granted that identity the required access.

Aliases usually send or receive through the underlying account in preference to creating a separate passkey identity. Forwarding likewise transfers no passkey protection to the destination mailbox, so both the source and receiving accounts need independent protection.

For shared mailboxes, assigning named users or groups avoids the distribution of one password or app password. When a person leaves a family plan, team, or delegated arrangement, removing the permission and revoking connected OAuth 2.0 tokens or app passwords closes the access.

The practical checkpoint is straightforward. Use a passkey for interactive provider sign-in, OAuth 2.0 for modern mail clients, and an app password only as a controlled exception. That separation keeps the passkey private while preserving approved desktop and mobile access, provided every connected account and authorization stays under review.

Every QR prompt teaches employees to scan first and question later, which cyberattackers exploit. Adaptive Security builds the reflex to verify before approving any authentication request that reaches the mailbox.

Take a self-guided tour

How Do I Recover Passkeys for Email After Losing a Device?

Recovery for passkeys for email proceeds in three stages: secure the account from a trusted device, move the credential to replacement hardware, and audit everything the missing device could still reach. Each stage assumes the account already holds a second registered authenticator or a stored recovery method, which is the single most important preparation step. Organizations that skip that preparation discover the gap at the worst possible moment, when the only authenticator is already gone and the help desk becomes the fallback.

1. Secure the Account After a Lost, Stolen, or Reassigned Device

The user signs in from a trusted device using a password, another registered passkey, a recovery code, or a hardware security key. Changing the account password, where one exists, matters most when the missing device was unlocked, shared, or accessible to another person. The email provider's security controls then allow the device to be marked as lost, signed out remotely, and stripped of its passkey.

A passkey stored only on the missing device gives a cyberattacker no automatic access to the email account. Risk climbs when that person also holds the device's screen lock, Apple Account, Google Account, recovery phone, or an active browser session. Apple's passkey guidance explains how to manage and delete credentials through the Passwords app, so the missing device's credential should be removed even where remote-wipe protection is enabled.

Recovery should never depend on one channel. Store recovery codes offline, enroll at least one backup security key, and maintain a password or alternate verification method protected separately from the primary phone.

For a business mailbox, document an approved help-desk or administrator recovery process that restores access without bypassing identity checks.

When the Apple Account or Google Account synchronizing passkeys for email is itself unavailable, that account needs recovery through its official process first. A previously trusted device, a recovery contact, a backup email, a recovery phone, or a security key can each serve as the entry point. Creating a new email account transfers none of the old passkeys, because synchronized credentials stay tied to the credential manager and account ecosystem that created them.

2. Migrate Passkeys for Email Between iPhone and Android

Plan migration before wiping or trading in the old phone. Confirm that the email account has a second sign-in method, verify that passkeys are synchronized, generate fresh recovery codes, and enroll the replacement phone or a backup security key. Keeping the old device connected and usable until the replacement completes a successful email sign-in prevents a self-inflicted lockout.

Moving between iPhone and Android depends on the credential manager and the email provider's support for cross-device passkey transfer. Passkeys synchronized through iCloud Keychain appear on other Apple devices signed in to the same Apple Account.

Google's passkey recovery guidance describes a comparable restoration path through Google Password Manager once the user signs in and verifies the device's screen-lock credential. Cross-platform migration can instead require a QR-code handoff, another passkey, a security key, or the account password and recovery method.

After signing in on the replacement phone, test the email account in a private browser window and in the mobile app. Confirm that the passkey appears in the correct password manager, then remove the old device from the provider's device list.

Factory-reset, sell, recycle, or reassign the previous phone only once access works on the replacement. For company-owned devices, also remove management profiles, work accounts, authentication applications, and cached browser sessions through the organization's device-management process.

3. Audit Account Access, Sessions, and Connected Applications

Finish recovery for passkeys for email with an account and session audit. Review every active browser session, phone, tablet, mail client, trusted device, recovery method, passkey, and security key. Revoke anything unfamiliar, expired, or associated with the lost or reassigned device, and sign out of all sessions where the provider offers that control, because changing a password alone can leave existing sessions active.

Third-party OAuth tokens deserve attention immediately after sessions. Email, calendar, storage, travel, productivity, and marketing applications can retain delegated access long after a device is erased. Revoke tokens for applications the user no longer needs, does not recognize, or reached from the old device.

Check forwarding rules, mailbox delegates, filters, app passwords, recovery addresses, and recent security events for changes made during the exposure window.

Primary email needs more than one recovery path, because it often resets other accounts. Maintain two independent methods, such as a passkey on a primary phone plus a hardware security key, or a passkey plus offline recovery codes.

Test both methods during a planned account review, and replace recovery codes or keys immediately after loss, compromise, or reassignment.

Recovery channels fail quietly until a help desk hands an account to the wrong caller. Adaptive Security runs voice phishing simulations that test verification discipline under manufactured urgency.

Take a self-guided tour

How Do I View, Remove, Replace, or Troubleshoot Passkeys for Email?

Managing passkeys for email means identifying where the credential is stored, confirming that the email provider supports passkeys, and using the provider's official sign-in or account-security page to create, revoke, or retry authentication. The device, browser, password manager, and fallback methods all deserve a check before anything is deleted. Unexpected security warnings should be treated as suspicious until the provider is opened directly in preference to following a link inside the message.

1. Manage and Revoke Passkeys for Email

A password manager or device platform stores the passkey, while the email provider maintains a registered credential record. Retiring a passkey from a sold, lost, shared, or borrowed device requires checking both locations.

For Google accounts, the path runs through Google Account > Security > Passkeys and security keys, and Google Password Manager offers a second view when searched by account. Reviewing device names and creation dates makes unrecognized credentials easy to remove. When the passkey was saved locally in Chrome or Android, Google Password Manager > Passkeys deserves the same review.

A passkey that appears automatically after registration can be entirely legitimate. Some providers create or register one during account setup or after a successful password sign-in, so the absence of a separate "create passkey" action does not by itself indicate compromise.

On an iPhone running iOS 18 or later, the user opens the Passwords app, authenticates with Face ID, Touch ID, or the device passcode, selects Passkeys, and chooses the email account, then taps Edit > Delete > Delete Passkey. Apple's passkey management guidance explains that older iOS versions place comparable controls under Settings > Passwords. When iCloud Keychain synchronizes the credential, deleting it from one Apple device can remove it from other devices using the same Apple Account.

Replacing a passkey works better than deleting one outright. Sign in through the provider's account-security page, register a new credential on a trusted device, test it in a private browser window, and revoke the old credential only once the new one works. Replacement matters most when the old credential belongs to a device that was sold, returned, shared, or otherwise released.

An alert reporting that a passkey was added, changed, or used without approval calls for immediate action: change the account password, revoke unfamiliar sessions, remove the passkey, and review recovery methods. Check the account's recent activity from the provider's official website in preference to any link inside the alert.

2. Diagnose Common Sign-In Errors With Passkeys for Email

A missing passkey usually means the credential sits in a different password manager, under another account, or on a device that does not share the same synchronization service. Search the provider's account-security page and the device's password manager. On Apple devices, check Passwords > All, Passwords > Passkeys, and Deleted.

On Android or Chrome, check the signed-in Google account in Google Password Manager in preference to only the browser profile currently open.

A passkey that appears invalid, expired, duplicated, or unavailable often reflects a stale credential record or an incomplete registration. When the provider reports that the request expired, starting a new sign-in or registration flow works better than reusing the original browser tab. When two entries describe the same account, keep the credential tied to a device under the user's control, test it, and revoke the duplicate through the provider's security settings.

Delayed availability can occur during synchronization. Confirm that the device is online, unlock it once, reopen the password manager, and retry the sign-in. Repeatedly creating credentials during a synchronization delay produces unnecessary passkey records and makes account management harder.

When the passkey prompt does not appear at all, confirm that the provider supports passkeys and that the account type is eligible. Update the operating system, password manager, and browser, then retry with a current version of Chrome, Safari, Edge, or another supported browser. Privacy settings, a disabled device lock, blocked Bluetooth during a nearby-device flow, or an outdated browser can each prevent the credential chooser from appearing.

3. Use a Safe Fallback and Troubleshooting Sequence

A safe fallback preserves account access without weakening the account. Select Try another way only on the provider's genuine sign-in page, then use the password, authenticator app, security key, recovery code, or verified recovery method already attached to the account. Keep at least one trusted fallback available until the new passkey works across primary devices.

A legitimate provider prompt appears inside the expected website or operating-system credential interface and asks for approval through the device lock, Face ID, Touch ID, or a fingerprint. It never asks anyone to type a passkey, reveal a private key, install an unknown app, call a phone number, or enter credentials into a pop-up reached through an unsolicited email.

Warnings that demand immediate action deserve to be closed. Open the email provider by typing its address or using a saved bookmark, review account activity there, and contact support through the provider's official website when access remains blocked.

Fraudulent warnings arrive at scale. According to the FBI Internet Crime Complaint Center's 2025 Internet Crime Report, phishing and spoofing generated 191,561 complaints, the highest number of reports in any category.

When troubleshooting fails, stop creating new credentials. Revoke the suspicious or broken passkey from the provider, secure the account with a trusted fallback method, update the device and browser, and document the event for the security team. Organizations can reinforce that process with phishing simulations that train employees to distinguish genuine authentication prompts from social-engineering warnings, turning a confusing sign-in failure into a practiced security decision.

Sign-in failures create the exact confusion that fraudulent support messages are written to exploit. Adaptive Security lets employees report suspect prompts and routes them through automated triage.

Explore the platform

How Should Businesses Roll Out Passkeys for Email Across Employee Accounts?

Businesses should roll out passkeys for email in stages: assess identity and device readiness, pilot a representative group, define authentication and recovery policies, expand enrollment, and monitor failures alongside suspicious activity. Configuration begins at the identity provider in Google Workspace, Microsoft 365, Microsoft Entra ID, or another platform, followed by validation of how SAML applications inherit those policies. Sequencing matters, because a policy enforced before recovery exists produces lockouts.

1. Establish Readiness and Run a Controlled Pilot

Inventory every identity path employees use to reach email. Document whether Google Workspace or Microsoft 365 acts as the primary identity provider, whether Microsoft Entra ID brokers access, and which applications authenticate through SAML. Include mobile mail clients, desktop Outlook, Gmail, virtual desktops, contractors, shared workstations, and recovery workflows, because a passkey policy that works in a browser and fails in a legacy mobile client creates lockouts in place of protection.

Check operating-system versions, browser support, screen-lock settings, biometric availability, security-key compatibility, and mobile-device-management controls. Test same-device passkeys for email and cross-device sign-in, including QR-code handoffs where supported. Include employees who use assistive technologies, cannot use biometrics, share workstations, or work where mobile access is restricted, since accessibility functions as an access-control requirement.

Choose a pilot cohort that reflects operational differences. Include IT administrators, security staff, finance employees who approve payments, remote workers, users on managed and unmanaged devices, and employees with older hardware. Limiting the pilot to technically confident volunteers hides the failure patterns that matter most.

Record enrollment completion, sign-in success, help-desk contacts, recovery attempts, device replacement cases, and application failures. Expand only once the team can explain and remediate each failure pattern it observed. Most organizations are already somewhere on this path, since the FIDO Alliance's State of Passkeys 2026 found that 68% of surveyed organizations have deployed or are actively deploying passkeys for employee sign-ins.

2. Define Policy and Communicate Enrollment

Write the policy before sending enrollment invitations. Specify which passkey types are allowed, whether users need one or two registered authenticators, when phishing-resistant MFA becomes mandatory, and which populations require device-bound credentials. Administrators, privileged users, finance approvers, executives, and regulated users should receive stricter controls wherever device provenance matters, and attestation belongs in that policy when the identity provider supports it and the risk assessment calls for cryptographically verifiable authenticator information.

Synced passkeys generally do not support attestation, which creates a common configuration error. A policy meant to restrict only privileged accounts can accidentally exclude the general workforce. Apply separate policies by user group, device type, and risk level, and document the reason for each exception.

In Google Workspace, configure passkey and security-key settings in the Admin console, apply them to pilot organizational units, and test enforcement against Gmail web, mobile access, and SAML applications. In Microsoft 365 or Microsoft Entra ID, configure passkey profiles and authentication-method policies for selected users or groups before broad enforcement. In a SAML environment, enforce the policy at the identity provider that issues the authentication assertion, then test every service provider's session, reauthentication, and logout behavior.

Enrollment messages should explain what employees will do, what information the organization will not receive, and how to get help. State plainly that a device PIN, fingerprint, facial recognition, or security key unlocks the passkey and that the organization receives no employee biometric data.

Provide a short enrollment window, live support, platform-specific screenshots, and a warning never to approve an unexpected sign-in prompt. Document HRIS, SCIM, SSO, and directory dependencies through identity and access integrations.

Treat shared business mailboxes separately. Give every employee an individual passkey and require that person to authenticate as themselves before opening a delegated mailbox, granting access through Google delegation, Microsoft 365 mailbox permissions, or an approved role-based group. One passkey or password serving multiple people erases accountability and makes departures, investigations, and access reviews unreliable.

Record who holds delegation, who used the mailbox, and when access was removed.

3. Monitor Enrollment and Build Recovery Before Enforcement

Monitor the full credential lifecycle in preference to initial registration counts alone. Alert on unusual enrollment locations, rapid passkey additions, unexpected removals, repeated failures, recovery-method changes, new authenticator models, and sign-ins following suspicious password resets. Compare identity-provider logs with device-management and mailbox-audit data, because a sudden removal of an executive's passkey followed by a new registration and a mailbox-delegation change deserves investigation before the account is trusted again.

Recovery should require two-person approval for privileged accounts and a documented identity-verification procedure for everyone else. Require employees to register a second authenticator before enforcement, such as a separate device-bound passkey or a hardware security key. Store spare security keys under controlled custody for administrators and regulated users, and test replacement procedures during the pilot.

Keep a narrowly scoped temporary recovery method for genuine exceptions, with a short expiration, enhanced logging, and mandatory follow-up enrollment.

Prevent lockouts by identifying older devices and unsupported browsers before disabling passwords or phishable MFA. Maintain an exception group, publish minimum client requirements, and give employees a clear upgrade path with a deadline. Review enrollment, failure, recovery, removal, delegation, and incident metrics weekly during rollout, then monthly after stabilization.

Governance determines whether any of that survives contact with competing priorities. According to the World Economic Forum's 2026 Global Cybersecurity Outlook, 52% of highly resilient organizations indicate that board members receive regular cybersecurity updates, and 48% report that board members are actively engaged with cybersecurity issues. Sustained attention at that level is what keeps a passkeys for email program funded through the awkward middle of a rollout.

Enforcement deadlines slip when employees never understand why the authentication method changed. Adaptive Security pairs rollout communication with compliance training and completion evidence security leaders can audit.

Take a self-guided tour

What Are the Privacy, Security, and Usability Limitations of Passkeys for Email?

Passkeys for email provide stronger phishing resistance than passwords without removing every account-takeover risk. The central trade-off runs between device-bound passkeys, which maximize isolation, and synced passkeys, which improve recovery and portability by copying encrypted credentials across a provider's cloud ecosystem. The right configuration depends on whether the mailbox is personal, shared, administrative, regulated, or capable of resetting other accounts.

What Are the Privacy and Device-Access Limitations?

Passkey biometrics typically remain on the device. A fingerprint or face scan unlocks the device's protected authenticator locally, while the email provider receives cryptographic proof in place of the biometric image or template. That design limits exposure to centralized biometric databases without making device security optional.

Anyone able to unlock a shared phone, family tablet, or unattended workstation can potentially use the passkey to open the email account. A separate biometric profile creates no separate security boundary when several people can unlock the same device or reach the same account session.

Use a dedicated device profile, require a strong device PIN, disable automatic sign-in on shared hardware, and avoid registering passkeys for email on equipment that other people can unlock. For administrative and recovery mailboxes, keep the authenticator on a device controlled by the account owner or the organization.

Passkeys also offer no protection against an already-stolen active session. Malware, a malicious browser extension, an exposed session cookie, or remote access to an unlocked browser can let a cyberattacker operate inside an authenticated mailbox without triggering a new passkey event. NIST Special Publication 800-63B, published in 2025, treats session management, reauthentication, session monitoring, and prompt termination as separate controls, because strong sign-in guarantees nothing about session integrity.

Speed is what makes that gap consequential. According to the CrowdStrike 2026 Global Threat Report, the average adversary breakout time, the window between initial access and lateral movement, dropped to 29 minutes, with the fastest measured at just 27 seconds.

Email administrators should therefore shorten sessions for privileged accounts, require reauthentication for forwarding-rule changes and recovery-factor edits, and revoke active sessions after device loss or suspected compromise. Passkeys strengthen authentication at sign-in, and session controls protect the account afterward.

Privacy also depends on the passkey provider's account-management practices. Synced passkeys improve access across phones and laptops, and the synchronization service becomes part of the trust boundary because it stores encrypted copies of credentials and controls how they are restored across approved devices. Review the provider's encryption model, device-management controls, account-recovery process, and breach-notification commitments before enrolling a sensitive mailbox.

Portability creates a further usability constraint. Moving a passkey between ecosystems is rarely as simple as exporting a password vault, and services differ in their support for import, export, sharing, hardware security keys, and cross-platform transfers. Create an inventory of registered passkeys for email and recovery methods so administrators can remove credentials when a device is sold, reassigned, or retired.

What Are the Availability and Recovery Trade-Offs?

Availability is the main advantage of synced passkeys for email and the main source of additional dependency. Restoring a synced credential after device loss depends on the synchronization service, its account login, its recovery controls, and network access.

A passkey eliminates no provider outage as a practical failure mode. When the email provider, identity platform, passkey manager, or synchronization service is unavailable, users can lose the ability to sign in, register a replacement authenticator, or complete recovery. Administrators should register at least two independent authenticators, maintain tested recovery codes, and document an offline help-desk process.

Recovery email accounts require special treatment because they can reset the primary mailbox and often sit outside normal organizational identity controls. Protect the recovery account with a separate device-bound passkey or hardware security key in preference to another mailbox that depends on the first account. Keep the recovery device away from routine browsing and store recovery codes under controlled access.

Recovery factors can become the easiest route into a strongly protected account. A compromised recovery email, a hijacked phone number, a stolen recovery code, or a socially engineered support interaction can let a cyberattacker add a new passkey without defeating the original authenticator. NIST's 2025 guidance separates authenticator recovery from ordinary authentication and recommends multiple recovery methods alongside notifications for recovery activity.

Treat recovery changes as high-risk events. Require step-up authentication, notify the account owner through an independent channel, record the change, and remove old authenticators when a device is reassigned, sold, or retired. Test these procedures under realistic conditions, because an untested recovery plan fails precisely when the original device or account is unavailable.

What Passkey Configuration Fits Each Risk Level?

Configuration should follow the damage an email takeover would cause in preference to the convenience of the sign-in screen. The FIDO Alliance's 2024 comparison of synced and device-bound credentials describes synced passkeys as more practical for standard accounts and device-bound credentials as better suited to higher-assurance use cases. Recommended configurations by account type follow:

• Ordinary users: Use a synced passkey on a personally controlled phone or computer, protect it with a strong device PIN or biometric, and register a second passkey on another trusted device;
• Families: Give each person a separate device profile and account, avoid shared passkeys, and use a hardware security key or device-bound passkey for the household recovery mailbox;
• Administrators: Use device-bound passkeys or hardware security keys, require two independent authenticators, restrict registration to managed devices, and enforce short sessions with step-up checks for security changes;
• Regulated organizations: Prefer managed, device-bound credentials for privileged and sensitive roles, retain auditable recovery procedures, and validate provider controls against organizational policy and applicable requirements;
• High-risk accounts: Use two hardware security keys stored separately, prohibit synced credentials where assurance requirements demand non-exportable keys, and maintain a tested break-glass process;
• Recovery email accounts: Treat the account as a root of trust, isolate it from daily browsing, use a separate authenticator, and review forwarding rules, sessions, and recovery methods after every device change.

Passkeys for email are a substantial improvement over reusable passwords, and email security still rests on device access, recovery design, session controls, and operational discipline. Select the most portable configuration the account's risk can tolerate, then test loss, outage, recovery, and device-reassignment procedures before deployment becomes routine.

Session theft and consent abuse operate entirely after authentication succeeds, where cryptography offers nothing. Adaptive Security monitors human risk signals across the mailbox and flags the exposures first.

Explore the platform

Why Passkeys for Email Belong Inside a Broader Human-Layer Security Program

Passkeys for email remove a major credential-theft pathway without removing the human decisions cyberattackers exploit after sign-in. Phishing-resistant authentication protects the act of proving identity, while cybersecurity awareness training and human risk management protect the actions employees take before, during, and after access. The Cybersecurity and Infrastructure Security Agency's Implementing Phishing-Resistant MFA fact sheet (2022) identifies FIDO and WebAuthn authentication as widely available phishing-resistant methods, and broader defense still requires employees to recognize manipulation across several channels and report suspicious activity quickly.

Which Cyber Threats Still Require Cybersecurity Awareness Training?

Passkeys stop none of the following: vishing, smishing, business email compromise (BEC), deepfake impersonation, malicious OAuth consent, unsafe forwarding, or disclosure of sensitive information after access. A cyberattacker can call an employee while posing as a help desk technician, send an SMS claiming that a recovery action is urgent, or use a convincing executive voice to request payment details. The authentication method stays intact while the employee is manipulated into a harmful action.

Documented incidents illustrate what survives strong authentication. In Hong Kong in 2024, an Arup employee approved roughly $25.6 million (HK$200 million) across 15 separate transfers after joining a video conference populated entirely by deepfake participants, according to the Financial Times' 2024 report. In a separate 2024 incident, an AI-generated impersonation of Ukraine's foreign minister appeared in a call with U.S. Sen. Ben Cardin, as reported by The Washington Post in 2024.

Employees should pause high-impact requests, verify them through a known second channel, and report suspicious prompts in preference to treating a familiar face, voice, or phone number as proof. Finance teams can practice verifying an urgent invoice change, executives can rehearse responding to an alleged assistant or regulator, and developers can examine malicious OAuth consent screens and unsafe data-sharing requests.

The synthetic media behind the Arup and Cardin cases is now industrialized. According to Sumsub's 2025–2026 Identity Fraud Report, deepfake attacks increased 180% YoY including deepfakes, synthetics, and telemetry tampering.

All employees should practice spotting smishing messages, vishing calls, and deepfake video requests without being blamed when a phishing simulation exposes a gap. Cybersecurity awareness training should also address what happens after a successful login, including forwarding email, handling sensitive attachments, approving applications, sharing data with external recipients, and escalating suspicious mailbox behavior. Multi-channel phishing simulations connect email, voice, SMS, and video scenarios so the organization measures how people respond when several signals reinforce the same false story.

How Can Authentication Signals Combine With Measurable Behavior Change?

Passkeys provide an authentication signal, and human risk programs add behavioral signals showing whether employees recognize and report cyber threats in real operating conditions. Security leaders should connect adoption of passkeys for email and authentication-factor changes with reporting behavior, phishing simulation outcomes, recovery events, suspicious consent approvals, and risky data-handling patterns.

A useful measurement framework includes:

1. 1Authentication resilience: Track passkey enrollment, failed sign-in attempts, unusual recovery changes, and unrecognized authentication prompts;
2. 2Decision quality: Measure whether employees approve, reject, verify, or report simulated requests involving BEC, OAuth consent, payment changes, and sensitive information;
3. 3Reporting speed: Record how quickly employees report suspicious email, SMS, calls, videos, and sign-in prompts, then measure the time security teams need to investigate;
4. 4Role-based exposure: Compare outcomes across finance, executive support, IT help desk, sales, and other roles facing different social-engineering scenarios;
5. 5Behavioral change: Re-test employees after targeted cybersecurity awareness training and track whether reporting rates rise, unsafe actions fall, and risk scores improve over time.

Completion records alone reveal nothing about whether employees will challenge a fraudulent request under pressure. According to Verizon's 2026 Data Breach Investigations Report, 62% of confirmed breaches involve a human element, which is the share of risk no cryptographic control addresses on its own.

A stronger program therefore uses phishing simulations to expose a specific behavior, delivers short cybersecurity awareness training tied to that event, and repeats the test across another channel. The result is a feedback loop in place of an annual compliance exercise.

Deepfake video calls and cloned executive voices never touch the sign-in screen at all. Adaptive Security builds recognition for those cyberattacks through AI-generated, role-specific phishing simulations employees remember.

Book a demo

What Are the Best Practices for Securing an Email Account With Passkeys for Email?

Securing an email account with passkeys for email takes more than enabling one sign-in method. Register at least two independent authenticators, preserve a separate backup, protect the account that synchronizes passkeys, and review recovery factors and connected applications on a schedule. The practices below split by context, because an individual, a household, and an enterprise each carry different failure modes.

1. Individual Practices for Passkeys for Email

Register two passkey authenticators under independent control. Pair a platform authenticator, such as the secure hardware in a current phone or laptop, with a separate hardware security key. If one device is lost, damaged, replaced, or unavailable, the second authenticator preserves access without forcing a weaker recovery process.

Choose authenticators that support the email provider and the mail clients actually in use, then confirm passkey sign-in through the provider's current web interface, mobile application, and desktop client before removing older credentials.

Keep one physical security key in a secure location and store recovery codes offline. The only recovery code should never sit inside the email account it protects, in an unencrypted note, or on the same phone holding the primary passkey. Test recovery ahead of an emergency by confirming that the backup authenticator and recovery method work without loosening the account's security settings.

Protect the synchronization account with its own passkey and strong device security. Passkeys for email stored in a password manager or platform cloud account inherit risk from that account, so use a unique password where one remains necessary, register separate authenticators, enable device encryption, and keep operating systems current. That synchronization account forms part of the email account's security boundary.

2. Family and Shared-Access Practices

Family accounts should use individual identities in preference to shared email passwords or one passkey on a household device. Create delegated access, forwarding rules, or shared-mailbox permissions through the provider's supported controls, and document who has access and why. Individual identities make it possible to revoke one person's access and attribute suspicious activity to the correct account.

Each person should register two authenticators and retain an independent recovery method. Keeping every family member's recovery codes in one unprotected location defeats the purpose, so store them in separate secure places and treat a recovery code as equivalent to an account credential.

Review recovery phone numbers, alternate email addresses, and trusted devices after a family member changes phones, leaves the household, or stops using the account. Remove passkeys for email from reassigned devices before handing them to another person. Audit OAuth access as well, because calendars, messaging tools, and productivity services can reach email without requesting the primary sign-in each time.

3. Enterprise Practices for Passkeys for Email

Organizations should make passkeys for email the preferred sign-in method while maintaining a controlled enrollment path for employees whose devices cannot support them. Standardize approved authenticators, require at least two per user for sensitive roles, and issue hardware security keys to administrators, finance personnel, and executives who face high-impact account-takeover attempts.

That last group deserves the strongest controls for a measurable reason. According to the FBI's Internet Crime Report 2025, BEC losses reached $3.04 billion in the U.S. alone, making it one of the most financially damaging fraud categories.

Identity teams should protect the passkey synchronization account and central identity provider with controls at least as strong as those guarding email. Require phishing-resistant authentication for administrators, restrict recovery-factor changes, alert on new authenticator enrollment, and review sign-in anomalies. Recovery must be auditable, time-limited, and separated from routine help desk approval so a cyberattacker cannot socially engineer a reset through a convincing phone call or vishing attempt.

Offboarding and device reassignment must include credential removal. Revoke passkeys from returned laptops and phones, terminate active sessions, remove OAuth grants, disable forwarding rules, and confirm that recovery factors no longer point to an employee-controlled address or number. Identity and user-management integration controls can connect these actions to HRIS and SCIM status changes, keeping access aligned with current ownership.

The remaining gap is behavioral rather than technical. Employees need practice rejecting unexpected passkey prompts, stopping when a sign-in request arrives without an action they initiated, and reporting suspicious activity through a known channel. Cybersecurity awareness training should rehearse those moments without blaming employees, because practiced recognition gives people a clear response when a cyberattacker manufactures urgency.

Checklists age fast, and an unaudited recovery path is the one cyberattackers eventually find. Track that drift with Adaptive Security's continuous human risk monitoring and mitigation dashboards.

Book a demo

How Adaptive Security Extends Passkeys for Email Into Measurable Human Defense

Security leaders who deploy passkeys for email want a specific outcome: fewer compromised mailboxes, with evidence they can show an auditor or a board. Reaching that outcome requires closing the two gaps passkeys leave open, namely the messages that arrive in the inbox and the decisions employees make once inside it. Adaptive Security addresses both from one place, so credential hardening and behavioral readiness stop living in separate tools.

Adaptive Security's Cloud Email Security connects to Google Workspace or Microsoft 365 through an API, without MX record changes, and applies behavioral signals, intent analysis, and language-model reasoning to inbound mail. Confirmed malicious messages, including fraudulent enrollment and recovery lures aimed at passkeys for email, are removed automatically across every inbox they reached. Each detection then feeds the targeted employee's risk score and triggers relevant Security Awareness Training, which turns a blocked cyberattack into a lesson tied to a real event.

Coverage extends past email as cyberattackers move on, through multi-channel phishing simulations for voice, SMS, and deepfake scenarios, Phish Triage for automated investigation of employee reports, and AI Governance for the shadow AI accounts and data-sharing habits that no authentication method touches. According to the National Cybersecurity Alliance's 2025–2026 Oh Behave! The Annual Cybersecurity Attitudes and Behaviors Report, 58% of employed participants reported they have not received any training on the security or privacy risks of AI tools, despite 65% now using AI and 43% admitting to sharing sensitive work information with AI tools. This gap concentrates risk precisely where visibility is lowest.

Phishing-resistant sign-in closes one door while the rest of the inbox stays wide open. Adaptive Security covers detection, remediation, cybersecurity awareness training, and reporting in one place.

Take a self-guided tour

Frequently Asked Questions About Passkeys for Email

Does Gmail Support Passkeys for Email, and Where Are They Enabled?

Yes. Gmail supports passkeys for email, enabled from the Google Account in preference to Gmail's inbox settings. The path runs through Google Account, then Security, then How you sign in to Google, then Passkeys and security keys. Google's passkey setup instructions provide the current path and device requirements. Selecting Create a passkey, confirming identity, and approving the device's screen lock, fingerprint, or face recognition prompt completes enrollment. Google Workspace users may see different options where an administrator controls passkey enrollment. Registering a second device or security key before treating a passkey as the primary email sign-in method prevents a lockout.

Do Outlook and Microsoft 365 Support Passkeys for Work and School Accounts?

Yes. Outlook and Microsoft 365 support passkeys for email on work and school accounts where the organization's identity policy allows them. The account's Security info page offers Add sign-in method, then Passkey, which can be saved to a compatible device, password manager, or security key. Microsoft's passkey creation guidance covers personal and work or school accounts. An administrator can restrict available authenticators, require a FIDO2 security key, or delay enrollment during a pilot. When Passkey does not appear, contacting the organization's IT administrator is the correct step in preference to creating credentials through an unofficial prompt or third-party site.

Do Passkeys for Email Protect Native Mobile Mail Apps or Only Webmail?

Passkeys for email protect the identity-provider sign-in used by webmail and supported mobile authentication flows instead of every native mail app's internal login screen. Gmail and Outlook mobile apps typically route account authentication through a provider-controlled web or system prompt, where the passkey can be selected. Modern clients using OAuth 2.0 receive an access token in place of the passkey or its private key. Google's OAuth and app sign-in guidance explains this delegated model. Older IMAP, SMTP, or POP clients that lack OAuth 2.0 usually cannot invoke a passkey directly and may require an app password or a supported mail client.

Can Passkeys for Email Replace Both a Password and Two-Step Verification?

A passkey can replace the password and satisfy the sign-in requirement that two-step verification protects, though the exact result depends on the email provider and account policy. Passkeys for email use a device unlock or security-key PIN and function as phishing-resistant authentication under FIDO standards, as described by the FIDO Alliance. The provider may still retain a password for recovery, legacy protocols, or account changes, and administrators may require additional controls for high-risk actions. Keep recovery codes, a backup authenticator, and a protected recovery channel, treating those fallbacks as part of the security boundary, because a cyberattacker who captures recovery access bypasses the strength of the everyday sign-in.

What Should Users Do After Losing the Device That Stores Passkeys for Email?

Losing a passkey device or its synchronizing account calls for three actions: use a verified recovery method, remove the lost credential, and audit active access immediately. Sign in from a trusted device with a recovery code, backup security key, password, or provider-approved alternate method. Google's account recovery and passkey instructions recommend managing passkeys from account security settings, while synced credentials require access to the account protecting the credential store. Revoke unfamiliar sessions and OAuth access, replace lost devices, and add another authenticator. Organizations should document this process before enrollment so employees can report loss quickly and recovery controls stay accountable.

Are Most Organizations Already Using Phishing-Resistant Sign-In?

Not yet, despite widespread deployment activity. According to the FIDO Alliance's State of Passkeys 2026, 57% of organizations continue to rely on phishable authentication methods for employees' primary day-to-day sign-in, and 82% describe fully passwordless authentication as an ultimate workforce goal while only 28% have reached it. The practical reading is that availability of passkeys for email and enforcement of them remain different things, and the interval between the two is where cyberattackers still operate. Organizations closing that interval should disable password fallback where operationally practical, register backup authenticators first, and keep behavioral defenses running throughout the transition.

Passwords disappear from the sign-in screen long before manipulation disappears from the inbox. Close that remaining gap with Adaptive Security's measurable, role-based approach to human security readiness.

Book a demo