A Shared Service Account Is a Single Point of Contention

I once had to integrate several services with an older system through its API, and the thing that bit hardest wasn’t the protocol or the data model — it was the account. Everyone connected as the same shared service user, and that single credential had two nasty properties: the server allowed only one live session per account, and a few bad logins locked the account entirely. Suddenly “shared access” wasn’t a convenience, it was a fight. A shared service account isn’t just a security smell; it’s a single point of contention, and contention has failure modes all its own.

One credential, one session, many consumers

The system allowed exactly one active session per login — a new sign-in bumped the previous one. With a single shared account across a development box, a test environment, and a scheduled job, they didn’t coexist; they stole the session from each other. Each new connection silently kicked the last, so whichever consumer connected most recently “worked” and the others mysteriously didn’t. Nobody was wrong, exactly. They were just all using the same key to the same single-occupancy room.

That’s the part people underestimate about shared identities: even setting security aside, they serialize access you assumed was parallel. The account becomes a resource your consumers queue for, usually without knowing they’re in a queue.

Lockout turns a typo into an outage for everyone

The second property made it worse. A few failed logins auto-locked the account, and unlocking it was a manual, go-ask-someone process. So any consumer that fat-fingered the password, or kept retrying with a stale credential after a rotation, could lock out every other consumer at once. One service’s bad day became everyone’s outage, and the blast radius of a single typo was the entire integration.

Share an account and you share its worst moment. One consumer’s bad password is everyone’s lockout.

This is the quiet danger of a shared credential with a lockout policy: you’ve coupled the availability of every consumer to the carelessness of the least careful one.

Shared identity also destroys your audit trail

There’s a third cost that shows up later, when something goes wrong and you want to know who. If every consumer authenticates as the same user, the logs can’t tell them apart. “The service account did it” is true and useless. You lose the ability to attribute actions, scope a revocation to one misbehaving client, or rotate one consumer’s access without breaking all of them. Identity is supposed to answer “who is this?” — a shared account answers “one of us, good luck.”

Give every consumer its own identity

The fix is the boring, correct one: each consumer gets its own credential. Per environment, per service, ideally per purpose. It costs a little more setup and it buys back everything the shared account took:

• No session theft — separate identities hold separate sessions, so consumers stop knocking each other offline.
• Contained lockouts — one client locking itself out is one client’s problem, not a shared outage.
• Real attribution — logs name the actual consumer, so you can trace, scope, and revoke precisely.
• Independent rotation — you can roll one credential without coordinating a flag day across everything.

Least privilege is the usual argument for distinct identities, and it’s a good one. But even before you get to “what can this account do,” separate accounts fix “can these accounts coexist at all.”

When the legacy system won’t let you

Sometimes you genuinely can’t issue more accounts — the upstream is old, owned by another team, or hands out exactly one credential and that’s that. When you’re stuck sharing, the move is to stop pretending the access is concurrent and make the serialization explicit: a single broker in front of the credential that all consumers go through, so there’s one well-behaved client to the upstream and the queuing is deliberate instead of a surprise. Centralize the careful behavior in one place, and protect the credential like the fragile shared resource it is.

The headline holds either way: an account used by many things is a contention point and a shared fate, not just a permission. Design for one identity per consumer, and when you can’t, put something disciplined in front of the one you’re forced to share. It’s the same instinct as treating security as architecture rather than an afterthought. If you’ve untangled a shared-account mess, tell me about it.