Quick Answer
A WordPress application password audit checklist should confirm which users have API credentials, which integration each credential belongs to, whether the site is using HTTPS, whether stale credentials can be revoked, and whether WP-CLI or the REST API can produce an inventory without exposing secrets. The best fit for a small publisher is a quarterly access review that treats application passwords as named integration credentials, not as invisible background settings.
Audit Map
| Review area | What to verify | Better operator decision |
|---|---|---|
| User owner | Which WordPress user owns each application password | Tie every credential to a real maintainer |
| Integration name | Which app, script, plugin, or workflow uses it | Rename vague entries before a handoff |
| Access path | REST API, XML-RPC where enabled, or another API workflow | Keep public notes focused on API ownership, not secret values |
| Site availability | Whether application passwords are available for the site | Confirm HTTPS or local-environment assumptions before troubleshooting |
| Inventory method | User profile, REST endpoint, or WP-CLI list command | Use the least invasive method that answers the audit question |
| Revocation plan | Single credential, all credentials for a user, or user role change | Revoke stale integration access before deleting context |
Who Should Use This Checklist?
Use this checklist when a WordPress site owner, editor-operator, automation maintainer, or small publishing team connects external tools to WordPress through authenticated API access. It fits sites that already review REST API exposure, user roles, webhook signatures, no-code app connections, or general WordPress security hygiene.
This is operational site-maintenance guidance, not legal, privacy, incident-response, professional security, financial, tax, or compliance advice. It does not change WordPress users, server configuration, OAuth clients, Search Console, Bing Webmaster Tools, Google AdSense, payment settings, or private integration accounts. It also does not claim that Yolkmeet inspected a private WordPress dashboard, live credential table, server log, token vault, WP-CLI output, REST response, or third-party integration. The article is source-derived analysis from public WordPress documentation.
The practical issue is straightforward: application passwords are useful because they are named, individually revocable credentials for API access. They become risky when no one remembers why they exist, which user owns them, whether the integration still runs, or how to revoke one password without disrupting unrelated publishing work.
Step 1: Build A Credential Inventory
Official WordPress documentation describes an application password as a password tied to a specific WordPress user account, intended for API authentication, stored hashed, shown only once when created, and individually revocable. That makes the audit boundary clear: every entry needs a user, a name, a purpose, and a revocation owner.
Record one row per application password:
| Field | What to record |
|---|---|
| WordPress user | User account that owns the credential |
| Role | Administrator, editor, author, or custom role |
| Application name | Human-readable name shown in WordPress or WP-CLI output |
| Purpose | Publishing script, editorial tool, mobile app, no-code workflow, monitoring job, or integration |
| Owner | Person or team responsible for the connected workflow |
| Created date | When the credential was created, if visible in the inventory source |
| Last-used signal | Last-used metadata if available to the operator |
| Decision | Keep, rename, replace, revoke, or investigate |
Do not copy the actual password into an editorial document, public article, issue tracker, spreadsheet, or screenshot. WordPress only shows an application password once at creation time; an audit should identify ownership and usage, not preserve secrets.
Step 2: Confirm The Access Model
The REST API authentication handbook explains that WordPress includes application passwords and that they can be generated from the Edit User page. The same documentation describes their use with Basic Authentication over HTTPS for REST API requests. For operators, the important point is not the transport details alone. It is the accountability model: the credential acts as the user that owns it.
Use this access checklist:
- [ ] Confirm the credential belongs to the intended WordPress user.
- [ ] Confirm the user role still matches the integration's job.
- [ ] Confirm the integration requires authenticated API access.
- [ ] Confirm the site uses HTTPS for remote REST requests.
- [ ] Confirm the application name is specific enough for a future operator.
- [ ] Confirm the credential can be revoked without changing the user's main login password.
Avoid creating application passwords under a broad administrator account just because it is convenient. A credential connected to an administrator can inherit more capability than a narrow publishing integration needs. If the integration only creates drafts, updates metadata, or reads content, review whether a lower-privilege user and clearer role boundary would reduce operational risk.
Step 3: Separate User Review From Integration Review
A normal WordPress user-role audit asks whether each person still needs dashboard access. An application password audit asks a related but separate question: which API integrations are attached to those users?
Use this decision table:
| Situation | Better choice | What to avoid |
|---|---|---|
| Active integration with clear owner | Keep and record next review date | Recreating credentials without a reason |
| Unknown app name | Investigate owner before keeping | Treating vague names as harmless |
| Departed user | Transfer workflow first, then revoke stale credentials | Deleting a user before checking connected jobs |
| Temporary migration script | Revoke after migration is complete | Leaving one-time credentials active |
| No-code publishing workflow | Tie to a named service user where appropriate | Sharing one personal admin credential |
| Failed or abandoned experiment | Revoke and document the cleanup | Keeping old credentials for convenience |
This separation matters during handoffs. A user account can remain valid while one application password is stale, and a user account can be removed while an integration still needs a replacement owner. Make the integration decision before changing the account.
Step 4: Use WP-CLI For A Private Inventory When Available
WP-CLI documents the wp user application-password command group for creating, updating, deleting, listing, and retrieving application passwords. The list command can show application password records for a user and can limit fields. That makes WP-CLI useful for a private operator inventory when shell access is already part of the maintenance workflow.
Use WP-CLI only in a private runbook or terminal session, not as public article evidence:
| WP-CLI task | Operator use |
|---|---|
| List passwords for a user | Build an inventory without visiting every profile screen |
| Limit fields | Avoid exposing unnecessary details in exports |
| Retrieve a record | Inspect metadata for a known credential |
| Delete one credential | Revoke a stale integration without changing the login password |
| Delete all for a user | Clean up after replacement and confirmation |
Do not publish terminal output that includes hashes, identifiers, usernames, emails, site paths, hostnames, or private application names. Public content can explain the checklist. Private evidence can stay in the site owner's access-control runbook.
Step 5: Check REST Endpoint Exposure Without Overreacting
The REST API reference includes application password endpoints for retrieving, creating, updating, and deleting application password records. That does not mean every public REST route is automatically a problem. The operator question is whether authenticated actions are tied to the right user, purpose, and revocation process.
Pair this article with a broader REST API exposure review:
- [ ] Public REST responses do not reveal private operational data.
- [ ] Authenticated write actions are limited by WordPress capabilities and roles.
- [ ] Application password owners are reviewed with the same care as dashboard users.
- [ ] Integration credentials are not stored in public repositories, docs, screenshots, or tickets.
- [ ] Retired scripts, mobile apps, and automation tools lose access promptly.
- [ ] REST troubleshooting does not become a reason to disable useful WordPress functionality without diagnosis.
The best decision is measured: keep the REST API available for normal WordPress behavior, limit authenticated access to known workflows, and remove credentials that no longer have an owner.
Step 6: Verify Availability Before Troubleshooting
WordPress developer documentation for wp_is_application_passwords_available() notes that application passwords are available by default for SSL sites and local environments, and that filters can adjust availability. For an operator, this means a missing application-password interface can come from site availability rules, local development behavior, or custom code.
Use this troubleshooting path:
| Symptom | First check | Better next step |
|---|---|---|
| Application password UI missing | HTTPS and site availability | Check site configuration before recreating users |
| Integration stopped authenticating | Credential was revoked, renamed, or replaced | Review the integration owner and recent changes |
| Unknown credential appears | User profile and WP-CLI inventory | Identify purpose before deciding keep or revoke |
| Former maintainer still owns credentials | Handoff record and replacement workflow | Move ownership, confirm the new credential, then revoke old access |
| REST request fails | Authentication method, role capability, and endpoint | Avoid broad role upgrades until the failure is understood |
This keeps the audit from becoming guesswork. A credential issue may be an HTTPS, role, endpoint, availability, or integration-secret problem. Change one variable at a time.
What Should Stay Out Of Public Notes?
Do not publish application passwords, hashes, Basic Auth strings, authorization headers, usernames, emails, user IDs, UUIDs, site paths, REST responses, WP-CLI output, OAuth tokens, plugin secrets, webhook secrets, .env values, screenshots with account identifiers, production URLs for private endpoints, or private integration names.
Public notes can say what the checklist reviews and cite official documentation. Private runbooks can store redacted inventory evidence, owner decisions, and revocation logs.
What Should A Handoff Include?
A WordPress application password handoff should include the credential owner, WordPress user, role, application name, integration purpose, connected tool, private secret-storage location, creation date if available, last-used signal if available, replacement plan, revocation owner, and next review date. The best sequence is inventory first, ownership review second, role review third, replacement credential fourth, live integration check fifth, and old credential revocation last.
Common Questions
Are WordPress application passwords the same as user login passwords?
No. Application passwords are separate credentials tied to a WordPress user account and intended for API authentication. They can be individually revoked without changing the user's main login password.
Should every integration use an administrator account?
No. Choose the lowest WordPress role that can do the required job, then document the integration owner. Administrator-owned credentials should be exceptional and reviewed more often.
Can WP-CLI replace a manual profile review?
It can help build a private inventory when shell access is appropriate, but it should not replace operator judgment. You still need to decide whether each credential has a current owner and purpose.
Does a REST API warning mean application passwords must be disabled?
No. Review the specific risk first. Application passwords can be useful for authenticated integrations when HTTPS, user roles, secret storage, and revocation are handled deliberately.
How often should small publishers review application passwords?
Review quarterly for stable sites and immediately after a maintainer leaves, a no-code workflow changes owner, a publishing script is replaced, a suspicious integration appears, or a REST API credential is rotated.
Source Notes
- https://developer.wordpress.org/advanced-administration/security/application-passwords/ checked 2026-06-11; used for source-derived analysis of what application passwords are, how they are tied to users, one-time visibility, hashed storage, and individual revocation.
- https://developer.wordpress.org/rest-api/using-the-rest-api/authentication/ checked 2026-06-11; used for source-derived analysis of REST API authentication, generating application passwords from the user edit screen, and HTTPS Basic Authentication behavior.
- https://developer.wordpress.org/rest-api/reference/application-passwords/ checked 2026-06-11; used for source-derived analysis of REST application password endpoints for retrieving, creating, updating, and deleting records.
- https://developer.wordpress.org/cli/commands/user/application-password/ checked 2026-06-11; used for source-derived analysis of the WP-CLI command group for creating, updating, deleting, listing, and retrieving application passwords.
- https://developer.wordpress.org/cli/commands/user/application-password/list/ checked 2026-06-11; used for source-derived analysis of private inventory options and field-limited application password listing.
- https://developer.wordpress.org/reference/functions/wp_is_application_passwords_available/ checked 2026-06-11; used for source-derived analysis of application password availability on SSL sites, local environments, and filter-adjusted environments.
No private WordPress dashboard, production REST response, application password, user account, WP-CLI output, server log, plugin settings page, no-code account, webhook payload, credential vault, Search Console account, Bing account, or Google AdSense account was inspected for this article. If a future operator adds account-specific inventory evidence, keep it private and narrow public claims to the documented environment.
Internal Link Notes
Link to wordpress-rest-api-exposure-checklist when the reader needs the broader REST API review. Link to wordpress-user-role-audit-checklist when credential ownership depends on role cleanup. Link to wordpress-security-checklist-for-blogs when the site needs a wider maintenance review. Link to webhook-signature-verification-checklist when an integration receives signed events. Link to no-code-app-connection-hygiene-checklist when application passwords support a no-code workflow.
Update Note
Review this checklist every 60 days. Recheck official WordPress documentation for application passwords, REST API authentication, application password endpoints, WP-CLI application-password commands, and availability behavior. Refresh earlier after WordPress changes credential UI behavior, REST authentication guidance, WP-CLI command options, HTTPS availability assumptions, or Yolkmeet changes its WordPress integration workflow.