The failure, stated plainly
An organisation routes all administrative access through a hardened gateway. Every session is logged. Then an unexplained configuration change appears on a production database, and the session record says the connection was made as oracle — an account eleven people know the password to.
The investigation stops there. The gateway did its job; the account defeated it.
Why shared accounts survive
They persist for reasons that are not stupid, which is why exhortation never removes them:
- The application requires it. Vendor software that runs as a single named account, with support contracts that lapse if you change it.
- Emergencies need it. When production is down at 3am, nobody wants to discover that the individual accounts were never provisioned on the failover node.
- It has always been there. The credential predates everyone currently on the team, and nobody knows what breaks if it changes.
- Individual provisioning is work. Named accounts on 400 hosts means lifecycle management on 400 hosts.
What to do instead
The workable pattern separates who you are from what you sign in as:
- Authenticate the human at the gateway. Named account, MFA, tied to your directory so leavers lose access automatically.
- Let the gateway hold the target credential. The shared account can continue to exist on the target if the application demands it — but it is vaulted, and no human knows the value.
- Inject it at connection time. The operator opens a session as
oraclewithout ever learning theoraclepassword. - Record the mapping. The session record now reads "m.reyes, authenticated with MFA, connected as oracle to prod-db-01 at 14:22" — attribution restored without changing the application.
This is the core move of privileged access management, and it is why credential injection matters more than credential rotation. See why operators should never see passwords.
The accounts to hunt first
| Account type | Why it is urgent |
|---|---|
| Root / Administrator on production | Unbounded privilege, and the first thing an attacker looks for |
| Database superusers | Reach the data directly, often bypassing application-level logging |
Network device enable | One credential typically reused across the entire estate |
| Vendor support accounts | Known outside your organisation, and frequently never rotated after an engagement |
| Break-glass accounts | Legitimate, but need explicit design rather than a password in a safe |
Measuring progress honestly
The metric is not "shared accounts removed" — some cannot be. It is shared credentials known to a human. A shared account whose password lives only in a vault and is injected at connection time no longer breaks attribution, even though the account still exists.
Track it as a number, review it monthly, and expect the last few to be hard. The vendor appliance with a hardcoded password will still be there next year; what you can change is whether anybody knows what the password is.