
Sigil protects WordPress sign-in with passkeys, authenticator apps, backup codes and email codes. Anyone with a passkey can sign in with Face ID, Touch ID, Windows Hello or a security key and skip the password. Administrators can require a second factor for chosen roles, and a short setup wizard gets the first administrator enrolled before anything is enforced.
The login screen shows a “Sign in with a passkey” button, and browsers that support it offer saved passkeys in the username field. A passkey pairs the device you hold with your fingerprint, face or device PIN, so it counts as the full sign-in on its own. Older security keys that can’t store a passkey keep working as a second factor after the password. Passkeys need PHP 8.0 or newer.
Wrong passwords are counted per account and per IP address, across wp-login.php, XML-RPC, the REST API and AJAX login forms. After five wrong passwords, password sign-in for that account pauses for 15 minutes, and repeat pauses get longer, up to an hour. A passkey still signs the owner in during a pause, and the refusal looks the same whether or not the account exists. Sites that already run another limiter can switch this one off.
Put [sigil_2fa] on any page and users can set up and manage their methods there. Enforcement sends people to that page instead of to an admin screen they can’t open. On WooCommerce stores, customers manage two-factor authentication from a tab in My Account.
Accounts are network-wide in WordPress, so second factors are too. An authenticator or backup codes cover every site on the network, the policy is set once under Network Admin, and wrong second-factor codes are counted across the network. Resetting another user’s 2FA is a Network Admin action there, which is how WordPress governs user editing on a network.
Passkeys are bound to the domain they were created for, so by default a passkey covers the site it was registered on. A network under one operator can widen that to every subdomain site with the sigil_rp_id filter. It’s opt-in because widening lets any site under that domain request passkey sign-ins, which matters when sites have different administrators.
A decoupled front end can handle sign-in itself through routes under sigil/v1. They run the passwordless passkey sign-in and the login challenge, read, reset or remove a user’s methods, and read and edit the policy. The challenge routes are authenticated by the token issued after the password step. Everything else needs the same capability as the matching screen.
Several ways back in if a second factor is lost:
edit_users capability can reset another user’s 2FA from the Users screen.wp sigil reset <user> clears a user’s second factor from the command line when nobody can reach the dashboard.wp sigil unlock <user> [--ip=<address>] [--challenge] reopens password sign-in for an account paused by too many wrong passwords.Two-factor authentication doesn’t apply to application passwords, which authenticate REST API and XML-RPC requests. The settings screen explains this, and application passwords can be disabled per role. The account password itself is refused on XML-RPC and REST for anyone with a second factor, because those requests never reach the second step.
assets/js/vendor/qrcode.js (https://github.com/kazuhikoarase/qrcode-generator). Draws the authenticator QR in the browser.vendor/, used to verify passkey registrations and assertions.Neither contacts an external service.