Passwordless Login and Two-Factor Authentication for WordPress: A Practical Setup Guide

Account compromise tickets tend to follow a pattern: a site owner assumes their login is reasonably secure because their password is “strong,” and nothing else was ever added on top of it. WordPress core gives you less protection here than most people assume, and the pieces that do exist are frequently confused with each other. It’s worth being precise about what’s actually built in versus what needs a plugin before setting anything up.

Two Different Problems, One Login Screen

Passwordless login and two-factor authentication solve different problems and get conflated constantly. Passwordless login — passkeys, WebAuthn — replaces the password itself with something tied to a physical device: a fingerprint, a face scan, a hardware key. Two-factor authentication keeps the password but requires a second, independent factor on top of it, like a time-based code from an authenticator app. They’re not competing approaches; a well-secured account can reasonably use passkeys as the primary method and keep a second-factor option available as backup.

What’s Already Built Into WordPress Core

WordPress 5.6, released in December 2020, introduced Application Passwords — and this is the single most common point of confusion. Application Passwords authenticate external applications and scripts to the REST API on a user’s behalf; they were never built as a login-screen replacement, and they don’t appear as an option on the standard wp-login.php form at all. Someone expecting Application Passwords to add passkey-style login to their site will be looking in the wrong place entirely.

As of 2026, WordPress core still has no native passkey support and no built-in two-factor authentication. Both require a plugin — this hasn’t changed since the feature was first proposed for core years ago.

The Plugin Layer That Actually Handles This

Two plugins cover most of what’s needed, and they’re designed to work together:

• Two Factor — maintained by WordPress core contributors as a feature plugin with eventual core-merge intent, it covers TOTP authenticator apps, email-based codes, and printable backup codes.
• Two-Factor Provider: WebAuthn — a companion plugin that plugs directly into Two Factor’s settings screen and adds passkey and hardware-key support, covering Face ID, Touch ID, Windows Hello, and physical security keys.

There’s reportedly an open pull request aiming to fold WebAuthn support directly into the core Two Factor plugin rather than keeping it a separate install — worth checking each plugin’s current changelog before assuming which state that merge is in by the time you’re setting this up, since it’s an active area of development rather than a settled one.

Why Bother — the Threat Numbers

Wordfence’s own threat intelligence reporting has described blocking billions of brute-force and credential-stuffing attempts across its network on a monthly basis, with AI-driven botnet volume reported as increasing further through 2025. Patchstack’s 2025 vulnerability tracking reportedly logged over 11,000 new WordPress vulnerability disclosures for the year, a sizable jump from the prior year’s count. I’d treat both of those specific figures as the vendors’ own published telemetry rather than something independently audited — but the direction they both point, automated login attacks scaling up rather than down, is consistent across multiple security vendors’ reporting and matches what shows up anecdotally in support tickets about compromised accounts.

A Practical Setup Path

1. Install the official Two Factor plugin and enable TOTP as the baseline requirement for every admin and editor account.
2. Add the WebAuthn companion plugin and register a passkey as the primary sign-in method on any device that supports it.
3. Store backup codes in a password manager, not a text file left on the server or in an email inbox.
4. Avoid SMS-based codes as a primary factor given the well-documented risk of SIM-swap attacks intercepting them.
5. Apply all of this to every account with publish or admin-level capability, not just the main administrator login — a common gap is securing the owner’s account while leaving an editor or shop-manager account with equal capabilities completely unprotected.

A password alone was never really the security model — it just used to be the only piece people bothered to set up, and the plugins that add passkeys and 2FA to WordPress aren’t optional hardening anymore so much as the missing second half of a login system that was always meant to have one.

None of this requires custom development or a security specialist — it’s two plugins and about fifteen minutes per account. The gap isn’t a technical limitation; it’s that WordPress core still treats this as opt-in rather than default, which means it stays undone on most sites until something forces the issue.