WordPress application passwords let an app connect as a WordPress user without using that person’s normal login password. To end a retired app’s access, revoke its application password on the relevant user profile. Changing the person’s login password is not the same operation.
That distinction matters when an agency leaves, a publishing tool is replaced or a forgotten integration appears during a handover. The aim is to close the right connection without stopping another service or deleting the user’s content. Start by identifying the account and the job behind the credential.
Which password are you actually retiring?
Core application passwords authenticate API requests, not interactive wp-admin logins. WordPress’s application-password handbook explains the separation. A connected tool can act with the user’s permissions; the friendly name you give its password does not restrict those permissions.
| Access you want to stop | Control to review | Keep separate |
|---|---|---|
| A retired app using a core application password | That credential on the relevant WordPress user profile | Other credentials belonging to the same user |
| A person’s browser access | Their account, login security and active sessions | API credentials and external hosting access |
| A WooCommerce REST API integration | WooCommerce’s own API-key controls | Core application passwords are not the same key system |
| A vendor’s remote-management connection | The specific vendor’s connection and revocation instructions | Removing a core app password does not prove that vendor access ended |
For example, WooCommerce documents its separate REST API keys. An UpdraftCentral connection has its own incident and recovery instructions, covered in our UpdraftCentral incident guide. Do not turn one successful revoke into a claim that every route into the site is closed.
Find the correct user’s application passwords
Sign in directly to the intended WordPress site over HTTPS. Open Users > Profile for your own account. An authorized administrator reviewing another account can use Users > All Users > Edit. Find the Application Passwords section.
Review the application name, creation date and available usage information. You are looking at credentials for that profile, not a complete sitewide inventory. An empty list under your own name does not establish that another user’s integrations are absent.
Match each relevant entry to a business owner, tool and required job. Keep that access register private and record labels rather than secret values. A name such as Old publishing tool is a clue, not proof of who created it or whether it is safe.
If the section is missing, ask the site administrator to check feature availability, HTTPS detection and the site’s security policy. Do not disable a firewall, security plugin or authentication protection merely to make the panel appear.
Read Last Used as a clue, not an audit log
WordPress core deliberately limits how frequently it records application-password activity. Its usage-recording function skips a new write when the previous recorded use is less than a day old. The displayed time and IP are therefore not a request-by-request history.
A monthly reporting job may look quiet for several weeks. A familiar IP can belong to shared infrastructure. Neither an old timestamp nor an unfamiliar IP alone tells you whether to delete the credential. Compare the tool’s schedule, responsible person and existing logs before an ordinary retirement decision.
If nobody can explain an entry and you suspect unauthorized access, preserve the visible details and relevant logs privately, then arrange containment with the responsible specialist. Do not leave credible unauthorized access active while waiting for a convenient maintenance window.
Revoke one retired integration, not every connection
For a planned retirement, agree which job may stop and when. Then use this narrow sequence:
- Confirm the intended site, user profile and application label with the person responsible for the tool.
- Record the entry’s non-secret identifying details and the dependent job in your private handover record.
- Select Revoke beside that specific credential and confirm the intended action.
- Refresh the profile and confirm that the entry is no longer listed.
- Check the retired tool’s authenticated connection and verify that the unrelated integrations you meant to keep still work.
The profile’s Revoke all application passwords control is broader: it removes that user’s application passwords, not every user’s credentials across the whole site. The native delete-all method explicitly takes a user ID. Do not choose it simply because one app has finished its work.
A public homepage still loading is not a useful revocation test. Public pages can remain available without authentication. Have the integration owner verify an operation that actually requires its credential, without publishing content, sending messages or making transactions as an unapproved test.
A worked handover: keep reporting, retire publishing
Imagine a service business with a monthly reporting connection and an old publishing connection under the same WordPress user. The business is replacing the publishing tool but keeping reporting. This is a hypothetical example, not a client incident or a test performed on this website.
Changing the user’s ordinary password does not complete that handover. In the standard core implementation, the normal password setter updates the login password, while application passwords have their own storage and revocation controls. Plugins can add behavior, so verify your site’s actual result.
The owner first confirms which label belongs to the old publishing tool. They revoke only that entry, verify that the retired tool can no longer authenticate, and retain the reporting entry. They also check the reporting job when it is due. The record now names the surviving tool, its owner and its next review, without containing a password.
If the wrong credential is revoked, do not expect to recover its original value. Restore required access through a newly approved credential and securely reconnect the legitimate tool. Revocation is not an undoable pause. If the credential may have leaked, never reconnect using the old secret.
Separate a credential from its permissions
Creating a password named Read-only reports does not make an administrator account read-only. Review the actual user’s role and the integration’s authorization checks. WordPress documents these boundaries in its roles and capabilities guide.
Use a separately owned account with only the capabilities the agreed job needs. A connector may add its own limits, but confirm those limits rather than assuming its interface enforces them. For AI tools, the AI-agent permissions guide covers tool scope, staging and human approval. This article addresses the credential’s lifecycle, not permission to connect a new agent.
Finish the access review, not just the button click
Application-password retirement does not remove hosting users, SSH keys, separate vendor tokens or information a tool already copied. During a normal provider change, use the wider maintenance onboarding checklist to keep those responsibilities visible.
If there are unexplained users, altered files or other signs of compromise, stop treating this as ordinary housekeeping. Follow a scoped hacked-site recovery process. Revoking a credential can contain one path; it does not reverse changes already made or prove the site is clean.
For an ordinary handover, Webless’s WordPress maintenance work is the relevant place to discuss the access map and verification plan. Share the affected integration and the outcome you need, not passwords, API keys or full logs in an initial enquiry.