Access Control for Shared and Generic Accounts

Shared accounts are one of the biggest blind spots in access management. An account labelled “reception@company.com” or “admin” that multiple people use may seem convenient, but it destroys the single most important principle of access control: accountability. When something goes wrong — and it will — you need to know exactly who did what. Shared accounts make that impossible.

This lesson explains why shared and generic accounts are a serious security risk, how to identify them in your environment, and what to do about them — including practical alternatives for the scenarios where sharing seems unavoidable.

What Are Shared and Generic Accounts?

A shared account is any account whose credentials are known by more than one person. A generic account is one that is not linked to a specific, identifiable individual. Common examples include:

• “admin” or “administrator” — a generic system administration account used by multiple IT staff
• “reception@” or “info@” — a shared mailbox that multiple people log into directly
• “sales-team” or “marketing” — a shared login for a business application
• Service accounts — accounts used by applications to communicate with other systems, often with credentials shared among developers or IT staff
• Test accounts — accounts created during development or testing that are never decommissioned

The Security Problem with Shared Accounts

Shared accounts undermine security in multiple ways:

• No accountability. If four people know the password to the “admin” account and a harmful change is made, you cannot determine who made it. Audit logs show the action was taken by “admin” — but that tells you nothing.
• Password management failure. When someone who knows a shared password leaves the organisation, the password should be changed immediately. In practice, this rarely happens — or it is changed and then shared with the remaining users via email or a sticky note.
• MFA bypass. Multi-factor authentication relies on verifying a specific individual. Shared accounts typically cannot use MFA effectively because the second factor (a phone, a token) belongs to one person, not the group.
• Privilege escalation risk. Shared admin accounts often have elevated privileges. Anyone who knows the password has those privileges — including people who should only have standard user access.

Shared accounts are explicitly flagged as a risk in virtually every cybersecurity framework. ISO 27001, Cyber Essentials, NIST, and GDPR all require individual accountability for access — which shared accounts cannot provide.

Practical Alternatives to Shared Accounts

For every scenario where a shared account seems necessary, there is usually a better alternative:

• Shared mailboxes: Use delegated access instead of shared credentials. In Microsoft 365 and Google Workspace, you can grant individuals access to a shared mailbox through their own authenticated account — maintaining individual accountability.
• Admin accounts: Create individual named admin accounts (e.g., “admin-jane.smith”) rather than a single shared “admin” account. Each IT team member gets their own elevated account.
• Application logins: If a system only supports one login, raise it as a risk and budget for an upgrade. In the interim, implement compensating controls — log who uses the account, change the password regularly, and restrict when and where it can be used.
• Service accounts: Use a privileged access management (PAM) tool or password vault to manage service account credentials. No individual should know the password directly.
• Test accounts: Create individual test accounts for each developer or tester. Decommission them when testing is complete.

How to Identify Shared Accounts in Your Environment

Finding shared accounts requires detective work. Look for these indicators:

• Accounts that log in from multiple IP addresses or devices simultaneously or in rapid succession
• Accounts with generic names that do not correspond to a specific person
• Accounts whose password was last changed long ago (shared passwords tend not to be rotated)
• Accounts that are excluded from MFA policies
• Accounts that IT or department heads acknowledge are “shared by the team”

Why This Matters

When a breach investigation begins, the first question is “who accessed this data?” If the answer is “we don’t know — it was a shared account,” your organisation faces regulatory scrutiny, inability to contain the breach effectively, and potential legal liability. Shared accounts also invalidate your audit trail, which undermines every other security control you have in place.

Cyber insurance providers are increasingly asking about shared accounts. Some will reduce coverage or increase premiums if shared admin accounts are in use. The cost of replacing shared accounts with individual ones is a fraction of the cost of a breach you cannot investigate.

What to Do Now

• Conduct a discovery exercise to identify all shared and generic accounts across your systems
• Categorise each by risk level: admin/privileged shared accounts are the highest priority
• For each shared account, identify a practical alternative (delegated access, individual named accounts, PAM tool)
• Create a migration plan with timelines — tackle the highest risk shared accounts first
• Update your access policy to prohibit the creation of new shared accounts without formal risk acceptance

Evidence to Collect

• An inventory of all shared and generic accounts with their current status (active, scheduled for migration, decommissioned)
• A migration plan showing how each shared account will be replaced with individual alternatives
• Evidence that shared admin accounts have been replaced with named individual admin accounts
• An updated access policy that addresses shared accounts

Common Mistakes

• Ignoring shared accounts because “everyone does it.” Prevalence does not equal safety. Shared accounts are a known risk and auditors will flag them regardless of how common they are.
• Changing the shared password and calling it fixed. Password rotation on a shared account does not solve the accountability problem. The account still lacks individual attribution.
• Excluding service accounts from the review. Service accounts with shared credentials are often the most dangerous because they tend to have elevated privileges and are monitored less frequently.
• Accepting “the system doesn’t support individual accounts” without challenge. In most cases, the system does support individual accounts — it just has not been configured that way. If it genuinely does not, that is a risk that should be formally accepted and documented by management.

---

Knowledge Check

---