A recovery admin account is a second, rarely-used WordPress administrator you keep in reserve for the day the primary login stops working. You can test it without touching your main session by signing in from a separate browser profile, a private window, or a different browser entirely — WordPress stores its login cookie per browser cookie jar, so a second jar holds a second session without evicting the first. That one trick removes the usual reason these accounts go untested: nobody wants to log themselves out of a live site mid-task to find out whether a spare password still works. The rest of the job is knowing what to verify beyond "the password was accepted," and keeping the spare account from becoming the weakest door into the site.
Table of Contents
- What a recovery admin is, and what it is not
- Testing a second login without ending your own session
- What to verify beyond "the password worked"
- The security cost of a standing second administrator
- Fallbacks for when the recovery login also fails
- When to re-run the test
- Frequently Asked Questions
What a recovery admin is, and what it is not
A recovery admin is an ordinary WordPress user with the Administrator role, created ahead of time, with credentials stored somewhere the team can reach during an incident. Nothing about it is special to WordPress — there is no "recovery" role — which is exactly why it has to be tested like any other account. It is not the same thing as WordPress recovery mode, the built-in feature that emails a special login link to the site's admin address when a plugin or theme triggers a fatal error. Recovery mode depends on the site being able to send mail and on someone having access to that one mailbox.
A recovery admin account is the fallback for the broader case: a forgotten password, a departed contractor, a security plugin that locked the main user, or a two-factor device that was wiped. On a multisite network, note the distinction between Administrator and Super Admin. A site administrator cannot install plugins or manage the network. If your recovery plan needs network-level access, the reserve account has to be a Super Admin, and that is a much larger privilege to leave sitting idle.
Testing a second login without ending your own session
WordPress authenticates with a cookie scoped to the site domain. Log into a second account in the same browser and the new cookie replaces the old one for that domain — you are logged out of the first account. Separate cookie storage is what keeps both alive at once.
Practical options, roughly in order of convenience: For sites where the recovery path is programmatic rather than browser-based, WordPress application passwords let you authenticate against the REST API without a browser session at all. An application password is a per-user token used for API and remote requests; it does not log anyone into wp-admin and does not disturb any existing session. A single authenticated request to the users endpoint confirms the credential and the account's identity.
- A private or incognito window. Fastest, isolated cookie jar, closes clean. Extensions are usually disabled, which is itself useful — it shows whether the login works without your browser's password manager filling anything in.
- A second browser profile. Persistent, so you can keep the recovery account's saved bookmarks and notes separate. Chrome profiles and Firefox containers both work.
- A different browser altogether. Zero configuration, and it exercises a different user-agent, which occasionally matters when a security plugin or CDN behaves differently per client.
- A separate device or phone on mobile data. This is the version that also tests whether an IP-based login restriction will block you from an unfamiliar network — the scenario you are most likely to face during a real emergency.
What to verify beyond "the password worked"
A password that is accepted proves less than it looks. The account can authenticate and still be useless at the moment you need it, because capabilities, email, and second factors all fail independently. Work through these on each test:.
- Capabilities, not just the role label. Open Plugins, Users, and Tools → Site Health. A role editor plugin or a `DISALLOW_FILE_MODS` constant can leave an account labelled Administrator with the plugin editor or installer removed.
- The password reset path. Trigger a reset from the login form and confirm the email actually arrives. Sites with broken outbound mail look fine until the day a reset is the only way in.
- The email address itself. If the recovery account uses an address on the same domain as the site, a DNS or hosting failure takes out the site and the mailbox together. Point it at an independent mailbox that more than one person can reach.
- Two-factor enrolment. If the site enforces 2FA, the recovery account needs its own enrolled factor and its own stored backup codes. An account that cannot pass the second step is not a recovery account.
- Login restrictions. Brute-force plugins, allowlisted IP ranges, and custom login URLs all apply to the spare account. Test from off-network so you learn about the restriction now rather than during an outage.
The security cost of a standing second administrator
Every administrator account is a full-privilege target, and a rarely-used one gets watched least. Treat the recovery account as the most sensitive credential on the site, not the most casual. Give it a unique, non-obvious username — never `admin`, `root`, or the site name — and a long random password generated and stored in a shared password manager vault, not a document, a chat message, or a sticky note. Enrol a second factor. If the site runs an activity-log plugin, add an alert on logins by that specific user, because any login you did not schedule is worth an immediate look.
Audit the administrator list on a regular cadence. Over SSH, `wp user list –role=administrator` returns every admin on the site in one line of output; in wp-admin, Users → Administrators does the same. An admin account nobody recognises is one of the clearer signals of a compromise, and you can only spot the extra one if you know the expected set. When a recovery account is retired, remove it rather than leaving it dormant. WordPress asks whether to delete that user's content or reassign it to another user — choose reassignment if the account ever authored anything, or those posts go with it.
Fallbacks for when the recovery login also fails
A second admin account covers most lockouts, but not all of them. If the database is intact and you have server access, WP-CLI works entirely outside the login form: `wp user create`, `wp user update`, and `wp user reset-password` all run as the system user over SSH, with no browser, no cookie, and no email involved. Many managed hosts expose WP-CLI in their control panel even when SSH is not offered. Editing the password hash directly in the database is the method most often repeated in old forum threads, and it is the one to trust least.
WordPress has changed its password hashing over time, so pasting a hash generated by an outdated method may not validate. Generating the value through WordPress itself — via WP-CLI, or a temporary must-use plugin that calls the core password functions — avoids guessing at the format. If you use a temporary drop-in file to restore access, delete it the moment you are back in. A file that creates an administrator on every page load is a backdoor regardless of who wrote it, and it will be found.
When to re-run the test
Tie the test to changes rather than to the calendar alone, because the things that break a spare login are nearly always deliberate changes someone made. Re-test after installing or reconfiguring a security or two-factor plugin, after a host migration or URL change, after any role or capability edit, and after a staff change that alters who holds the vault. A quarterly check is a reasonable floor on a site nobody is actively developing.
The test itself is short: open a private window, log in, load the Plugins and Users screens, request a password reset, confirm the email lands, log out, close the window. Your main session stays untouched the whole time. Write down the result with a date, next to the credentials. The value of a recovery account is knowing it worked recently — an untested one is a plan, not a safeguard.
Frequently Asked Questions
Can I stay logged in as two different WordPress users at once in the same browser?
Not in the same cookie jar. Use a private window, a second browser profile, or a different browser, and both sessions stay alive independently.
Does an application password let someone log into wp-admin?
No. Application passwords authenticate REST API and remote requests only. They are useful for confirming a credential works without creating or disturbing a browser session.
Should the recovery account use the same email address as the main administrator?
No. Use a separate, independently hosted mailbox that more than one person can access, so a DNS or hosting failure does not take out the site and the reset path together.
Is it safer to create the recovery account only when it is needed?
Creating it on demand requires the very access you have lost. Keep it standing, but protect it with a unique username, a vaulted random password, 2FA, and login alerting.
You Might Also Like
- WordPress Maintenance: Google Login Stops Working During an Account Lockout: How to Check Existing Local Admin Access
- WordPress Maintenance: Google Sheets Integrations After Account Restoration: How to Test Permissions Before Resuming Sync
- WordPress Maintenance: Google Calendar Embeds During an Account Outage: How to Check Public and Private Access Separately
