Every operations team we have worked with has had at least one shared login. A dispatch account four people know. A vendor portal password in a pinned message. A read-only reporting user that quietly became read-write. The instinct is to treat this as a discipline problem and send a policy reminder. That reliably fails, because the policy was never the constraint. People share credentials because the alternative costs them something real, every day, and the risk costs them nothing until it does.
Why shared logins happen
It is worth being precise about the cause, because the remedy follows directly from it. In nearly every case we have looked at, one of three things is true.
- Per-seat pricing makes an occasional user cost the same as a full-time one, so the fifth technician who needs the system twice a week does not get an account.
- Provisioning is slow. A new hire waits nine days for credentials while their supervisor is expected to have them productive on day two, so the supervisor lends theirs and nobody circles back.
- Switching users is painful. A shared workstation that requires a full logout, a re-login, and a two-minute application load will get one session that stays open all shift.
Note that all three are decisions made by someone who is trying to get work done. That matters when you go to fix it. If you remove the shared credential without removing the constraint, you get a worse workaround: a password on a sticky note, a personal email address used as a relay, or work that stops being recorded at all.
The first cost: attribution disappears
This is the one that matters most, and it is the one least often stated plainly. A shared login does not weaken your other controls one at a time. It removes the foundation they all sit on.
An audit trail records that an action happened and who took it. Strip out the second half and what remains is a log of events with no accountable party. You can still see that a price was overridden, a record was deleted, or a payment was released. You cannot say by whom, and therefore you cannot answer the only question anyone asks after the fact.
The same logic runs through approvals. A two-person approval rule assumes two people. If both approvers use the same account, or if one approver's credentials are known to the person requesting the approval, the rule is decoration. Access reviews degrade the same way: you can confirm that an account has a set of permissions, but not whether the eleven people using it all still need them, or how many of them there actually are.
Offboarding, and why the rotation never happens
Offboarding is where the cost becomes concrete. When someone leaves, you disable their accounts. That takes minutes and nobody objects. But if that person also knew a shared credential, disabling their named account does nothing, because the shared password is still valid and they still know it.
The correct response is to rotate the shared credential. In practice, that means finding everyone who uses it, coordinating a change across shifts and locations, updating whatever scripts, scanners, integrations, and saved browser sessions depend on it, and absorbing the disruption when you miss one. It is a small project. Departures are routine. So the rotation gets deferred, and then it gets forgotten, and the credential outlives everyone who was originally given it.
Ask a straightforward question of any shared account: when was this last changed, and who has known it since? If nobody can answer, your access list for that system includes an unknown number of former employees. That is not a hypothetical risk. It is the current state.
Blast radius, least privilege, and the factor nobody enabled
A named account that is compromised gives up one person's access. A shared account gives up everything that account can reach, and it does so without any of the signals you would normally use to notice. Unusual hours, an unfamiliar location, or a second concurrent session all look normal on an account that ten people use across three shifts.
Shared accounts also drift upward in privilege, and they only drift one direction. When someone using the account needs to do something it cannot do, the permission gets added. Nobody ever removes a permission from a shared account, because there is no safe way to know who still depends on it. Over a few years the account converges on the union of every task anyone using it has ever needed. Least privilege is not weakened here; it is structurally unavailable.
Why multi-factor authentication was never turned on
Organizations with shared logins frequently also lack multi-factor authentication on the same systems, and the two facts are related. Multi-factor authentication assumes a factor belonging to one person. A shared account cannot satisfy that assumption cleanly. Either the second factor lives on one person's phone, which makes them a bottleneck for everyone else, or the factor is shared too, which removes most of its value.
So the rollout stalls, and the stated reason becomes something else: cost, user resistance, a system that does not support it. Worth checking whether the shared account is the actual blocker before you spend anything on the stated one.
Contracts and coverage: questions to confirm, not assume
This section is deliberately narrow, because it is not our field and it is not yours either unless it is. Several kinds of agreement can make statements about individual credentials. Software licensing terms often define a named user and prohibit sharing. Cyber liability policies and customer security addenda sometimes include representations about access controls. Regulated environments may impose specific requirements on unique identification.
We are not telling you what your agreements say or what your coverage would do. We are telling you that the answer is knowable and that you should know it. Pull the relevant contracts, policies, and customer addenda, and ask your counsel and your broker directly whether current practice matches what has been represented. Do that before an incident forces the question, when the answer is still useful.
What a shared login does to each control
| Control you think you have | What a shared login does to it | Minimum mitigation |
|---|---|---|
| Audit trail | Records the action but not an accountable person, so it cannot answer who. | Capture a separate individual identifier (badge, PIN, or initials) with every recorded action. |
| Segregation of duties | Requester and approver may be the same person using the same account. | Move approval steps to a system where every approver has a named account, even if the work itself does not. |
| Offboarding | Disabling the named account leaves the shared credential valid and known. | Maintain a register of who knows each shared credential, and rotate on departure as a scheduled task. |
| Least privilege | The account accrues the union of everyone's needs and never sheds permissions. | Split into several narrowly scoped shared accounts by function instead of one general-purpose account. |
| Anomaly detection | Odd hours, new locations, and concurrent sessions are all normal for the account. | Restrict the account to known devices or network ranges so unexpected origins are still visible. |
| Multi-factor authentication | The second factor is either a single person's bottleneck or shared and diluted. | Enforce the factor at the device or workstation layer rather than per login. |
Remedies, in order of cost
Work this list in order. The cheap items address the cause; the expensive items address the symptom. Doing them in the wrong order is how organizations spend money and end up with the same behavior.
- 1
Fix provisioning speed. Measure the time from hire approval to working credentials. If it is more than one business day, that is your root cause and it is an internal process problem you can solve without a vendor conversation. Do this first.
- 2
Address the licensing model. Get real numbers for how many occasional users are excluded by seat cost, then take that to a renewal conversation. Concurrent, role-based, or tiered read-only licensing often exists but is not offered by default. If the model cannot change, that becomes a documented input to the replacement decision rather than a vague complaint.
- 3
Use device-level or kiosk patterns where the workstation is genuinely shared. A shop-floor terminal, warehouse scanner, or front-desk machine can hold one authenticated device session while each person identifies themselves with a badge tap or short PIN. The session is shared; the identity is not.
- 4
Where a shared account must persist, scope it as tightly as the work allows, record an individual identifier with every action it takes, register who holds it, and set a rotation date rather than waiting for a departure to prompt one.
One caution on the fourth step. Recording an individual identifier alongside a shared session gives you attribution for operational purposes. You can see which technician closed the job or adjusted the price. It is weaker than authentication, because a user-entered identifier can be entered by anyone. Treat it as a genuine improvement over nothing and as an interim state, not as an equivalent to individual accounts.
When shared logins have become normal operating procedure alongside duplicate entry and spreadsheet workarounds, they are usually not the problem to solve on their own. They are a signal that the system is priced or structured in a way that pushes people out of it, and the durable fix is the one that removes that pressure.
Common questions
- Is a shared login always a security problem?
- It is always an attribution problem, which becomes a security problem as soon as the account can do anything consequential. A tightly scoped shared account that can only view a public price list carries little risk. The same pattern on an account that can release payments, change customer records, or export data is a different matter entirely.
- We can't afford a seat for every occasional user. What do we do?
- Start by quantifying it: count the users you are excluding and what a seat costs for each. That number is the input to a renewal negotiation, and concurrent or read-only licensing tiers often exist even when they are not quoted up front. If the vendor will not move, the cost of exclusion belongs in your total cost of ownership when you evaluate replacing the system.
- How do we handle a genuinely shared workstation?
- Separate the session from the identity. Let the device hold one authenticated session so nobody waits through a login cycle, and have each person identify themselves with a badge tap or short PIN before taking an action. You keep the speed people are protecting and recover most of the attribution you lost.
- Should we rotate shared passwords on a schedule?
- A schedule is better than nothing, but the event that matters is a departure. Rotate whenever someone who knows the credential leaves, and keep a register of who currently knows each one so you can tell. A scheduled rotation with no register still leaves you unable to say who has access today.
- Does using a password manager fix this?
- A password manager improves how the credential is stored and shared, which is worthwhile, and some can log which vault member retrieved an entry. It does not change what the target system records, and the target system still sees one account. Treat it as better hygiene around the problem rather than a resolution of it.
- Our licensing agreement may prohibit sharing. How exposed are we?
- That depends on the specific wording of your agreements and on facts we cannot see, so we will not characterize it. Pull the license terms, any customer security addenda, and your cyber liability policy, and ask your counsel and your broker whether current practice matches what has been represented. It is a short conversation and the answer is far more useful before an incident than after.