Security Basics 10｜The cost of a shared account: when something happens, you cannot tell who did it

I have pasted the admin username and password in the group's notepad, so anyone who needs to list a product, edit an order or export a report can just sign in with that — in plenty of small and mid-sized companies this is a long-standing understanding. No need to call an engineer every time somebody new arrives, no need for anyone to remember their own password, and it can even save the per-seat monthly fee that cloud software charges.

Until one morning you find that a headline product on the site has lost a zero from its price, or that a large batch of customer records was exported in the middle of the night, or that an important setting has been switched off. You furiously ask your engineer to find out who did it, and the engineer opens the system log and gives you one sentence: the log says it was the admin account, but several people in the company plus the outside supplier all know that password, so there is no way to tell whose hand it was. This is the tenth piece in our security basics series. Following Security Basics 01｜An advisory just landed: how do you know whether it affects you and the previous piece on closing accounts when someone leaves, this one works out the arithmetic: the three costs a shared account genuinely charges you.

Cost one: nothing can be attributed, and you cannot even separate a slip from a break-in

Inside a system, an account is a person's digital fingerprint. When each person signs in as themselves, the log records plainly who changed which order at what time and who deleted which file. The point is not to catch people out daily, but that when the system behaves oddly you can find the person involved straight away and ask what happened.

The UK's National Cyber Security Centre (NCSC) states it clearly in its 10 Steps to Cyber Security: Identity and access management guidance: when designing an access control system, an organisation must be able to monitor account usage easily, and must ensure that every action taken in the system can be tied specifically back to the person or the account that performed it.

Once everyone shares one account, that line of attribution is simply cut. Worse, when something strange appears in the back office you cannot immediately tell whether a new colleague unfamiliar with the interface pressed the wrong thing, or whether the password has leaked and an outside attacker is in — because everybody is signed in under the same identity at the same time, so legitimate work and malicious work sit in one undivided record.

Cost two: the moment one person leaves, changing the password and not changing it both hurt

In the previous piece we said the first thing to do on the day someone leaves is to disable their account. But if your company uses a shared account, then when one colleague leaves, or a marketing supplier engaged for a short project finishes, you are stuck at once between two options:

• Choose not to change the password: the person who has left the company still holds a key that signs them into your back office whenever they like. Even if you trust their character, you have no control over whether the private computer that has the password saved on it picks up malware later, or gets lent to somebody else.
• Choose to change the password: the moment you do, every colleague still employed, every automated integration that is running, and even the owner's own phone get thrown out of the system together. Then for several days everyone is asking in the group what the new password is, and eventually, for convenience, somebody pastes the new one in plain text into the chat.

It is precisely because changing a shared password is such a nuisance that many companies decide not to for now — and so one admin password runs for years, half the people who know it have left, and nobody dares touch it.

Cost three: to keep it usable for everyone, two-step verification gets switched off and permissions get opened up

A shared account brings one more chain reaction: it pushes you into dismantling, one by one, the very mechanisms that were protecting the system.

For instance, any system that takes security even slightly seriously now asks you to register a phone to receive a verification code (two-step verification). But when several people share one account, the code only ever appears on one person's phone, so each time a colleague wants to sign in they end up shouting across the office for somebody to read the code out. Before long everyone finds it tiresome and simply turns two-step verification off. By the same logic, because people in different departments all have to do their work through the same account, that shared account's permissions are forced up to the highest level — and an intern who only needed to look at reports is handed the top-level administrator key that can delete the entire website database.

One table: shared account versus one account per person, as it really is

Put the everyday convenience and the cost when something happens in the same table and it reads clearly:

Three small moves you can start today

Getting rid of shared accounts does not mean turning every system over at once. You can work through it in three steps, starting where the risk is highest:

• Step one: find out who holds a top-level administrator account: open your website back office, cloud server and payment platform, and see whether everybody is signing in with the same admin account.
• Step two: create a sub-account for each person who actually needs to work in there: for a back office you had built yourself, creating accounts costs nothing extra. For external software charged per seat, at least give the people who genuinely need to change settings their own accounts, and move the report-only readers to a scheduled export or a notification instead — do not let everyone share the highest permission to save a few seats' monthly fee.
• Step three: once everyone is signing in as themselves, change that original shared password immediately: lock the old shared password into the company's password manager, keep it only as an emergency fallback, and let nobody sign in with it in normal use.

Nerd Technic is a systems software company that came out of custom development, and what we do now is the long-term maintenance of AI systems. As we wrote in What a System Health Check Actually Looks At: Code, Database, Deployment, Security, the first door the security side looks at is "whether permissions are separated: not visible on screen does not count, there has to be a check on the back end", along with confirming on the code side "whether there is a version history, and whether you can see who changed what and when". Long-term maintenance means how quickly someone responds when something breaks should be written into the contract. If your system is still one account passed round in turn, or you are not even sure whether the back office can create sub-accounts, a system health check is a place to start: Book a system health check