I own a company that has hired an IT employee. He has all passwords to servers, work stations and data. He is refusing to share or supply these passwords (Keys to the Kingdom) on the grounds of security. He has pointed me to your site along with many others, about the implications of sharing passwords. I understand the implications of sharing passwords among employees and vendors. What is the best practice for securing passwords within a company? What if he gets in a car wreck tomorrow? How do we manage changing passwords? How do we make all parties feel comfortable? Most of all, me, the owner.

  • 2
    "He is refusing to share or supply these passwords ..." - with whom? With employees? With the owner? And which specific article on this site he has pointed you to to explain his behavior? Nov 24 '20 at 22:54
  • 1
    You're getting some answers but I want to emphasize one thing: as the owner, all the accounts are yours and so you must have access to everything. This doesn't mean that you login regularly (if ever) but there must be something in place that gives you access without needing you IT person. The fact that the IT person refuses is very disconcerting, not at all normal, to the extent that my gut reaction is "fire this person now" Nov 25 '20 at 9:42
  • very related: security.stackexchange.com/questions/183425/… Nov 25 '20 at 9:45
  • He is refusing to document and share all passwords with me, the owner on the grounds that he is responsible for security of data and infrastructure. His concern is that I am not computer/ security savvy and I will, once given access, give out passwords to other employees and vendors if requested by them, thereby jeopardizing data and infrastructure. He is partially correct, that is why I am looking for a solution that will protect us all. My side of this is that I need to protect the business and minimize disruption of business, in addition one employee should not hold this much power.
    – Putz
    Nov 25 '20 at 14:56
  • You need a security policy where you define who has access to what, why, where credentials are stored, and when anybody should be allowed to access anything. You have the right to mitigate the "bus factor" (what if he gets hit by a bus?), but in general you should not have the right to use any credentials without a good reason just because you are "the boss". Imagine Elon Musk wanting to fly a rocket just because he's the boss. There must be policies and safety procedures to follow.
    – reed
    Nov 25 '20 at 14:57

The way to solve this through a secret store. Your IT person is correct in that you should not share passwords as is.

But you do have a claim to have emergency restore access form when someone gets under a bus or other catastrophic event (loss of memory for example).

Some of the ways to solve this are

  • use a Password manager service, with a secondary recovery option.
  • use a safe with a printed out recovery key, this would only give you (destructive) access back into the system and is only for emergency use. (Hence why it is in a safe)
  • have a distributed secret set, for example 4 hardware (smart card) tokens where you need at least 3 together in order to decrypt the master key stored on the system.
  • use something like hashicorps vault to store all the secrets, and use a shared token secret to restore access.
  • use a 3rd party to mange your access.

Just make sure you not only implement a recovery process (technically), but also implement a recovery policy, e.a. Write down when and why, who may trigger the emergency use. How it’s communicated (I prefer noisy recoveries, that will automatically notify all know administrators that a recovery is attempted and done.)

What you must NEVER do is

  • ask for the access tokens for a individuals account.
  • write down a password in clear readable form, always make it so it takes effort to recover it.
  • never test the procedure. (Make it so that you test the recovery procedure periodically, I usually recommend every 2 years or so.)
  • access an account without notifying the “owner”/“user” of that account. (This is called transparency, and is a corner stone of a safe and secure organization.

I hope this helps you get an idea.

  • Hashicorp Vault would be a terrible solution for this problem. It just takes far too much effort to maintain and manage, with a risk of losing data if you are not careful Nov 26 '20 at 10:57
  • While that may be your opinion, it is a valid option. I am not giving any recommendations regarding what to choice, just options to pick from. They all have there own pitfalls and risks. I have used vault in a PoC for something like this without issue. But I agree it is not trivial to do so.
    – LvB
    Nov 26 '20 at 10:59
  • You missed the most important way to manage this: any key accounts for the company should be connected to a company-specific email with limited access, not an employee account. If your employee creates an AWS account for the company and ties the root account to employee@company.com then it is already wrong. It needs to be registered under owner@company.com, aws@company.com or similar Nov 26 '20 at 11:07
  • @ConorMancone I did it miss that, that is specific for an external account like with AWS. This is not what was asked for. The question was about access to servers. (We may not assume those are AWS machines)
    – LvB
    Nov 26 '20 at 11:10
  • I missed that, but that makes this even easier then, because that is what LDAP, AD, and other such technologies are for. OP doesn't need passwords to every machine - OP just needs break-glass access to an admin account on the local domain controller Nov 26 '20 at 11:48

There should be multiple people with these accesses at all times.

This does not mean sharing accounts and passwords, it means multiple accounts and passwords with full access. Someone has to be able to lock this person out in the event of termination, kid napping, or whatever.

This is a business. It's perfectly normal to have a disaster recovery file locked up somewhere with all of the necessary procedures, accounts, and passwords. Typically this would be a corporate safe or a bank deposit box if the business is small.

For most businesses, high tech split key, multilevel encryption is unwarranted. A notebook and a thumb drive in a safe is probably just fine, but you would need to determine that.

  • Your first paragraph is a little unclear. I think what you're saying is that, for instance, a given account should be configured so that different people can login with their own credentials. However, not all services support this, in which case you have no choice but to share a password (which is perfectly okay, as long as you are "sharing" the password in a secure manner). Also, I'm not sure if a bank deposit box would make sense - passwords change to regularly for that. Nov 25 '20 at 9:54
  • @Conor Mancone - Yes devices like SoHo routers that don't support multiple accounts will have to share the single account access. In most cases a bank deposit box would be over kill, a locked cabinet or small safe is probably more common. The OP would need to decide on that. Nov 26 '20 at 1:22

Your employee is making themselves a severe liability, but we'll get back to that. Let's first address your question of access sharing.

Owner access is definitely required

You seem to know this already but it is worth emphasizing. An owner doesn't need to login regularly, but an owner needs to have the ability to step in if the current employee managing things leaves, is fired, or is just out on vacation. Does your employee plan to be available 24/7/365? If not, then there clearly needs to be a provision for someone else having access when needed.

It's time for an identity provider

It sounds like your employee is manually managing local admin passwords for your work station and servers. This works fine when there are just a handful, but doesn't scale. You need an identity provider to manage this access. This could mean things like LDAP or AD, or for more web-centric companies might mean things like Auth0 or Okta. These solutions are all designed to have multiple admins so at that point problem solved - you and the head of your IT department both have your own admin account in your identity provider, so you both have access as needed without sharing passwords.

Break glass access must be provided regardless

Your employee is really thinking about this the wrong way. These are, without question and without exception, company accounts, and as such the company must have access. Your employee has access because the company has granted that access - not the other way around. Your employee needs to be clear about that. An identity provider will make this process much easier, but in the meantime if your IT team configures a workstation or server and creates a local admin password on that machine, then that password needs to be stored somewhere so that the designated company representative can access the machine when needed.

@LvB has some good suggestions for sharing access securely. Personally I would suggest using an online password manager with the master password stored in a company safe (or other secure location). Your IT person can stay logged in to the password manager on their work computer, and anytime they "create" a new password they immediately store it in the password manager. If access is ever needed the owner can get the master password out of the safe, login to the password manager, and gain access as needed. Even better if the password manager supports a Yubi key or the like which is stored in a separate location.

This employee is quickly becoming a critical liability

For you though I really want to emphasize that this employee is not making sense and is quickly becoming your biggest liability. Intentionally or not, they are putting themselves in a position where they cannot be fired, but the opposite is not true - no aspect of this makes it so that they cannot quit. How bad would it be for your company if they left? How bad do you think it will be if this continues for a year and then they leave?

I'm guessing it would already be painful, but will only get more painful with time, which is why this needs to be addressed now. Your employee needs to understand that these are company accounts and the company needs access in the case that the employee leaves. In a small business, "the company" means the owner of course, and as the owner if you do something stupid with your access then that is on you. Your employee refusing to give others access is not a solution to protect the company. Some basic training and understanding on your part will help so that you understand that this isn't meant for daily access, but it sounds like you already understand that.

If your employee still refuses to give access then it is time for them to be let go before it gets worse. By misunderstanding security this employee is creating a severe company-wide denial of service risk, which will put you out of business if it continues for too long.


For a smaller organization with only one IT person, (or with 0 IT people and an external IT consultant), refusing to handing over access credentials to the owner is generally not OK.

For organizations in industries requiring compliance (e.g., PCI compliance), a documented security policy is typically required. Include "provide full-access credentials to the owner" in this policy. Require any IT staff to sign off on it (with an actual signature) every year. Yearly reviewing/signing off on security policies is often required for compliance.

In large organizations (i.e., organizations with multiple IT employees), it is typically not OK for the IT people to provide passwords to their boss (nor to the owner). What happens instead is that the organization's security setup has multiple trusted IT staff who have varying levels of access. Any security-sensitive requests by the owner must go through this staff. In some sense, the owner is not trusted enough for such access. This is more a matter of technical distrust, rather than fear that fear of intentional sabotage.

Further, giving the owner direct access (rather than having their needs be met less directly) may be a violation of security compliance, as many compliance policies require that people who do not need access don't have access. The owner does not necessarily need access.

Of course, all of the above can be countered by having a documented, internal policy that the owner gets passwords/access to everything. However, such a policy is typically not recommended for larger companies; a competent IT staff may resist it.

Final note: It is bad security practice (and forbidden by PCI compliance) to have shared credentials. If the owner is given access, it should be done through a separate set of admin credentials, not via password-sharing.

  • 1
    Your final note is not strictly true. There are legitimate cases where shared access is only possible through shared passwords, and PCI doesn't forbid this in all circumstances Nov 26 '20 at 12:37

It is never reasonable to ask your employee to disclose their account password. It is, however, reasonable to demand either that they change their password and hand over the account to you, or that they simply create a new account for you... or as a last resort, that they log in to the account for you.

The reason for this is that the password they are using on their account could very well be the same one they use for any number of services outside the company or for personal use. It's not surprising that they are pushing back on your demands for them to hand their password over; it's sensitive personal information and their password is theirs, regardless of whether you own the system.

If the actual issue is that they won't give you access to these systems at all though, that's a case where you can and should take them to court.

  • To go a step further: In many industries, such disclosure is a contract violation. E.g., organizations who sign a contract to comply with PCI are forbidden to allow multiple people to use the same set of credentials. Permanently transferring an account may be fine, but 2 people should never have access to the same account. All such transfers must be accompanied by a password change (since otherwise 2 people have access to the same account).
    – Brian
    Nov 25 '20 at 15:05
  • 2
    You've missed the bigger issue - if the employee is registering for an account for the company then it isn't their account password - it is the company's account and the company's password. If the employee has reused a password from a personal account or an old employees then they need to change it, and then work with the owner so the employee can have secure access to the company account - which is what it is. Nov 26 '20 at 11:13
  • @daniel The owner is not asking for the IT person's password. You've misread the question.
    – schroeder
    Nov 26 '20 at 13:00
  • @schroeder "He is refusing to share or supply these passwords" No, I haven't misread the question at all.
    – Daniel
    Nov 27 '20 at 0:34
  • @ConorMancone if the employee has set the password, it is their password. It's irrelevant whether the infrastructure the account is on is theirs or not. This is why no identity management systems allow admins to simply "view" a user's password - e.g. AD. It is hashed and there is an option to change it but not view it. This is for very good reason. The rest of your comment is correct though, and just repeats what I already said. If they've created an account then they have an obligation to change the password and hand over the account if the owner of the infrastructure requests it.
    – Daniel
    Nov 27 '20 at 0:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.