One shared login is one account nobody is accountable for

The claim

The shared admin account, whose password lives in a spreadsheet or a group chat and is known to everyone who has ever needed it, is the single most common serious security weakness in small businesses — and its cost is not mainly that the password is weak. It is that a shared account destroys accountability: when something goes wrong, the logs say "admin did it", and admin is six people, two of whom no longer work here. You cannot investigate what you cannot attribute.

The three failures of a shared account

A shared login fails in three ways at once, and each is serious on its own.

It cannot be attributed. Every action taken through the shared account is anonymous within your own organisation. If a customer record is altered, a refund is issued, or a setting is changed, the audit trail names the account, not the person, and your investigation ends at a wall you built yourself.

It cannot be revoked cleanly. When one of the people who knew the password leaves, the only way to revoke their access is to change the password and redistribute it to everyone else — which is disruptive enough that it usually does not happen, so departed employees retain access for months.

It cannot have meaningful two-factor. If the second factor is shared too, it is not a second factor; it is a second thing everyone has. Real 2FA requires a device tied to one person, which a shared account cannot provide.

The fix is individual accounts with roles

Every person gets their own named account, and permissions attach to roles rather than to individuals. This sounds like more administration and is actually less, because the structure does the work:

-- roles, not people, hold permissions
CREATE ROLE billing_admin;
GRANT SELECT, UPDATE ON invoices TO billing_admin;

-- people are granted roles, and revoked individually
GRANT billing_admin TO alice;
GRANT billing_admin TO bob;

-- offboarding is one line, and it is complete
REVOKE billing_admin FROM bob;
DROP ROLE bob;  -- or disable

Now every action is attributable to a person, revoking one person's access is a single command that affects nobody else, and each person can have their own second factor. The permissions live on the role, so granting a new hire the right access is one line, and you can see at a glance who holds which role.

Least privilege, applied honestly

Individual accounts make it practical to give each person only the access their job requires, which is the other half of the fix. The shared admin account was almost certainly over-privileged — it had full control because it was easier than defining roles, so everyone using it had full control regardless of need. With roles, the person who issues refunds gets the refund role and not the ability to change system settings; the person who reads reports gets read access and nothing that writes.

The test is simple: for each person, could they do their job with less access? Where the answer is yes, the excess is pure risk — it is what an attacker gets if that person's account is compromised, and it is what that person can break by accident.

The accounts that are hardest to individualise

Two categories resist this and need deliberate handling. Service accounts — the credentials an application uses to reach a database or an API — are not people and should not be individual, but they should be named for their purpose, scoped to exactly what they need, and their credentials stored in a secrets manager rather than a config file. Break-glass accounts — the emergency access for when the identity system itself is down — are legitimately shared, but they should be rare, their credentials sealed and stored securely, their use alerting immediately, and their password rotated after every use. The existence of these exceptions is not a reason to keep the everyday shared admin.

Where to start

List every shared login in the business — the admin account, the shared mailbox, the social media logins, the vendor portals with one set of credentials. For each, the question is whether it can become individual accounts with roles, and for the overwhelming majority the answer is yes. Convert the highest-privilege ones first, because those are where the lack of attribution costs you most. The shared login feels convenient right up until the afternoon you are trying to work out who changed a customer's banking details and the only honest answer your systems can give is "someone who knew the password" — which, by design, is everyone.