A former contractor’s account and an old integration credential can both remain usable long after their original job is done. Neither needs regular activity to stay relevant to your site’s security. AAM’s Identify Inactive Accounts & Aging Application Passwords audit step brings these accounts and credentials into one review.
An Application Password lets a script or service authenticate as a WordPress user without knowing that user’s main password. It can be revoked individually, but while it exists, requests made with it use the owner’s permissions. An unused credential attached to an Administrator account therefore deserves more attention than the same credential attached to a narrowly scoped integration account.
What the audit reports
| Finding | What it means |
|---|---|
| Inactive user account | AAM recorded site access for the account, but the last record is older than the account threshold. |
| No recorded account activity | AAM has no access record for the account after a sufficiently long observation period. This does not prove the user never signed in. |
| Inactive Application Password | WordPress recorded use of the credential, but its last use is older than the password threshold. |
| Unused Application Password | The credential has no recorded use and was created before the password threshold. |
| Long-lived Application Password | Its creation date is older than the rotation threshold, whether or not it is still being used. |
By default, AAM uses 60 days for account inactivity, 60 days for Application Password inactivity, and 180 days for credential age. These are review thresholds, not automatic expiration dates. An old credential may be legitimate; a recently used credential may still have too much access.
AAM can report account inactivity only when its Track Last Access setting is on and tracking has started. For an account with no access record, AAM counts from the later of account registration or the start of tracking, and does not flag it when a recent Application Password use is recorded. Turning tracking on today does not create a reliable history of earlier access. WordPress updates an Application Password’s last_used value at most once a day, so treat it as a review signal rather than a minute-by-minute activity log. WordPress usage record
Why review both together?
An inactive human account can still hold privileged roles and capabilities. An Application Password tied to that account may also provide a route into the WordPress API. Reviewing the account and its credentials together helps you answer two questions: Who still needs this identity? and Which integrations still need to authenticate as it?
The age checks catch a different problem. A credential can be used every day and still be old enough to warrant rotation. Keeping one credential per integration makes it easier to identify its owner, replace it without disrupting other tools, and revoke it when the integration ends. WordPress guidance on managing Application Passwords
What to do with a finding
- Confirm the owner and purpose. Check whether the person still needs an account and which application owns each password. Review the account’s actual role and capabilities.
- Check recent use and dependencies. A quiet account may be seasonal, and an idle credential may belong to a scheduled job. Ask the owner before removing access that could break a workflow.
- Remove access that is no longer needed. Deactivate or remove an unneeded account according to your site’s retention process. Revoke each obsolete Application Password from the user’s WordPress profile.
- Rotate credentials that are still needed. Create a replacement for the same integration, update the application, confirm it works, then revoke the old password. Where possible, use a dedicated account with only the permissions the integration requires.
- Run the audit again. Confirm the findings you addressed have cleared and keep a record of any intentional exceptions.
The audit identifies accounts and credentials to investigate. It does not establish that a credential has leaked or automatically revoke anything. Review the evidence, make the access decision, and rerun the check regularly. For a broader inventory of these credentials, see WordPress Application Passwords: The Invisible Credentials You Need to Monitor.