WordPress application passwords: find, limit and revoke them
WordPress application passwords are how many tools sign in to a site: a publishing app, a deploy script, a connector for an AI assistant. Each one is a separate password for one tool, and WordPress gives it no expiry. On a site that has been running a while, they pile up.
Nothing in WordPress lists them across accounts, so a forgotten one can sit there for years. This guide explains what they are, how BetterShield finds the unused ones, how to revoke an application password, and the controls for the ones you keep.
Quick summary
- An application password belongs to one account and signs in over the REST API or XML-RPC. In BetterShield’s words, it “signs in without the second factor, by design.”
- The audit flags Application passwords that nothing has used for months: unused for 90 days, counted from creation if never used. It is Low.
- BetterShield › Agents › Surface lists every account’s application passwords in one place, with when each was last used.
- You can hold one to certain REST routes or a network, retire unused ones automatically, or refuse them for site managers.
- BetterShield’s own AI assistant connection does not use application passwords. It has its own credential.
What WordPress application passwords are
An application password is a long generated password you create under your profile, named for the tool that will use it. WordPress shows it once and keeps only a hash of it. The tool then signs in with your username and that password, and gets everything your account can do.
Three things make them different from your main password:
- They skip the second factor. Two-factor sign-in applies to people at the sign-in page. A request signed in with an application password goes straight through, which is what keeps integrations working.
- They do not expire. One made for a tool you stopped using still works.
- They are per tool. Each can be revoked on its own without changing your main password.
WordPress also requires HTTPS for them on most sites. If they are unavailable, BetterShield’s fix for them says so.
How assistants and tools sign in with them
The audit puts it simply: “Application passwords are how connected tools and AI agents sign in.” Many connectors for AI assistants, and many publishing and deployment tools, call the WordPress REST API with one.
BetterShield’s own MCP server is the exception. An assistant connected under BetterShield › Agents › Connect uses its own Connection credential, shown once, or signs in through the browser and appears under Connected apps. Rotate replaces that credential, Disconnect and Revoke end access, and none of it is an application password. See Connect an AI assistant.
The audit check for unused application passwords
Application passwords that nothing has used for months sits in the Access area at Low severity and costs 3 points while open. It counts a password as stale once nothing has used it for 90 days, and one that was never used counts from the day it was made.
Its Why it matters says: “One that nothing has used for ninety days is a live credential with no live purpose.” Its What could break is honest about the risk of cleaning up: “any integration secretly relying on one.”
The finding carries counts only: how many accounts and passwords. Its link, Open the agent surface, shows which ones. All the checks are on the checklist.
See every application password on one screen
BetterShield › Agents › Surface has an Application passwords section. Each account that holds one is listed with its role, how many it has, and a stale chip once one has gone 90 days unused. Under each account, every password shows its name and “created … · last used …”, or “created … · never used”.
This is the list to read before you revoke anything. A password named for a tool you no longer run is an easy decision. One you do not recognize is worth asking about first.
How to revoke an application password
Revoking is done in WordPress itself:
- Open Users › Profile, or the account’s edit screen if you manage other users.
- Scroll to Application Passwords.
- Press Revoke beside the one to remove. Revoke all application passwords clears every one on that account.
From the terminal, wp user application-password list <user> lists an account’s passwords with their IDs, and wp user application-password delete <user> <uuid> revokes one.
A revoked application password cannot be brought back, because WordPress never stored the password itself. Whatever used it will need a new one. The activity log records each revocation as “Application password revoked”, with its name.
Retire unused application passwords automatically
On Agents › Surface, Retire application passwords that have gone unused removes them on a daily sweep once they pass Unused for (days). It is off by default, the number defaults to 180, and the lowest you can set is 30.
The screen says what this means: “This is the one thing here that cannot be undone.” Each retirement is logged with the password’s name, so whoever owned it knows which to make again. The sweep never removes the credential the request is running on, or BetterShield’s decoy.
Limit the application passwords you keep
Each password on Agents › Surface has Limit…:
- REST routes it may use: route prefixes, such as
/wp/v2/posts. Empty means every route. - Network it may be used from: an address or a range, such as 203.0.113.0/24. Empty means anywhere.
Press Save limit. Until then the line reads Reaches everything its account can, from anywhere. A request outside the limit is refused and logged as “Application password refused outside its limit”. Remove limit takes it off, and an Undo is offered right after each change.
Refuse application passwords for site managers
If your administrators never need them, Refuse application passwords under Signing in on BetterShield › Protect › Login & Access turns them away. Who this applies to has two choices: Accounts that can manage this site (preselected) or Every account.
Nothing is deleted. The passwords stay on their accounts, are refused while the fix is on, and work again when you turn it off. The fix also hides the profile section that issues them, for the accounts it covers.
Before applying, Preview the change says how many site managers hold one, and reads your activity log: “Something used this on 5 separate hours in the last 30 days, most recently 2 hours ago.” Monitor first can count real application password sign-ins for an hour, a day or a week before you enforce. Details are in the Hardening guide.
What else BetterShield does around them
- Activity log. Each password created, revoked or used appears in the log. Use is recorded at most once an hour per password, so a busy connector does not flood it. See Activity log.
- Alerts. A new application password on an administrator or editor account is rated High and emailed as it happens.
- Sign-in limits. Wrong application passwords count toward the attempt limit on Login & Access.
- Two-factor. An account with two-factor cannot use its main password over XML-RPC; it needs an application password instead.
- No weakening by token. Undoing a fix, loosening login protection, ending sessions or turning off someone’s two-factor is refused with “This can only be changed from a signed-in browser session, not through an application password.”
- Decoy. Keep a decoy credential on my account adds an application password nobody is given. Any use is refused, logged as Critical and alerted.
Common mistakes
- Revoking everything at once. Read the list first. A tool that mattered stops working, and its password cannot be restored.
- Treating “never used” as safe to keep. A password made and never used is the most common kind of forgotten one, and the audit counts it from creation.
- Turning off two-factor to fix a tool. The tool needs an application password, not a weaker sign-in.
- Refusing them for every account without checking. A store or membership integration may sign in as an ordinary account. Start with Accounts that can manage this site.
Frequently asked questions
Do application passwords bypass two-factor authentication?
Yes, by design. Two-factor applies to people signing in at the sign-in page. Turning on two-factor in BetterShield leaves your existing application passwords working.
How do I revoke an application password in WordPress?
Open the account under Users, scroll to Application Passwords and press Revoke beside it. Or run wp user application-password delete <user> <uuid>. A revoked one cannot be restored.
Does BetterShield delete application passwords on its own?
Not unless you choose it. Retire application passwords that have gone unused, off by default, removes unused ones daily. An incident’s response plan can revoke an account’s recent application passwords when you tick that action and confirm, and with Ultra, Automatic incident response can do the same for the action types you select. Refuse application passwords never deletes any.
Can I see which application passwords are still in use?
Yes. Agents › Surface shows when each was last used, and the activity log records “Application password used” at most once an hour for each one.
Conclusion
WordPress application passwords are useful, and they last until someone removes them. Look through Agents › Surface, revoke what nothing uses, limit what you keep, and let the audit tell you when another one goes quiet.
BetterShield is free on WordPress.org. For assistants, read WordPress MCP: connecting an AI assistant to your site safely.