Shared accounts and Cyber Essentials: why they fail, and what to do instead

The rule (A7.2)

The NCSC’s Requirements for IT Infrastructure (v3.3) say you must authenticate users with unique credentials before giving them access to applications or devices — and that this includes third-party accounts, such as the ones your IT support uses. The question set turns it into A7.2: are all your user and administrative accounts accessed by entering unique credentials? Its guidance is four words long: “Accounts must not be shared.”

IASME’s user-access FAQ has been asked about the obvious exceptions and gives the same answer each time. A shared login on a third-party web app, with a recorded business reason and a list of who uses it, is not compliant. Nor is a generic account on a device protected by an auto-lock and a fingerprint reader. Unique accounts are required for all users and administrators.

Why it matters beyond one question

A shared login undermines the rest of the user-access section as well. You can’t switch off a leaver’s access to an account four people use without changing it for the other three (A7.3). Multi-factor authentication sent to one person’s phone either locks the others out or gets passed around — and a cloud account without working MFA is an automatic fail (A7.16, A7.17). And when something goes wrong, nobody can tell who did what. That is the whole reason the rule exists.

The usual shared accounts, and the fix for each

The info@ or accounts@ inbox

Make it a shared mailbox in Microsoft 365, or a Google Group or delegated inbox in Google Workspace, that named people open from their own accounts. Nobody signs in as info@, so there is no shared password, and each person’s own login carries their MFA. The Microsoft 365 and Google Workspace guides have the clicks.

The office or reception PC everyone uses

Give each person their own account on it — switching users takes seconds on Windows and on a Mac. IASME’s guidance on accounts says the same: if more than one person uses a PC, each needs their own account, and an unused guest account should be switched off. This is the case IASME’s FAQ answered about a generic login behind a fingerprint reader: the lock protects the device, but the account is still shared.

Company social media

Business pages are built for teams. Facebook and Instagram business accounts can be managed through Meta’s business tools, where each person is added with their own login, and a LinkedIn company page is run by admins using their own LinkedIn accounts. Where a platform truly offers only one login, make it one named person’s account and have everyone else go through them. Business social accounts are cloud services, so they need MFA too.

The web tool that sells one seat

IASME’s FAQ answers exactly this case, and the answer is that it isn’t compliant. Buy a seat for each person who needs it; or make it one named person’s account that only they use; or, if nobody really needs it any more, close it — software and services you don’t use should be removed anyway (A5.1).

Admin logins and your IT provider

Each person who administers Microsoft 365, Google Workspace or your devices needs their own named admin account, separate from their everyday one (A7.6). The same goes for an IT provider: a single “support” login used by several of their engineers is a shared account, and the requirements specifically include third-party accounts. Ask them for named accounts, and put those accounts on your admin list (A7.8).

The emergency “break glass” admin account

Many businesses keep a spare admin account in case the usual admin is locked out. IASME’s FAQ says a break-glass account should still have a form of MFA, using a different method from other users — for example, allowing sign-in only from a trusted, managed device.

One phone for everyone’s MFA codes

Some offices send every person’s sign-in codes to a single office phone. IASME’s FAQ says this is acceptable but not advisable: think through what happens if that phone is lost or breaks. Each person approving their own sign-ins on their own phone or security key is the sturdier set-up.

Sharing the password more carefully doesn’t fix it

A shared vault in a password manager, a sealed envelope, a note only two people know — they make a shared password safer to handle, but it is still one account used by more than one person, which is what A7.2 rules out. Password managers are for each person’s own unique passwords (A7.12).

Fixing it in an afternoon

1. List every login more than one person uses — inboxes, the office PC, social media, supplier portals, the accounting software.
2. Convert the inboxes to shared mailboxes or groups.
3. Give everyone on a shared PC their own account, and switch off any guest account.
4. Add people to each tool with their own login, buying seats where needed.
5. Retire the old shared login once everyone has moved: change its password or remove it, so it can’t still be used (A5.2).
6. Write it down. The free user access policy template commits to individual logins from day one; the other free templates cover the rest.