Maybe a better solution to your situation is to design the system such that even if you are hit by a bus, and your credentials are lost forever, nothing bad happens.

Perhaps it's best to think of the problem as two problems, authentication and authorization.

Authentication establishes that you are who you claim to be. Some system can know that a request it really came from you because only someone with your credentials could have made the request, and only you know the credentials.

Authorization establishes that you are allowed to do a certain thing. A request can be authentic but not authorized.

If at least two people are authorized to do a thing, then it doesn't matter if one of them is hit by a bus. Alice may be killed by a bus, and knowledge of her credentials lost forever. But Bob knows his own credentials, and he's authorized to do anything Alice could do.

If the system is designed in such a way that anyone could be literally hit by a bus and killed, it also means it's possible to revoke one person's credentials. Former employees, especially those that leave on bad terms, are a security liability. You can't force a former employee to forget a password, so to be safe you should change all your shared passwords whenever an employee leaves. In practice this is too much of a pain and it isn't done. Not sharing passwords in the first place solves the problem.

Never sharing passwords also preserves accountability. You can't run a business with no administrators, but you'd like to have the ability to know if a particular admin abuses his powers. Ultimately the threat of termination or litigation dissuades any admin from abuse. If passwords are shared then "must have been one of the other admins with the password" is a plausible defense.

Maybe a better solution to your situation is to design the system such that even if you are hit by a bus, and your credentials are lost forever, nothing bad happens.

Perhaps it's best to think of the problem as two problems, authentication and authorization.

Authentication establishes that you are who you claim to be. Some system can know that a request it really came from you because only someone with your credentials could have made the request, and only you know the credentials.

Authorization establishes that you are allowed to do a certain thing. A request can be authentic but not authorized.

If at least two people are authorized to do a thing, then it doesn't matter if one of them is hit by a bus. Alice may be killed by a bus, and knowledge of her credentials lost forever. But Bob knows his own credentials, and he's authorized to do anything Alice could do.

If the system is designed in such a way that anyone could be literally hit by a bus and killed, it also means it's possible to revoke one person's credentials. Former employees, especially those that leave on bad terms, are a security liability. You can't force a former employee to forget a password, so to be safe you should change all your shared passwords whenever an employee leaves. In practice this is too much of a pain and it isn't done. Not sharing passwords in the first place solves the problem.

Never sharing passwords also preserves accountability. You can't run a business with no administrators, but you'd like to have the ability to know if a particular admin abuses his powers. Ultimately the threat of termination or litigation dissuades any admin from abuse. If passwords are shared then "must have been one of the other admins with the password" is a plausible defense.

Sometimes you run into situations where it seems impossible to avoid sharing a password. But there's usually a solution, even if it's not immediately obvious.

Do you need to share root passwords? No, you can not have a root password at all, and instead use sudo.

What about AWS root credentials? You can use IAM instead.

Maybe you have an especially brain-dead web application you can't avoid? You may not be able to fix this one but you can cover it up: use a password manager that allows sharing credentials among multiple users. (I know LastPass can do this). While you are still sharing the password, you at least have an automated means for changing it and distributing knowledge of the new password. Change the password at least whenever an employee leaves, but preferably more frequently.

Maybe a better solution to your situation is to design the system such that even if you are hit by a bus, and your credentials are lost forever, nothing bad happens.

Perhaps it's best to think of the problem as two problems, authentication and authorization.

Authentication establishes that you are who you claim to be. Some system can know that a request it really came from you because only someone with your credentials could have made the request, and only you know the credentials.

Authorization establishes that you are allowed to do a certain thing. A request can be authentic but not authorized.

If at least two people are authorized to do a thing, then it doesn't matter if one of them is hit by a bus. Alice may be killed by a bus, and knowledge of her credentials lost forever. But Bob knows his own credentials, and he's authorized to do anything Alice could do.

If the system is designed in such a way that anyone could be literally hit by a bus and killed, it also means it's possible to revoke one person's credentials. Former employees, especially those that leave on bad terms, are a security liability. You can't force a former employee to forget a password, so to be safe you should change all your shared passwords whenever an employee leaves. In practice this is too much of a pain and it isn't done. Not sharing passwords in the first place solves the problem.

It also means you have accountability. You can't run a business with no administrators, but you'd like to have the ability to know if a particular admin abuses his powers. If passwords are shared, then an admin can point the finger at the other admins, and you'll have to way to prove otherwise. If you never share passwords, a malicious admin will have to claim that his credentials were compromised, which is a much weaker defense.

Maybe a better solution to your situation is to design the system such that even if you are hit by a bus, and your credentials are lost forever, nothing bad happens.

Perhaps it's best to think of the problem as two problems, authentication and authorization.

Authentication establishes that you are who you claim to be. Some system can know that a request it really came from you because only someone with your credentials could have made the request, and only you know the credentials.

Authorization establishes that you are allowed to do a certain thing. A request can be authentic but not authorized.

If at least two people are authorized to do a thing, then it doesn't matter if one of them is hit by a bus. Alice may be killed by a bus, and knowledge of her credentials lost forever. But Bob knows his own credentials, and he's authorized to do anything Alice could do.

If the system is designed in such a way that anyone could be literally hit by a bus and killed, it also means it's possible to revoke one person's credentials. Former employees, especially those that leave on bad terms, are a security liability. You can't force a former employee to forget a password, so to be safe you should change all your shared passwords whenever an employee leaves. In practice this is too much of a pain and it isn't done. Not sharing passwords in the first place solves the problem.

Never sharing passwords also preserves accountability. You can't run a business with no administrators, but you'd like to have the ability to know if a particular admin abuses his powers. Ultimately the threat of termination or litigation dissuades any admin from abuse. If passwords are shared then "must have been one of the other admins with the password" is a plausible defense.