Quick answer
An HTTP 200 after revoking a WordPress application password does not necessarily mean revocation failed. The endpoint may be public, a browser session may supply another identity, or the request may target a different site. Test a protected read-only route with no alternate authentication and compare no credential, revoked credential, and a separately approved valid credential.
Check what the endpoint promises
Public WordPress REST resources can return data to unauthenticated visitors. Reading a public post successfully is therefore a poor credential test. Choose a route whose contract requires authentication, such as the current-user route where appropriate, and verify the response identifies the intended account.
Do not use a destructive action to prove access. Publishing, deleting, changing users, or modifying orders introduces unnecessary risk. A correctly designed read-only identity check is enough to distinguish an authenticated request from public access. Keep the returned profile information private and collect only what is necessary.
Remove competing authentication paths
A browser used to administer WordPress can already have a session. WordPress REST cookie authentication also involves its nonce mechanism. An authentication plugin may add another route to identity. Make the test in a clean API client that sends only the credential under review and no browser cookies.
Inspect the client configuration for inherited authorization, environment variables, or a saved connection. An API tool may silently use the current environment's valid secret while the tester believes an old value was selected. Record credential labels and configuration references, but never paste secret material into the incident worksheet.
Confirm the exact site and record
Compare the scheme, hostname, path, WordPress user, and application-password UUID with the control where revocation occurred. A staging clone, a second site, or an unexpected redirect can invalidate the comparison. Follow only the approved destination and preserve TLS validation.
Renaming a credential is not revoking it. Deleting a similarly named entry under another account does not revoke this one either. Read the remaining application-password inventory through supported controls and match the stable identifier. Do not use direct database edits as a first response to an ambiguous test.
Run a three-way control
First send the protected read-only request without an application password. It should not authenticate as the target user. Next send it with the revoked credential through the secure client. Finally, send it with an approved valid credential for the intended test account.
The expected distinction is identity, not merely a particular status number. Plugins can alter error presentation, so record the status, content type, and minimal response fields together. If all three responses are the same public HTML page, investigate routing or the endpoint before drawing any security conclusion.
Test | Expected identity
No credential | no authenticated user
Revoked credential | no authenticated user
Approved credential | intended test user
Browser session | separate test, not a control
Escalate a reproducible protected-route failure
If the revoked value really authenticates in the isolated test, preserve the evidence privately and involve the site's security owner. Review authentication plugins, request routing, account state, and whether multiple application servers agree on the credential record. Do not weaken access controls or disclose the credential publicly while investigating.
If compromise is suspected, contain the affected integration according to the incident plan. Avoid a broad revoke-all operation unless its disruption and scope are understood. Separate the need to remove suspicious access from the need to keep unrelated business integrations running.
Record what was actually proven
Close the report with the endpoint contract, hostname, account identifier, isolated client, and the three outcomes. State whether revocation failed or the original test was misleading. Do not claim every integration is secure because one credential was rejected. The value of this test is a narrow, reproducible answer that another operator can verify without receiving the password.
Illustrative diagnostic example. Use your own redacted evidence.One final acceptance check
Check for a cached intermediary response if the identity result is implausibly unchanged. Authentication checks must reach the intended protected handler. Ask the hosting owner to verify existing authenticated-request cache exclusions rather than adding an arbitrary query parameter and assuming it bypasses every cache layer.
When to bring in help
Use WordPress REST authentication diagnostics when a protected route still accepts a revoked credential in an isolated test. Preserve redacted request metadata and the exact account and site identifiers for review.
Related troubleshooting
For the adjacent diagnostic path, read Application-password access review. Keep its evidence separate from this test so a change in one component does not hide a failure in another.
Helpful references
WordPress application passwords. WordPress REST authentication.