Ask any administrator which accounts worry them most, and the answer is rarely the ones belonging to people. It is the account called something like “svc-backup” with a password set years ago, or the shared login that the whole marketing team uses for a social media tool. Nobody owns them, nobody rotates them, and nobody dares touch them because something might break.

That fear is reasonable, which is why cleanup needs a careful sequence rather than a purge.

Why These Accounts Are Risky

Personal accounts have a natural lifecycle: someone joins, someone leaves, and offboarding catches the account. Service accounts and shared logins have none of that.

• No individual accountability. When five people use one login, an audit log cannot say which of them acted.
• Passwords that never change. Changing them risks outages, so they stay put.
• Often over-privileged. Created in a hurry with broad rights “to make it work.”
• Frequently exempt from MFA. A shared login with a code sent to one person’s phone is a common workaround, and a fragile one.
• Stale after departures. Anyone who ever knew the password still has access until it changes.

Step One: Find Them

You can’t fix what you can’t see. Look in several places:

• Your directory or identity provider, filtering for accounts without a named human, or with naming patterns like “svc”, “admin”, “test” or “shared”
• Accounts that sign in non-interactively, or with no sign-in at all for long stretches
• Application configuration files and automation tools that reference stored credentials
• Password managers or documents where teams keep “the team login”
• SaaS admin pages listing users who share email addresses such as a generic team inbox

Expect surprises. The first pass usually turns up accounts nobody remembers creating.

Step Two: Assign an Owner and a Purpose

Every account needs two facts recorded: a named human owner and a one-line purpose. Owners are accountable for rotation, for review, and for retirement. If nobody claims an account, that is a finding in itself.

Account type	Typical problem	Preferred direction
Service account used by one application	Static password, broad rights	Narrow permissions, managed or short-lived credentials
Service account used by several apps	Unknown blast radius	Split into one account per application
Shared login for a SaaS tool	No individual audit trail	Individual named accounts or role-based seats
Shared admin login	Nobody accountable	Named admin accounts plus a sealed emergency account
Generic mailbox used to sign in	Anyone with inbox access gets in	Move to a protected shared mailbox with MFA on the app
Unknown account, no activity	May be dead or may be critical	Disable first, delete after a quiet period

Step Three: Reduce What Each Can Do

For each service account, answer: what exactly does it need to access, and from where? Then shrink it. Remove interactive sign-in if the account does not need it. Restrict the source locations that can use it where your platform supports that. Replace broad roles with specific permissions. Where the platform offers managed identities or temporary credentials, prefer them, since there is then no stored password to leak. The details vary by vendor, so check current documentation.

A Hypothetical Example

A small company’s nightly backup runs under a domain administrator account whose password is known to three former and two current staff. The IT lead chooses a careful cutover.

Create a new dedicated backup account with only the rights backup requires. Configure the backup job to use it in a test window and confirm a restore works. Switch the real job. Leave the old account in place but monitor sign-in attempts to it for a couple of weeks; any attempt reveals a forgotten dependency. When nothing uses it, disable it, wait through one full business cycle including month-end, then delete.

That final waiting period is what makes the cleanup safe. Quarterly or annual processes surface dependencies that nightly tests miss.

Replacing Shared Logins

Shared logins often exist because a vendor charges per seat. Weigh the cost honestly. If a tool contains customer data or can publish publicly, the savings from sharing rarely justify losing accountability. Options in order of preference:

1. Individual named accounts for everyone who needs access
2. Role-based accounts through single sign-on, if the tool supports it
3. A shared login held in a team password manager with access logging, a rotation rule, and MFA that more than one person can satisfy

Option three is a compromise, not a goal. Document the reason it exists and revisit it.

Keep It From Growing Back

• Require a ticket and owner before any new service account is created.
• Add service accounts to the quarterly access review.
• Set an expiry or review date on each one.
• Alert on interactive sign-ins by accounts that should be non-interactive.
• Include these accounts in offboarding: when an owner leaves, ownership transfers.

Frequently Asked Questions

Is it ever acceptable to have a shared account? Occasionally, such as an emergency break-glass account kept sealed and monitored. Treat these as documented exceptions with strong controls, never as convenience.

How do we rotate a service account password without downtime? Map every system using it first. Where possible, support two valid credentials briefly, update consumers, then retire the old one. Test in a non-production setup first.

What if we don’t know what an account does? Disable it in a controlled window and watch for failures, with a quick way to re-enable. Deleting immediately removes your safety net.

Should service accounts have MFA? Non-interactive accounts cannot answer MFA prompts, so compensate with narrow rights, limited source locations, managed credentials and monitoring.

Who should own service accounts? The team that depends on the application, not a generic administrator group. Ownership should sit with someone who understands what breaks.

Next Step

Export the account list from your identity provider and mark every row that lacks a named owner. Resolve ten of them this week, starting with the ones holding administrative rights.