My authenticator codes are being rejected. What should I check first?

Confirm your device clock is correct. TOTP codes depend on accurate time, so a phone or computer with drifted time generates codes Awthy rejects even when nothing else is wrong.

I cannot complete the second-factor prompt and have no backup codes left. How do I get back in?

From the login screen you can email yourself a recovery link. It only ever goes to the account's own stored email address, so confirm that address is current and check spam if it does not arrive.

I am told to wait before another recovery email is sent. Is something broken?

No. That is the normal per-account anti-flood pace, not a failure. It clears on its own after a short delay, and a network-wide brute-force slow-down does not block recovery emails.

Troubleshooting

Last verified: 2026-07-08

Most setup and rollout support issues should be handled with calm, repeatable steps.

Common checks

Confirm the user is on the expected WordPress account.
Confirm device time is correct before diagnosing TOTP failures.
Confirm recovery material was stored before enforcement was enabled.
Keep sensitive information out of support forms and screenshots.

Hub claim and managed export connection issues

If a paid install cannot connect to Hub-managed Google Drive or Custd reporting:

Generate a fresh claim code from the Hub account utility. Claim codes expire and can only be used once.
Confirm the user selected the expected Hub account and license before copying the code into WordPress.
If the license has reached its activation limit, decide which install should remain active before trying again.
If WordPress reports a reclaim conflict, the same site is already active under a different Hub account. Support must verify ownership before any transfer; do not share claim codes, cookies, install secrets, Google tokens, or Custd credentials in the support request.

See Hub Connection for the full claim and reconnect workflow.

If a custom login path breaks login access, restore wp-login.php with AWTHY_DISABLE_LOGIN_PATH in wp-config.php or run:

wp awthy login-path disable

Confirm the default login screen works in a private browser window before trying another custom path. See Custom Login Path.

For maintenance commands that bypass browser nonces, see WP-CLI Recovery And Maintenance.

IP access lockout recovery

If an IP access rule blocks legitimate login or admin access, use a trusted server session:

wp awthy ip disable

Review the rule in monitor mode before enforcing it again. See IP Access Rules.

Passkey support

If passkey registration or assertion fails, test with a current browser over HTTPS, confirm the device or password manager allows passkeys, and keep authenticator codes or recovery codes available. See Passkeys.

Geo database setup

If login activity shows missing or stale geo data, confirm the IP2Location token, Hub-managed download state, file permissions under uploads/awthy/geo/, and WordPress cron. See Geo database setup.

Audit export connections

If S3, Google Drive, or managed reporting export fails, confirm entitlement, destination connection state, Hub connection state, and the latest export job error. Do not paste credentials, tokens, claim codes, or raw export payloads into support requests.

See Audit Export Readiness, Hub Connection, and Plans and Entitlements.

If a consent notice is missing, too broad, or out of sync with the site's privacy policy, confirm the selected display style, required categories, optional categories, and retention preview. Awthy records display-safe consent evidence, but legal wording and regional requirements remain the site owner's responsibility.

See Consent Notices.

Stuck at the second-factor prompt

If a user cannot complete the second-factor prompt — lost authenticator, no phone, no backup codes left — they can email themselves a recovery link from the login screen. A few things worth knowing before escalating:

The link only ever goes to the account's own stored email address, so confirm that address is current and that mail is being delivered (check spam and any deliverability issues first).
If they are told to wait before another email is sent, that is the normal per-account anti-flood pace, not a failure — it clears on its own after a short delay.
A network-wide brute-force slow-down does not block recovery emails, so "my office IP is throttled" is never the reason a recovery link will not send.