Someone cannot get past the second factor

Five wrong codes do not lock an account — they end the attempt. What actually blocks people, and the four user meta keys that turn two-factor off for one person.

Intermediate
6 min read
Applies to 2.0

First, the thing most people get wrong

There is no 2FA lockout. Nothing is locked, nothing expires in fifteen minutes, and there is no timestamp to clear.

Five incorrect codes discard the pending sign-in and return "Too many incorrect codes. Please sign in again." The person retypes their password and gets a fresh code. That is the whole of it.

If you came here looking for attrua_2fa_failed_attempts or attrua_2fa_locked_until in the user meta table, stop looking. Neither exists. The attempt count lives with the pending session — attrua_pw2fa_pending — and disappears with it, which is why clearing a cookie does not reset it and why there is nothing in the database to delete.

So if someone reports being "locked out of 2FA", the cause is one of the three below, and none of them is a lockout.

The three real causes

They lost the authenticator, and have no backup codes

The common one, and the only one needing your intervention. The secret lives on their phone; if the phone is gone and the backup codes were never saved, no code they can produce will ever be right.

Remedy: turn two-factor off for that one account, below. They set it up again afterwards.

The emailed code arrived too late, or not at all

An emailed code lives ten minutes, in a transient named attrua_pw2fa_code_{user_id}. A slow mail queue can outlast it, and the code then reads as wrong rather than as expired.

Remedy: the sign-in screen's resend issues a new code and a new ten minutes. If resending never arrives at all, the problem is mail delivery, not 2FA — see checking email delivery.

This is the confusion worth naming: login throttling and the second factor are different mechanisms, and only the first one locks anything.

	Second factor	Login throttling
Counts	wrong codes	wrong passwords
Ceiling	5, fixed in code	your setting, on Security → Login throttling
Consequence	the attempt ends	the identifier is refused for a duration
Where the count lives	the pending session	`{prefix}attrua_login_attempts`
Duration setting	none	`lockout_duration`, optionally progressive

If someone is refused before being asked for a code, it is throttling. Clear it from Security → Login throttling, or by deleting their row:

DELETE FROM wp_attrua_login_attempts WHERE identifier = 'their-username';

Turning two-factor off for one person

Four user meta keys hold everything. Deleting them returns the account to password-only, exactly as the plugin's own "Remove" button does.

wp user meta delete their-username attrua_2fa_enabled
wp user meta delete their-username attrua_2fa_secret
wp user meta delete their-username attrua_2fa_method
wp user meta delete their-username attrua_2fa_backup_codes

# confirm nothing is left
wp user meta list their-username --keys=attrua_2fa_enabled,attrua_2fa_secret,attrua_2fa_method,attrua_2fa_backup_codes

The same thing in SQL, if you have no WP-CLI:

DELETE FROM wp_usermeta
WHERE user_id = 123
  AND meta_key IN (
    'attrua_2fa_enabled',
    'attrua_2fa_secret',
    'attrua_2fa_method',
    'attrua_2fa_backup_codes'
  );

Replace wp_ with your own table prefix, and take a backup first. user_id is the numeric ID, which wp user get their-username --field=ID will tell you.

If the person uses the passwordless authenticator rather than password + 2FA, their backup codes are under attrua_ptl_backup_codes instead. Delete that one too if they are enrolled in both.

If the locked-out person is you

You cannot delete your own meta from a screen you cannot reach, so it is one of these three, in order of how easy they are:

A backup code, if you saved them when you enrolled. Each works once.
Another administrator runs the commands above against your account.
The commands yourself, over WP-CLI or in the database — neither needs you to be signed in to WordPress.

The emergency access link does not help here.

That link — wp-login.php?attrua_emergency=… — stops the redirect to your custom login page and nothing else. Two-factor is applied after WordPress has checked the password, so it still applies on wp-login.php, and you will meet the same code prompt.

It is genuinely the way back when a custom login page is broken. It is not a way past a second factor, and a URL parameter that switched one off would be a worse problem than any lockout.

Whichever route you use, the lesson is the same one and it is worth acting on now rather than later: save your backup codes somewhere outside the site. A password manager entry or a printed note both work; an email to yourself does not, if that mailbox is behind the second factor.

With no link and no access at all, the WP-CLI commands above still work over SSH, because WP-CLI does not sign in.

Reducing how often this happens

Make people save their backup codes at enrolment. The codes are shown once. An account with codes never needs you.
Check the address on file before enrolling anyone whose second factor is emailed. wp user list --field=user_email reads them in bulk.
Watch the audit log — attrua_pro_2fa_attempts_exceeded fires each time five wrong codes end an attempt. Several for one account in a short window is either someone struggling or someone guessing.

Something missing or out of date? Tell support.