Shared user accounts and poor cyber hygiene: the risks businesses keep ignoring

Why shared accounts seem convenient (and why they're not)

It starts with something small. A new member of staff needs access to an invoicing system. Creating an individual account means contacting the vendor, waiting for provisioning, maybe paying for an extra licence seat. Someone decides it's easier to share the finance team login. The password goes on a sticky note, or into a WhatsApp message, and the arrangement becomes permanent.

This pattern repeats across businesses: a shared admin account for a hosted platform, a single login for a third-party portal, a generic "accounts@" mailbox that three people log into with the same credentials. Nobody planned it; it accumulated over time as the path of least resistance.

The problem with shared accounts isn't just that they're a security risk. It's that they remove the ability to see what actually happened. When five people share a login, there is no meaningful audit trail. If data is deleted, exported or changed, you have no way of establishing who did it, when or why. That matters for internal investigation, for regulatory compliance and – in the worst cases – for legal proceedings.

One compromised credential in a shared account doesn't give an attacker access to one person's work. It gives them access to everything that account can reach, with no indication of who's using it or whether the activity is legitimate.

The compliance problem with shared accounts

This isn't just a security best practice issue. Several frameworks that businesses are either required or increasingly expected to comply with take a specific position on shared accounts.

Cyber Essentials – the UK government-backed baseline certification scheme – requires that user accounts are individual and that multi-factor authentication is applied. A shared account with a single password fails both requirements. Businesses seeking Cyber Essentials certification need to address this before assessment.

PCI DSS, the Payment Card Industry Data Security Standard, is explicit: shared or generic user IDs are prohibited. For any business that processes, stores or transmits cardholder data – which includes most businesses that take card payments directly – shared accounts that touch payment systems are a compliance violation, not just a risk.

GDPR creates a data governance problem that shared accounts make unsolvable. When an individual exercises their right of access or their right to erasure, the business needs to be able to identify every place their data was touched and by whom. If your accounts records were accessed by a shared login, you cannot establish who saw what. That gap is a liability – both in terms of demonstrating compliance to the ICO and in responding accurately to a subject access request.

Offboarding: the access problem you don't notice until it's too late

Ask most businesses whether they have an offboarding process and they'll say yes. Ask them whether the last three people who left still have any form of access and the answer is often less certain.

The failure mode is predictable. When someone leaves, their email account might be disabled within a few days. But what about the CRM they logged into with a personal password they set themselves? The VPN credentials that were never tied to their email account? The shared password they knew and can still use from home? The Slack workspace where their account was never deactivated?

Former employees retain access more often than most businesses realise, and not always maliciously. Sometimes they use it because nobody told them not to. Sometimes they access a system out of habit. And sometimes they use it deliberately, because the motivation to cause harm or extract information comes after they've left.

A proper offboarding checklist doesn't just disable the email account. It covers every system the individual had access to – which requires knowing what access they had in the first place. That means maintaining an up-to-date access register, revoking individual credentials across all systems on the day of departure, changing any shared passwords the individual knew, and recovering any company-managed devices. It also means removing them from distribution groups, shared mailboxes and any external service accounts that were tied to their personal email address.

This is operationally tedious. It's also the thing that prevents a disgruntled former employee from becoming a serious incident.

Admin rights as everyday accounts

Running with administrator-level privileges as your day-to-day user account is a habit that multiplies the impact of almost any attack. It's also extremely common, particularly in smaller businesses where IT was set up informally and nobody reconfigured access as the business grew.

When a user with standard privileges opens a malicious email attachment or clicks a phishing link, the damage is constrained by what that account can do. If the same thing happens on an administrator account, the attacker inherits the ability to install software, modify system settings, disable security tools and access files that a standard user couldn't reach. Ransomware running under admin privileges encrypts more. Malware running under admin privileges persists more effectively.

The fix is straightforward in principle: daily work happens on a standard user account, and a separate administrator account – with a different password – is used only when elevated privileges are actually needed. That separation doesn't prevent all attacks, but it significantly reduces what an attacker can do if they get in through the everyday account.

For small businesses on Windows, this means creating a secondary local or domain admin account and downgrading the primary account to standard user. It takes an hour to configure. It's rarely done proactively because it introduces friction – installing software, changing settings and some system tasks require the admin password. That friction is, in fact, the point.

Other poor practices that compound the risk

Shared accounts don't exist in isolation. They tend to appear alongside other habits that individually seem minor but together create a compounding exposure.

Password reuse is the most consequential of these. When someone uses the same password for their work email, their personal email and several external platforms, a breach of any one of those services gives an attacker credentials they can try everywhere else. Credential stuffing – the automated testing of leaked username and password pairs against other services – is responsible for a large proportion of account compromises that businesses attribute to "hacking". The account wasn't hacked; the password was reused from somewhere that was.

Personal email for work documents is another pattern with consequences that only become visible when things go wrong. When a document is emailed to a personal Gmail account because it's convenient, the business loses visibility and control of that data. It can't be recalled, audited or wiped. If that employee's personal account is compromised – or if they leave – the business has no way of knowing where that document has gone.

SMS-based multi-factor authentication is better than no MFA at all, but it's weaker than the alternatives. SIM-swapping attacks – where an attacker convinces a mobile network to transfer a victim's number to a SIM they control – can intercept SMS codes. Authenticator app-based MFA (Microsoft Authenticator, Google Authenticator) or hardware keys (YubiKey) don't have this weakness. For high-value accounts, the choice of MFA method matters.

What to do

None of this requires enterprise-scale tooling or significant budget. The fixes are mostly process changes that any business can implement.

Start with an account audit. Map every system your business uses, identify every account that exists on each system and establish whether it's individual or shared. This is the baseline you need to fix anything else.

Implement individual accounts with MFA across all systems – not shared accounts with a sticky note. Where vendor licensing is the barrier, evaluate whether the cost of an additional licence seat is actually greater than the risk you're carrying by sharing credentials. In almost every case it isn't.

Build and follow an offboarding checklist. It should be exhaustive, system-by-system, and it should be completed on the day of departure – not the following week when someone remembers. Assign ownership of this process to a named person.

Introduce a password manager. A business password manager (1Password, Bitwarden, Keeper) gives every person their own credentials for every system, removes the incentive to reuse passwords and makes sharing credentials – where it genuinely can't be avoided – controllable and auditable. It also solves the "what do we do when someone leaves and we don't know what passwords they knew" problem.

Separate admin from daily-use accounts. Downgrade everyday accounts to standard user. Create dedicated admin accounts used only when needed. The inconvenience is real and it's the right trade-off.

These aren't complex technical interventions. They're discipline and process. Businesses that implement them are harder to attack, easier to audit and better placed to meet the compliance requirements that are increasingly unavoidable.