Audit WordPress Application Passwords Before 7.2 Ships

An application password audit means listing every application password on your WordPress site, checking when each one was last used, and revoking the ones nobody can explain. You can do it from Users, then Edit User, in the Application Passwords section, or with WP-CLI in a few commands. On most small sites the listing part is a short task.

Here is a scene I see a lot. Someone scrolls to the bottom of their profile page in wp-admin and finds a small table called Application Passwords, full of entries nobody remembers making. One is called "test". Another was last used two years ago.

That table matters more right now because WordPress 7.2 is targeted for early December 2026, according to the WordPress roadmap post, and that post lists a round of hardening and UX work for Application Passwords. The same post says the listed items may not all ship, so do not plan around any of them.

By the end of this guide you will have a written list of every application password on your site, you will know which ones are stale, and you will be able to revoke the dead ones without breaking the apps you still need.

What an application password is, in plain words

An application password is a separate password that WordPress creates for one app, so that app can talk to your site without knowing your real login password. Think of it as a spare key you cut for one app: you can take that one key back later without changing the locks on the whole house.

A few facts from the official Application Passwords integration guide are worth knowing. The feature arrived in WordPress 5.6. Each generated password is 24 characters long, and it can be typed with or without the spaces WordPress shows.

Apps use these passwords with the REST API (the part of WordPress that answers requests from other software) or with XML-RPC (an older remote-access system). For the REST API, the password is sent with HTTP Basic Auth, which simply means the username and password travel with each request, so it must go over https://.

You cannot use an application password to log in at wp-login.php. They are meant for programs, not people.

Why this matters: each password belongs to a user. When the integration guide was written, it described limiting a password to certain actions (called scoping) as future work, and nothing I opened today says that has changed. So treat every application password as carrying the full power of the account it sits under. A password on an administrator account is an administrator key.

Before you start

Run through this checklist before you touch anything:

• Administrator access to wp-admin, so you can open other users' profiles.
• WP-CLI access if your host gives you SSH (a secure command line on the server). This is optional, but it makes the audit much faster on sites with many users.
• A fresh backup of the database and the files. The steps below show the database command.
• A list of the apps and services that connect to your site, such as a mobile app, a publishing tool, a sync service or a custom script. Write down who owns each one.
• A staging copy (a private test copy of the site) if you want to rehearse a revoke first. My guide on how to test the WordPress 7.2 beta on staging covers setting one up.
• Time needed: a short task to list everything, plus however long it takes to get answers from app owners.
• Risk level: listing is read only and safe. Revoking is permanent and will stop the app that uses that password.

If you have SSH and WP-CLI, this command exports the database to a .sql file in the current folder.

wp db export

You should see a line like Success: Exported to 'wordpress_dbase-db72bb5.sql'. with your own database name. The default file name follows the pattern {dbname}-{Y-m-d}-{random-hash}.sql. Move that file somewhere outside the public web folder and download a copy. For files, use your host's backup tool or download the wp-content folder.

Heads up: if WP-CLI stops with Error: YIKES! It looks like you’re running this as root., do not force it. The WP-CLI handbook explains that running as root lets any plugin or theme code take control of the server. Log in as the site's own user instead.

Find every application password on the site

Application passwords are stored per user, so the audit has two halves: list the users, then list each user's passwords.

Step 1: Find every user who can log in

Every user profile has its own Application Passwords section, and the integration guide says a user's application passwords can be managed by anyone with permission to edit_user them. So check everyone, not only admins.

This command lists every user with their ID, login name and role.

wp user list --fields=ID,user_login,roles

You should see a table with one row per user. Note the ID numbers, because the next commands use them.

To see only administrators, which is where you should look first, run this command.

wp user list --role=administrator --format=csv

On a multisite network, this command lists the user IDs for the whole network instead of a single site.

wp user list --network --field=ID

In wp-admin, the same list lives at Users, then All Users. You can filter by role with the links above the table.

Step 2: List the passwords for one user

The WP-CLI application-password command lists, creates, updates and deletes these passwords. Here we only list.

This command shows the passwords for the user with ID 2, with the ID, name, creation time, last use time and last IP address of each.

wp user application-password list 2 --fields=uuid,name,created,last_used,last_ip

You should see a table. Each row is one password. The uuid is a long unique ID such as 6633824d-c1d7-4f79-9dd5-4586f734d69e, and you will need it to revoke that password later.

The created and last_used values are Unix timestamps, which are dates written as a count of seconds since 1970. A free online timestamp converter turns them into a normal date, or you can read the dates on the admin screen in Step 4.

Quick tip: I left the password field out on purpose. The official list command page shows an example with --fields=name,password, and that field prints the stored hash (a scrambled version of the password). It is not the password itself, but there is no reason to copy it into your notes or a ticket.

If you only want the number of passwords a user has, this command prints a single count.

wp user application-password list 2 --format=count

Step 3: List every user's passwords in one go

On a site with many users, a small loop saves time. This command goes through every user ID, prints the ID as a header, and lists that user's passwords with the oldest last use first.

for id in $(wp user list --field=ID); do echo "User ID: $id"; wp user application-password list "$id" --fields=uuid,name,created,last_used,last_ip --orderby=last_used --order=asc; done

You should see a "User ID" line for each user, followed by a table of passwords, with the stalest at the top.

Heads up: if you save this output to a file by adding > app-passwords-audit.txt at the end, remember it contains IP addresses and the names of your integrations. Keep it private and delete it when the audit is done.

Step 4: Check the same list in wp-admin

Go to Users, then All Users, hover over a user and click Edit. On your own account you can use Users, then Profile. Scroll down to the Application Passwords section.

You should see a table with the columns Name, Created, Last Used, Last IP and Revoke. Dates appear as a month, day and year. A password that has never been used shows a dash in the Last Used column instead of a date.

Quick tip: if you work with developers, the REST API also exposes these passwords at /wp/v2/users/USER_ID/application-passwords, where USER_ID is a placeholder you replace with the real numeric ID of the user, such as 2. The official reference page shows the path with a stray closing parenthesis after the user ID placeholder, so copy it from here, not from there.

Decide which passwords are stale

Now sort each entry on your list.

A password is a likely keep when its name clearly matches an app on your list and it has a recent Last Used date.

A password goes on the ask pile when the name is vague (like "test", "app" or a person's first name), when it sits on an account that belongs to someone who left, or when you simply do not recognise it.

A password is a strong revoke candidate when it has never been used, or has not been used in months, and its owner agrees it is no longer needed. My own rule of thumb is to question anything unused for 90 days, but that number is my habit, not a WordPress rule.

Heads up: the integration guide says the Last Used value is accurate to within 24 hours. WordPress only records a new use once per day, to avoid writing to the database on every request. So a password used this morning may still show yesterday's date. That is normal.

How to find the app behind a password

WordPress does not tell you which app holds a password. It only shows the name someone typed when they created it. To match a password to an app, try these:

• Ask the developer, agency or freelancer who set up the integration. They usually know exactly which name they used.
• Open the settings screen of each connected app or service and look for the site connection or account section. It may show the username the app connects as.
• Check the account the password sits under. A password on a former contractor's account is a strong hint.

Some apps use the official Authorize Application screen in wp-admin, and the integration guide says they can send an app_id, a unique ID the developer uses to find their own passwords. If an app owner tells you their app_id, you can filter by it with --app_id= on the list command.

A made-up example

Here is a made-up scenario to show the thinking. Sara runs a small bakery site. Her audit finds four passwords on her admin account: "Phone posting", "sync-old", "test" and "Ravi". (Sara, Ravi and these names are invented for this example.)

"Phone posting" was used yesterday and she posts from her phone every day, so she keeps it. "Ravi" belongs to a freelancer who built her order form two years ago and has not been used in fourteen months. She messages Ravi, he confirms he no longer needs it, and she revokes it. "test" has never been used, nobody claims it, and she revokes it after a week of asking. "sync-old" is still in use every day, but nobody is sure what it is, so she leaves it alone and keeps asking.

Daily use plus no owner is exactly the case where you must not guess.

Revoke the passwords you no longer need

Revoking is permanent, and the app using that password stops working. Do this only after the backup and after the owner agrees, or after you have asked and waited.

Step 5: Revoke one password in wp-admin

Go to the user's profile, scroll to Application Passwords, and click Revoke on the row you want to remove.

WordPress asks: "Are you sure you want to revoke this password? This action cannot be undone." Confirm, and you should see the notice "Application password revoked." The row disappears from the table.

There is also a Revoke all application passwords button below the table. It asks "Are you sure you want to revoke all passwords? This action cannot be undone." and then shows "All application passwords revoked." Use it only when you are sure every app on that account should lose access, for example on the account of someone who has left.

Step 6: Revoke one password with WP-CLI

The delete command page shows the exact syntax. This command revokes the single password with that UUID from user 2. Replace the UUID with the one from your Step 2 list.

wp user application-password delete 2 6633824d-c1d7-4f79-9dd5-4586f734d69e

You should see Success: Deleted 1 of 1 application password.

The same page says you can revoke several at once by passing a comma-separated list of UUIDs.

This command removes every application password for user 2, so be careful with it.

wp user application-password delete 2 --all

You should see Success: Deleted all application passwords.

Step 7: Rename vague passwords you decide to keep

Once you identify a mystery password, give it a clear name so the next audit is easy. This command renames the password with that UUID for user 2.

wp user application-password update 2 6633824d-c1d7-4f79-9dd5-4586f734d69e --name=newappname

You should see Success: Updated application password. Use a name that says what the app is and who owns it.

How to check it worked

1. List the user's passwords again with the Step 2 command. You should see only the passwords you decided to keep, and none of the UUIDs you revoked.
2. Reload the Application Passwords section on the user's profile. The table should match the WP-CLI list.
3. Ask each app owner whose password you kept to confirm the app still works. Their next sync or post should go through normally.
4. If you still have the old revoked password for a test app, try it against the REST API. The command below is taken from the official REST API authentication page, with example values.

Ask curl to prompt for the application password instead of placing the secret in the command:

curl --user "USERNAME" https://example.com/wp-json/wp/v2/users/me

Replace USERNAME and the domain, press Enter, then type the application password at curl's prompt. The password is not echoed. A revoked password should return an authentication error; a valid password should return the authenticated user's data.

Do not paste an active application password into the command itself, shell history, a ticket or a shared chat. The interactive prompt avoids storing it in the command line and reduces exposure through process listings.

Troubleshooting

Problem: "Invalid user ID, email or login"

Symptom: WP-CLI stops with Error: Invalid user ID, email or login: '2' (with your value in the quotes).

Likely cause: the user ID does not exist on this site, or you are running the command in the wrong WordPress folder.

Fix: run wp user list --fields=ID,user_login,roles again and copy the ID from that table. On multisite, check you are on the right site.

Problem: "You need to specify either one or more UUIDS or provide the --all flag"

Symptom: the delete command refuses to run and prints that message.

Likely cause: you gave a user but no UUID.

Fix: copy the UUID from the Step 2 list and add it after the user ID. Only use --all if you mean every password for that user.

Problem: the section says HTTPS is required

Symptom: the profile page shows "The application password feature requires HTTPS, which is not enabled on this site." This often happens on a staging copy.

Likely cause: WordPress only supports application passwords on sites using SSL or on local environments. Its own check is is_ssl() or an environment type of local.

Fix: turn on HTTPS for that copy. On a true local development site, set WP_ENVIRONMENT_TYPE to local. The notice suggests setting the environment type, and the 7.2 roadmap lists a ticket saying WordPress asks for a development environment but actually requires local. That ticket is a planned item, not a shipped change, so use local for now.

Problem: the section mentions Basic Authentication

Symptom: you see "Your website appears to use Basic Authentication, which is not currently compatible with Application Passwords."

Likely cause: the site is behind a server-level password prompt, which is common on staging sites.

Fix: ask your host or developer to remove that server password for testing, or test on a copy without it.

Problem: an app breaks with an invalid password error

Symptom: an app or script reports "The provided password is an invalid application password."

Likely cause: you revoked the password it was using, or someone typed it wrongly.

Fix: if the app should still have access, create a new password for it under Application Passwords with a clear name, and give it to the app's owner through a private channel. Then ask them to update the app.

Security notes and pro tips

Revoking a password breaks the app that uses it. That is the whole point, but plan the timing with the app's owner.

Do not delete a password you cannot identify without asking the app's owner first. A password with no clear owner and recent use is often a live integration that someone forgot to document. Ask whoever set up your integrations and wait a reasonable time before acting.

If your site does not use application passwords at all, a developer can turn the feature off with the wp_is_application_passwords_available filter, shown in the integration guide. This code makes the feature unavailable site wide.

add_filter( 'wp_is_application_passwords_available', '__return_false' );

To allow the feature only for users who can manage options (usually administrators), the guide describes the wp_is_application_passwords_available_for_user filter with a manage_options check. This code follows that pattern.

add_filter( 'wp_is_application_passwords_available_for_user', function ( $available, $user ) {
    if ( ! user_can( $user, 'manage_options' ) ) {
        $available = false;
    }
    return $available;
}, 10, 2 );

Heads up: either filter stops every affected app at once. Run your audit first so you know what will break.

Application passwords also work with XML-RPC. If you are reviewing remote access in general, my guide to disable WordPress XML-RPC safely is the natural next read. And because each password carries its user's role, it is worth checking that new sign-ups cannot get a powerful role, which is covered in the open registration and default role check.

Ask your host or a developer for help when you have no admin access, or when a password on an administrator account shows recent use from an IP address nobody recognises.

The one message worth forwarding

Copy this, fill in the blanks, and send it to your developer, host or boss:

"Hi, I am auditing the application passwords on example.com before the next WordPress update. I found these entries: [name, user, last used date]. Can you tell me which ones belong to you or your tools, and whether each one is still needed? I plan to revoke any that nobody claims after [date]. Revoking will stop the app that uses it, so please reply if any of these must stay."

Every application password is a spare key, so list them all, ask before you take one back, and revoke the ones nobody can name.