Our shared work login locked us out after someone changed the password, and nobody knows who did it. This account is used by my team of 7 because it controls a work service we all need during the day, but we currently pass the credentials around in a private chat.
What is the proper way to manage a login the whole team uses without losing access or making the password visible to everyone? Is this called a shared account, credential sharing, or something else? We may not be able to create separate users in the service, so how should password changes, recovery details, and access for people leaving the team be handled?
Realistically, if seven people can use the same credential, you cannot guarantee that none of them can extract or misuse it. A tool can hide the password during normal autofill, but that is mainly protection against casual copying. Separate named accounts with roles and audit logs are the proper solution whenever the service supports them.
If the service truly allows only one login, this is usually called a shared account or shared credential. Stop passing it through chat and put it in a team password vault. Bitwarden, for example, has a free password manager, though you should check which team controls, access reports, and administrative features require a paid plan. Give each employee their own vault login, then grant access to the shared work credential. Nobody should share the password manager’s master login.
Assign at least two trusted people as owners of the shared vault. Put the service’s recovery email under a company-controlled mailbox, not an employee’s personal address or phone number. Store backup codes securely, require MFA where possible, and document who is allowed to change the password. A password change should be made in the vault first or updated there immediately, with the team notified through a non-secret message such as “credential rotated.”
When somebody leaves, remove their individual vault access, revoke their active sessions if the service permits it, and rotate the shared password and MFA recovery codes. That last step matters even if the vault never displayed the password, because someone who could use the account may have copied credentials or retained a session.
The major drawback is accountability. The service itself will usually record all seven people as the same user, so you may not be able to tell who changed a setting or deleted something. A password manager can improve access records, but it cannot fix the service’s shared identity. If this account controls anything sensitive, paid seats or a service that supports separate users may cost less than investigating the next lockout.
2 Likes
Stop having multiple people hit “forgot password” or guess the new password, because that can extend the lockout or trigger a fraud hold. Pick one person to handle recovery, check the company mailbox for reset notices, and contact the service’s support team if the reset trail is unclear. Once access is restored, sign out every existing session before issuing a new credential.
@devfalcon4190 is right that a vault helps, but first check whether the service even permits seven employees to operate through one login. Some plans prohibit shared access or make password recovery intentionally difficult when activity comes from several devices and locations. If named users are available, ask the vendor whether they can convert the existing account without losing its data or settings.
If separate seats are genuinely not an option, appoint a primary account custodian and a backup. Everyone else can use the account, but only those two should be allowed to reset credentials, change MFA, or contact support. That small restriction will not create perfect accountability, but it should prevent another mystery password change.
A forced “sign out everywhere” can create a second outage if that login is tied to scheduled reports, browser extensions, integrations, or a device nobody remembers setting up. Before doing that, make a quick inventory of anything that depends on the account. If compromise is suspected, security wins and you revoke immediately, but for an internal password mix-up you can avoid breaking half the workflow by checking first.
I’d separate normal use from account administration. The team can access the service, but password changes, recovery settings, MFA enrollment, billing, and integrations should be restricted to two people. If the service cannot enforce that, write it down as a team rule and enable change notifications wherever possible. Anyone who receives a password-reset email they did not request should post a warning, not click through and “fix” it themselves.
Keep a tiny recovery runbook somewhere outside that service: vendor account number, company recovery mailbox, authorized support contacts, where backup codes are stored, and what systems need testing after a credential change. That document is boring right up until the next lockout, when it saves everyone from guessing.
Longer term, check whether routine work can use individual accounts while automation uses a separate service account or API credential. Seven humans and several background jobs all sharing the same password is where password rotation turns into an office-wide scavenger hunt. A vault improves distribution, as @devfalcon4190 said, but documenting dependencies is what keeps the next rotation from breaking things nobody connected to the login.
If this login can spend money, export customer data, change billing, or delete records, treat the lockout as a possible security incident rather than an office password mix-up. Until someone can match the change to a known employee and a legitimate reset email, you do not actually know that the person who changed it was on your team.
Have the designated recovery person ask the vendor for the time of the password change, source IP or device information if available, and any actions taken afterward. Preserve audit emails and screenshots before resetting anything. @foxking is right to check integrations before signing out every session, but I would not let that inventory delay revocation when the account has sensitive privileges. A broken report is inconvenient. An unknown session with billing or data access is worse.
After recovery, reduce what this shared identity can do. Remove stored payment methods if they are unnecessary, enable spending or usage limits, turn on alerts for login and administrative changes, and export activity logs regularly if the service offers them. Keep critical data backed up somewhere the shared account cannot delete. The password vault solves distribution, but it does not limit the damage caused by someone who already has valid access.
I would set a deadline for replacing the arrangement rather than accepting “the vendor only gives us one login” forever. Ask about read-only users, delegated access, an enterprise plan, or a separate operator role. If the answer is still no and the account controls anything important, that limitation belongs in a risk decision made by management, not an informal team habit. At minimum, document that only the two custodians may change credentials, and make unauthorized password changes something the team reports immediately instead of quietly trying to repair.
