The New Best Practice for Phishing-Resistant Login Security (2026)

The best-practice shift: from “MFA everywhere” to “phishing-resistant by default”

For years, the baseline advice was “turn on MFA.” In 2026, the more useful best practice is mandate phishing-resistant authentication for high-value access and pair it with device-bound sessions to blunt post-login token theft.

That shift is driven by two realities:

• Stolen credentials remain a dominant ingredient in breaches, especially for web apps. Verizon’s DBIR highlights that in the Basic Web Application Attacks pattern, about 88% of breaches involved stolen credentials.

• Attackers increasingly bypass or “work around” weak MFA (SMS, basic push prompts) using phishing kits, adversary-in-the-middle (AiTM) techniques, and session theft—so organizations need controls that remove the phishable secret entirely.

What is phishing-resistant MFA?

What is phishing-resistant MFA? Phishing-resistant MFA is authentication that remains secure even if a user is tricked into interacting with an attacker-controlled site, because credentials are cryptographically bound to the legitimate service (origin/domain) and can’t be replayed elsewhere. Standards like FIDO2/WebAuthn are designed to provide this property.

In practice, phishing-resistant MFA is usually implemented as:

• FIDO2/WebAuthn passkeys (platform or roaming security keys)

• Certificate-based authentication (common in enterprise and government)

• Strong, origin-bound methods enforced through a modern IdP and conditional access

CISA explicitly recommends moving toward phishing-resistant authenticators (e.g., FIDO2/WebAuthn) to counter modern credential phishing and MFA bypass.

What is a passkey?

What is a passkey? A passkey is a FIDO credential (public/private key pair) used for sign-in where the private key stays on the user’s device and the server stores only the public key. Because it’s bound to the service’s domain (relying party ID), it’s inherently resistant to classic phishing and replay.

There are two common forms:

• Platform passkeys: stored in a device’s secure hardware/OS keystore (e.g., phone/laptop). Great user experience.

• Roaming passkeys (security keys): external hardware (USB/NFC/BLE). Strong choice for admins, shared workstations, and higher assurance needs.

Why is phishing-resistant authentication important?

Why is phishing-resistant authentication important? It reduces the effectiveness of the most common account takeover paths by removing phishable shared secrets and preventing credential replay on attacker infrastructure. It also makes many AiTM phishing flows far harder because the authenticator verifies the real relying party before completing authentication.

It also improves operations: fewer password resets, fewer lockouts, and (when implemented correctly) less user friction than “password + OTP.”

The “new” twist: device-bound sessions to stop cookie and token theft after login

Passkeys harden the login moment. But modern attackers also target what happens after authentication: stealing session cookies/tokens via infostealers, endpoint compromise, or browser data theft.

That’s where a newer control is emerging: Device-Bound Session Credentials (DBSC).

What is Device-Bound Session Credentials (DBSC)? DBSC is a browser and identity security approach that ties session credentials to a specific device using cryptographic keys, aiming to make stolen cookies or session material far less useful off-device. It’s designed to reduce account takeover even when attackers manage to extract session artifacts.

Google has been rolling out passkey support broadly for Workspace and highlighting DBSC as an additional layer to protect sessions post-sign-in.

How does passkey authentication work?

How does passkey authentication work? During registration, a user’s authenticator creates a unique key pair for a specific service (domain). At login, the service sends a cryptographic challenge; the authenticator signs it only after user verification (PIN/biometric). The server validates the signature with the stored public key—no password is transmitted or shared.

This origin binding is the core reason passkeys resist phishing: the authenticator won’t sign challenges for look-alike domains.

A quick comparison table: common “MFA” methods vs. phishing resistance

CISA’s guidance is clear that FIDO2/WebAuthn is in the phishing-resistant category, unlike SMS and many OTP/push approaches.

What are the risks of rolling out passkeys and device-bound sessions?

What are the risks of rolling out passkeys and device-bound sessions? The biggest risks are rarely cryptographic—they’re operational: weak account recovery, incomplete app coverage, legacy protocols, and “exception sprawl” (service accounts, break-glass users, and unmanaged devices). Attackers often pivot to these gaps when primary authentication is hardened.

Key pitfalls to plan for:

• Account recovery becoming the new weakest link (help desk social engineering, insecure fallback factors).

• Legacy auth protocols (IMAP/POP, older VPNs, on-prem apps) that don’t support modern controls.

• Shared-device scenarios (kiosks, call centers) where platform passkeys need special handling.

• Device trust assumptions: device-bound sessions are only as good as your endpoint posture.

What are the best practices for deploying passkeys in an enterprise?

What are the best practices for deploying passkeys? Start with high-risk users and high-impact apps, enforce phishing-resistant methods via conditional access, harden recovery, and measure adoption. Treat passkeys as a program (identity + endpoints + support), not a toggle.

A practical rollout sequence that works well in most organizations:

1. Inventory authentication paths

   • List your IdP-backed apps, legacy apps, VPN/VDI, admin portals, SaaS consoles, CI/CD, and break-glass accounts.

2. Pick two “gold standard” authenticators

   • Platform passkeys for most users; roaming security keys for admins and sensitive roles.

3. Enforce with policy, not advice

   • Conditional access rules that require phishing-resistant authentication for: admin actions, payroll/HR, finance, source code, customer data, and remote access.

4. Harden recovery

   • Eliminate easy fallbacks (SMS reset links, email-only resets). Require stronger recovery verification and alerting for recovery events (NIST emphasizes lifecycle events and recovery as critical).

5. Define exception handling

   • Time-bound exceptions, documented compensating controls, and periodic review.

6. Operationalize telemetry

   • Track enrollment %, phishable MFA usage, recovery events, and “legacy auth” usage.

Microsoft’s guidance for planning phishing-resistant passwordless deployments can help structure prerequisites and staged enforcement.

Configuration patterns that make this “interesting” (and effective)

This is where many programs level up from “we enabled passkeys” to “we measurably reduced takeover risk.”

Pattern 1: Step-up phishing-resistant auth for risky actions

• Require passkey (or security key) for privilege elevation, new device registration, payout destination changes, and API token creation.

Pattern 2: Admin-first mandate

• Enforce roaming security keys for:

  • Identity admins

  • Cloud console admins

  • Endpoint management admins

  • CI/CD and secrets management admins

Okta and others have been emphasizing mandating phishing-resistant MFA for sensitive access as organizations move from “best practice” to “new standard.”

Pattern 3: Pair passkeys with device-bound sessions

• Use DBSC (where available) and complementary controls:

  • Device compliance checks

  • Shorter session lifetimes for unmanaged devices

  • Token binding / continuous access evaluation features in your IdP

Google has positioned DBSC as a direct response to post-login takeover via session material theft.

How does this reduce real-world attack chains?

Attackers commonly chain: phish credentials → bypass weak MFA → steal session → persist.

With passkeys, the initial phishing step is dramatically less useful because there’s no password to steal and replay, and the authenticator validates the intended relying party.

With device-bound sessions, stealing a cookie/token becomes less valuable off-device, which targets the “infostealer and session theft” stage directly.

Operational guardrails: help desk, recovery, and “break-glass” accounts

What are the risks of account recovery in a passkey rollout? Recovery becomes a prime social engineering target because attackers can no longer rely on password phishing. If recovery allows weak factors (SMS/email-only) or permissive help desk resets, attackers will pivot there. Strong recovery needs identity proofing, verified device checks, and high-signal notifications for recovery events.

Recommended guardrails:

• Dedicated, audited recovery process for privileged accounts.

• Two-person approval (or manager approval) for high-risk resets.

• Out-of-band user notifications and delays for sensitive changes.

• Break-glass accounts:

  • Kept offline where possible

  • Protected with hardware keys stored securely

  • Tested regularly

  • Excluded from day-to-day use

Metrics that prove the program is working

If you can’t measure it, exception sprawl will quietly undo your gains.

Track:

• % of users enrolled in passkeys (by cohort: admins, finance, engineering)

• % of sign-ins using phishing-resistant methods

• “Legacy auth” sign-ins remaining

• Recovery events per month and recovery fraud attempts

• Confirmed ATOs and their root causes (recovery vs endpoint vs OAuth consent abuse)

Industry reporting shows both MFA adoption and phishing-resistant authenticator usage increasing, which can be useful for benchmarking your progress.

Future trends: what to expect next

Three developments are likely to accelerate this best practice through 2026–2027:

• Broader passkey support and admin tooling across major identity providers and platforms.

• More controls aimed at post-login security (device-bound sessions, token theft resistance, continuous re-evaluation).

• Stronger standards alignment as guidance like NIST Digital Identity Guidelines evolves to reflect modern authenticators and their lifecycle risks.

A simple policy template you can adapt

If you want a practical “new best practice” statement to drive alignment:

• Policy: All privileged access and all access to high-impact systems must use phishing-resistant authentication (FIDO2/WebAuthn passkeys or equivalent).

• Session protection: For managed devices, enable device-bound sessions where supported and require compliant endpoints for persistent sessions.

• Fallback: Legacy MFA methods (SMS, basic push) are prohibited for privileged access and may only be used for low-risk, time-bound exceptions with compensating controls.

This aligns with CISA’s direction toward phishing-resistant MFA and the broader industry move toward passkeys as a default, not an option.