I know its best practice not to allow shared user accounts, but where is this best practice defined? Is it an ISO standard or something? What is the reasons to always create per person accounts?

  • 3
    For those of you answering in comments - please don't do that. I have deleted them. If you would like to write them as answers that would be very helpful.
    – Rory Alsop
    Commented Mar 2, 2019 at 10:17

10 Answers 10


Alice and Eve work for Bob. Alice is a very good worker who does exactly what Bob asks her to do. Eve is a criminal mastermind hell-bent on destroying Bob's company.

Alice and Eve both share the same account.

Eve logs into the account and uses it to sabotage an important business process. The audit log captures this action.

How does Bob know who sabotaged his company? He has to get rid of the bad actor, but can't fire both of them, because his company depends on the work that they do. He could fire just one, but he has no way of knowing which one is his friend and which one is his enemy.

If Alice and Eve had separate accounts, Bob could be sure that Eve was the one who did the sabotage. Eve might even avoid doing the sabotage, if she knows her account will be audited and she will be caught.

EDIT: Adding from comments:

If Eve quits, you now need to reset the password on every account she had access to, rather than just disabling her personal accounts. This is much harder to manage, and you will miss accounts.

Additionally, it removes your ability to have granular control over access. If Alice should be writing checks, and Eve should be signing them, you essentially have no technological way to enforce that if they share the same account.

Also, it makes it harder for a given individual to notice malicious changes to their environment. Alice knows what files are on Alice's desktop. Any new files will likely raise a red flag for her. Alice doesn't know what files are on Alice and Eve's shared desktop. It is likely new files will be met with a shrug and an assumption that another user put it there, not a malicious actor.

  • 50
    +1 Except that Eve, being a criminal mastermind, would have hacked in to Bob's account so he would have had to fire himself :-)
    – TripeHound
    Commented Feb 25, 2019 at 16:22
  • 73
    A more common situation: Eve quits or gets fired. Now you have to change the credentials for everything Eve was using (assuming you know that), you can't just disable Eve's account(s).
    – JimmyJames
    Commented Feb 25, 2019 at 16:41
  • 10
    Shared accounts also makes it much harder to detect when a bad actor has gained access to an account they should have access to.
    – JimmyJames
    Commented Feb 25, 2019 at 16:44
  • 17
    Even if Eve isn't out to sabotage the company, Alice and Eve's sharing an account also means that Bob can't give Alice additional permissions without also giving them to Eve. If Alice is promoted and now has access to data X, Eve gets it, too.
    – minnmass
    Commented Feb 25, 2019 at 19:10
  • 3
    @jpmc26 This is true, but this is not specific to shared vs non-shared accounts. Commented Feb 26, 2019 at 13:38

Real story, happened at a friends workplace (jurisdiction: Germany):

A coworker of his rudely insulted clients via her company e-mail. She was fired for this. She did go to court. There, her lawyer made the court aware of the fact that the employees shared their passwords (for instance, for answering a client´s mail in the absence of a certain colleague).

The Judge ruled that there was no good proof that that the person in question was really the one who sent the insulting e-mails. The person had to be rehired and compensated for the lost wage.

Morale: One function of user accounts is to discern users from one another, to make their action audit-able. Only private accounts fulfill that function.

  • 7
    It's a classic, in many country with many variation. You will find similar example almost everywhere. It's so mainstream it doesnt qualify for funny story in most French prud'homme (a French tribunal appointed to decide labour disputes). Commented Feb 26, 2019 at 15:30
  • Off-topic: but that's just a bad e-mail set-up. Every email system around for the past 15-20 years supports delegated mailbox access, even Gmail and formerly-known-as-Hotmail support it.
    – Dai
    Commented Mar 1, 2019 at 0:54
  • 3
    @slebetman: I think the moral of the story should be: One function of user accounts is to discern users from one another, to make their action audit-able. Only private accounts fulfill that function.
    – Daniel
    Commented Mar 1, 2019 at 16:03
  • 1
    This reads more as a story than an asnwer
    – northerner
    Commented Mar 2, 2019 at 4:43
  • 1
    @Daniel That is the answer! Everything else on this page is a distraction. Commented Mar 2, 2019 at 16:36

You should use separated account in all contexts (security on the top).
Adonalsium example show you because it's required. There are some rare situations where it is "not possible" or "not usefull" ...

Examples: "not possible" (legacy protocols/applications) "no relevant" (anonymous actions)

If it is no possible, but you need to identify, you have to mitigate the risk adding more source informations as possible (e.g. connection info, connection time, etc ...)

You can check ISO 27001 Risk Assessment Methodology, ISO 31000 Risk management as starting point to answer to your question "Why avoid shared user accounts?"

  • 2
    ISO 27001 doesn't detail any RM methodology, it basically says "hey, RM is a good idea, you should have one". RM is detailed in 27005, but again on a high level without a specific methodology and only listing a few examples (and bad ones at that!). The 27k is really less than helpful in this regards, I'm having a hard time in my risk management courses to teach people proper risk management, even if they already know the 27k.
    – Tom
    Commented Mar 3, 2019 at 8:51

The typical answer is accountability, traceability, etc; In other words to be able to know who exactly did what.

A shared account has n potential people doing something but all that you have points to one account doing that thing.

This problem is usually lifted by making sure someone is legally responsible for the activities of this account. This may or may not be feasible, and you may not have someone taking responsibility for the actions of others.

This problem often occurs when you outsource some monitoring activities - the account which does the monitoring tasks should be contractually in charge of that company, which is responsible for its actions.

If you cannot assign a responsible person, it is then up to management to make a decision based on the risk: not having a service vs. not knowing who does what with that account.


I only know one exception to that rule. There is one single machine that is shared by several users, and the following assertions are all true:

  • one and only one of those users is in charge of this machine at any moment
  • the account can only be used on the local machine - disabled via network

This may happen on 7/7 24/24 systems. In that use case, you still keep an acceptable imputability by knowing the user that was present at a specific moment, provided you could set the above second rule. But in fact, it is equivalent at having an account with no password, and only using physical security.

  • Typically in this set up best practices are to use a management software to roll the password every few hours, and have staff check out the shared password to their personal account as needed. Commented Feb 27, 2019 at 20:08
  • Please also make note that the approach you state here has 0 advantages over just properly configuring credentials for multiple users. If you can learn how to configure local-only access you can learn how to configure sudo properly. Commented Mar 1, 2019 at 1:12

Best practices are nowhere "defined", that's what the term means. A best practice is simply an established way of doing things that most people think is the best way.

It goes the other way around. Once a "best practice" is dominant, usually someone on a standards board decides to put it into some ISO or other norm. It then rests there, usually without explicit reasoning, or a circular reasoning pointing out that this is best practice.

The reasons for this particular practice are likewise practical ones. If Alice and Bob share an account and something bad happens, they will both point to the other person and you have no way of figuring out who did it. With personal accounts, they'll claim it was compromised, but then you at least have a single point to investigate further.

There are also explicit requirements for accountability in many sub-fields such as compliance, and they play into this.

  • 2
    It's not rare for someone (or an organization) to write and publish something that documents best practices, though. That doesn't define them, and it can be controversial which practices should/shouldn't be included in this document, but not sharing accounts is clearly agreed upon and the OP is simply asking if anyone has written that down someone. Commented Feb 27, 2019 at 9:00
  • 2
    No, OP specifically asks if it is defined, e.g. in an ISO norm. My answer is that if it is in the ISO norm, then it is there because they considered it a best practice, not the other way around.
    – Tom
    Commented Feb 27, 2019 at 15:47
  • I'm glad someone actually addressed the standards part of the question. PCI DSS Requirements 8.1 and 8.5 refer to using unique accounts and not using shared accounts. NIST SP 800-53 also has sections on identification and use of shared accounts.
    – HackneyB
    Commented Mar 3, 2019 at 0:52

Here are a few bullet points for easier understanding and a quick review.


Accountability is another important principle of information security that refers to the possibility of tracing actions and events back in time to the users, systems, or processes that performed them, to establish responsibility for actions or omissions.


If you are going down the path to be GDPR compliance or most regulations you need to be able to define a line on where each account have access to.


In case of an audit, you need to be able to pinpoint the accounts which were compromised or was responsible for an action.

Manage and protect

To protect, manage and monitor account it's easier to have separate individual access to delete, modify and detect abnormal usage.

Even if you are not following any regulations you still should (recommended) to follow the "best practices" it helps your overall network process on a big scale.

  • 1
    This is just a summary of other answers and nothing new?
    – schroeder
    Commented Feb 27, 2019 at 21:50

Another issue not yet mentioned is that if someone receives notification that their account is being accessed or has been accessed at a time when they're aren't/weren't accessing it and wouldn't expect anyone else to do so, they're much more likely to sound an alarm than they would be if they thought that the account might have been accessed by someone whom they'd authorized.

Given that the number of cases where it may be necessary for someone to authorize someone else to perform some particular action on their behalf, it would be extremely helpful if services could at include a means by which accounts could authorize and revoke secondary credentials with limited rights. That would allow the system to report which credential was used to access an account, thus allowing someone to better distinguish expected from unexpected activity.


In addition to the auditing issue that other answers point out, shared-user accounts are inherently less secure than a single-user account on the same platform.

If more people know the credentials for logging in, that account is less secure. You now have many more potential victims of social engineering attacks. Each additional person with access to account is another vector of attack against that account's security. As the saying goes, two can keep a secret if one is dead.

I'd also caution against the use of shared logins from a psychology standpoint. Besides just auditing/culpability concerns, shared logins also inherently mean sharing both the glory the blame. You could be dis-incentivizing personal accountability and work ethic. If it's a shared profile, each individual will feel less responsible for that account's security. After all, even if they do all the right things (like using a password manager and avoiding phishing email), what if their coworker doesn't? Why should they put in the extra effort when another person is just going to do the wrong thing anyway?

Additionally, I suspect that shared logins will have weaker passwords protecting the account. Trying to share a strong password and properly manage it across multiple people would be inconvenient. You'd likely end up with either the lowest common denominator for password weakness (CompanyName01?) or a password physically written down for all in the area to see.


As said by many, accountability, traceability, liability etc are the main reasons. There are a number of extra points to consider:

  • How secret is the information that is accessed? As an extreme case, many public FTP servers use(d) a shared account "anonymous". And is the account that you use to access public www-servers (a non-authenticated account) not basically the same? What about WPA2 passwords?
  • When you create a company policy, it is much easier to enforce "NEVER EVER share accounts", than "well, you should never share an account, but in some cases, like a read only account to not-so-secret information for a limited period between two people that work together, you might do that, if the real risk is low".
  • There is also an administrative burden on shared accounts. An example already given is the need to change passwords when someone leaves.
  • Some accounts need to be shared. An example is root on Unix/Linux. Yes, you will place a lot of restrictions on the use of root in production, like sudo with extensive logging and security monitoring, a password-vault etc., but it still is a shared account.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .