← Back to blog

The Offboarding You Forgot: Who Still Has Access to Your Client Sites

Scattered wp-admin logins and a departed contractor are a credential incident waiting to happen. How scoped, revocable access turns offboarding into a single click instead of an archaeology project.

Ben KalskyCo-founder & Engineering, Digitizer · · 2 min read
WordPressSecurityAgency OpsIncidentsSiteAgent

Here's a question most agencies can't answer quickly: if a contractor left today, which client sites could they still log into tomorrow? If the honest answer is "we'd have to check each one," that's not an access policy — it's an incident with a delay on it.

This is an illustration, not a specific customer. It's the quiet risk that grows every time a login gets shared and never gets cleaned up.

How access sprawl happens

Nobody designs this. It accumulates:

  • A freelancer needs to fix one thing, so they get the admin login. The fix ships; the login stays.
  • Credentials get shared over chat, saved in a browser, copied into a doc. Now you can't even enumerate who has them.
  • A laptop is lost, or a relationship ends, and "we should rotate those" turns into a to-do that means logging into forty sites by hand — so it doesn't happen.

None of these is a breach. Together they're a standing one: access that outlives the reason it was granted.

Where it bends: scoped, revocable, attributable

The fix is to stop handing out the crown jewels for routine work:

  • A per-site token, not the admin password. SiteAgent connects each site with its own scoped token: the site stores only a SHA-256 hash of it, and Aura keeps its copy encrypted at rest (AES-256-GCM). Either way, Aura never holds the site's main WordPress admin password, and a token can be rotated to cut access without touching that login.
  • Revoke without a scavenger hunt. Regenerate a site's token to cut access instantly; remove the site from Aura to end the connection. Offboarding becomes a central action, not per-site archaeology.
  • Attributable actions. Mutating actions are approval-gated and logged — who or what asked, who approved, what ran — so "who changed this" has an answer.

The honest boundaries

  • SiteAgent governs the access it manages. It doesn't retroactively find every place someone manually saved a wp-admin password — the point is to stop creating that sprawl for routine work, and to make the site's own Application Passwords revocable from WordPress.
  • A token is a sensitive credential. It's safer than a shared admin login because it's scoped and revocable — not because it can be careless.

Offboarding should be a click, not an investigation

You can't secure access you can't enumerate. Move routine work onto scoped, revocable, logged connections, and the question "who can still get in?" stops being scary — because the answer is "whoever's connection is active, and I can end any of them right now."

Aura's SiteAgent plugin is free and open source, and connecting your first site takes a minute. Read the security model to see exactly how the token and audit design works, or start free.

Frequently asked questions

What's the risk of shared wp-admin logins across client sites?
Shared admin credentials are hard to track and hard to revoke. When a contractor leaves or a laptop is lost, you often can't say which sites they could reach, and rotating access means logging into every site by hand. That gap between 'someone left' and 'their access is gone' is where credential incidents live.
How should an agency manage access to many WordPress sites?
Prefer scoped, revocable credentials over shared admin passwords: each connection uses its own token that can be rotated or removed without touching the site's real admin login, and every action is attributable. Then offboarding is revoking access centrally, not remembering every place a person could log in.
Does connecting a site to a dashboard mean handing over admin passwords?
It shouldn't. A well-designed connection uses a per-site token and standard WordPress mechanisms — the site stores only a hash of the token, and the dashboard keeps its own copy encrypted at rest — so the dashboard never holds the site's main admin password, and the token can be regenerated at any time to cut access.
← Back to all posts