A single set of credentials used by more than one person or role. Shared logins reduce accountability because actions cannot be cleanly attributed to an individual, which weakens audit trails, incident response, and lifecycle governance in environments that need precise access ownership.
Expanded Definition
A shared login is any credential set used by multiple people or roles, whether that access is tied to a console account, a service portal, or an operational break-glass path. In NHI and IAM practice, the problem is not only that the password or token is reused, but that the access path stops being attributable to one accountable identity. That breaks the link between action, approver, and operator, which is central to auditability and lifecycle control.
Usage in the industry is still evolving because some teams treat shared access as a temporary convenience while others treat it as an operating model for shift work or vendor support. NHI Management Group recommends treating any shared credential as a risk-bearing exception, not a normal access pattern, and aligning it with the governance expectations reflected in the NIST Cybersecurity Framework 2.0 and the broader lifecycle controls described in Ultimate Guide to NHIs.
The most common misapplication is calling any group-authorised access a shared login, which occurs when organisations confuse role-based entitlement with a single credential used by multiple individuals.
Examples and Use Cases
Implementing alternatives to shared logins rigorously often introduces onboarding and support overhead, requiring organisations to weigh faster access provisioning against stronger accountability and revocation discipline.
- A night-shift operations team uses one admin password for a production server, making it impossible to prove which operator ran a disruptive command.
- A contractor support desk signs into a customer portal with one shared account, so incident logs show only the team identity instead of the person who made the change.
- A break-glass account is shared across multiple engineers without individual attribution, which creates ambiguity during post-incident review and change validation.
- A legacy automation script uses a human shared login instead of a dedicated service account, blending person access with machine execution and complicating offboarding.
- An organisation replaces a shared login with individual access plus privileged session controls, preserving traceability while still supporting urgent access needs.
These patterns are discussed in NHI governance guidance such as Ultimate Guide to NHIs, and they map cleanly to identity governance expectations in the NIST Cybersecurity Framework 2.0.
Why It Matters in NHI Security
Shared logins undermine the core NHI security requirement that every action should be traceable to a specific operator, workflow, or automated identity. When credentials are reused, secrets are harder to rotate, privilege review becomes unreliable, and incident response loses the evidentiary chain needed to determine whether access was legitimate or abused. This matters even more in environments where service accounts, API keys, and operational tooling already create a large identity surface.
NHIMG research shows that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, and 68% of organisations do not know how to fully address NHI risks, which makes ambiguous access patterns even more dangerous. Shared logins also make it easier for excessive privilege to persist unnoticed, especially where offboarding is weak and access is never individually reviewed.
For governance teams, the issue becomes unavoidable after an alert, an outage, or a suspicious change cannot be tied to a person. Organisations typically encounter the operational cost of shared logins only after a security event or failed audit, at which point identity attribution becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Shared logins defeat accountability and individual attribution in NHI access governance. |
| NIST CSF 2.0 | PR.AC-1 | Access control requires identities and permissions to be uniquely managed and attributable. |
| NIST Zero Trust (SP 800-207) | Zero Trust depends on per-subject verification, not ambiguous shared credential use. |
Assign unique identities, review access ownership, and eliminate reuse of one credential by many users.
