Recovery

Recovery

Last verified: 2026-06-17.

Recovery needs to be understandable before enforcement is enabled. A store owner should know where recovery material is stored, who can use it, and how support should respond before administrators or staff are required to use a second factor.

Emailing yourself a recovery link

If you reach the second-factor prompt and cannot complete it — your authenticator is lost, your phone is flat, or you have run out of backup codes — Awthy can email a recovery link to the address on file for your account. From the login challenge screen, choose to send a recovery email. Here is exactly what happens:

• The link is sent only to the email address already stored for that account. You cannot redirect it elsewhere from the login screen, so a stranger who reaches the prompt cannot point the link at themselves.
• The email never contains your password, a one-time code, or your recovery codes — only a single-use link that expires shortly after it is sent.
• Opening the link signs you in once so you can fix your second factor (re-enrol an authenticator, generate fresh backup codes). It does not turn off your second factor or weaken the account.

Why a recovery request is sometimes asked to wait

Sending a recovery email is rate-limited per account so the feature cannot be abused to flood your inbox ("mail-bombing"). If you request several links in quick succession, Awthy briefly asks you to wait before it will send another. This per-account limit is the only thing that paces recovery emails, and it clears on its own after a short delay.

Crucially, this recovery request is not blocked by the brute-force source-IP slow-down. Repeated wrong second-factor codes — yours or anyone else's — from your network add a growing delay to guessing attempts, but they will not stop you emailing yourself a recovery link. A genuine owner stuck behind a busy shared office or mobile-carrier connection can always reach the recovery escape hatch. The emailed link can only land in the account's own inbox, so exempting it from the network slow-down costs nothing in security while keeping the safe way back in always open.

Managed site recovery

Managed recovery adds a separate owner-approved path for a lost or compromised WordPress site. An account owner with a recent step-up chooses a retained recovery point and a claimed destination in the Hub:

• Replace a lost site requires an empty destination and restores only the portable configuration needed to use the recovery point. The destination generates its own database credentials, paths, URLs, and sessions.
• Repair a hacked site preserves only reviewed portable values, withholds unknown or integration credentials, and rotates WordPress sessions and salts.

The destination performs a local preflight immediately before the mode-bound grant, delivery, and configuration apply. The one-use payload goes directly to the signed install; capsule plaintext is not shown in the browser or written to the WordPress database, logs, or support receipts. A fresh PHP boot may be required before Awthy can validate the new configuration.

The Hub reports one of three outcomes:

• Complete — the selected point, configuration, fresh-boot validation, and cleanup passed.
• Partial — action needed — an unsupported or withheld value needs the listed reconnect or manual action.
• Needs attention — authorization, integrity, expiry, preflight, or cleanup needs operator review.

This managed workflow is enabled per account and environment. Do not treat local or staging proof as a promise that an arbitrary hosting provider, plugin, or dynamic configuration is automatically restorable.

Safe handling

• Do not send recovery codes, authenticator secrets, passwords, private keys, or raw security logs through public forms.
• Store recovery codes somewhere separate from the WordPress admin account.
• Test recovery with a non-critical account before depending on it for production rollout.
• Confirm the last administrator has a recovery path that does not depend only on a logged-in WordPress dashboard.
• Check email deliverability before relying on email-assisted recovery messages.

Test email recovery before enforcement

Before requiring 2FA for administrators, staff, or customers, use a non-critical account to prove the email recovery path end to end:

1. Confirm the account has a current email address that the owner can access.
2. Trigger the Awthy recovery email test or recovery request from the account-security flow.
3. Confirm the message arrives, the link opens on the expected site, and the user can return to account security to fix their factor.
4. Check spam filtering, transactional-email plugins, and host mail logs if the message does not arrive.
5. Record only the result, not the link, token, recovery codes, or mailbox contents.

Do not treat recovery as ready just because the dashboard says email recovery is configured. Enforcement should wait until a real message has been delivered and opened successfully.

Support boundary

Support should help users understand the recovery flow, but it should not ask for sensitive secrets or bypass account ownership checks.

Support can explain where recovery starts, which account owner needs to approve a reset, and what evidence is safe to provide. Support should not publish a generic bypass, accept recovery codes over chat, or treat a remembered browser as proof of ownership.

Enforcement checklist

Before stricter 2FA or customer-account controls are enabled:

• Recovery codes have been generated and stored by critical users.
• At least one non-critical account has tested the recovery flow.
• The support desk knows which details are prohibited.
• The owner has decided how last-admin lockout, email delivery failure, and lost-device cases are handled.
• WooCommerce customer, checkout, and payment-adjacent flows have been tested before any customer-facing enforcement claim is published.