Internal Credential Sharing

A subject deliberately shares credentials for non-personal, persistent service accounts (e.g., admin, automation, deployment) with other individuals, either within or outside their team. These accounts often lack individual attribution, and when shared, they create a pool of untracked, unaccountable access.

Service account sharing typically emerges in high-pressure operational environments where speed or convenience is prioritized over access hygiene. Teams may rationalize the behavior as necessary to meet deployment deadlines, maintain uptime, or circumvent perceived access bottlenecks. In other cases, access may be extended informally to external collaborators, such as contractors or partner engineers, without proper onboarding or oversight.

When service account credentials are distributed, they become functionally equivalent to a shared key—undermining all identity-based controls. Investigators lose the ability to reliably associate actions with individuals, making forensic attribution difficult or impossible. This gap often delays incident response and enables repeated policy violations without detection.

Service accounts also frequently carry elevated privileges, operate without MFA, and are excluded from normal UAM logging, compounding the risk. Their use in this manner represents not just a technical misstep, but a structural breakdown in control integrity and accountability. In environments with compliance obligations or segmented access controls, service account sharing is a critical investigative red flag and should trigger formal review.

A subject deliberately shares credentials for an individually assigned user account with another person, or uses credentials assigned to another individual without authorization. Individually assigned accounts are intended to be used only by the assigned account holder and are governed by organizational policy, access control requirements, and identity management processes. Sharing or using another person’s account violates these controls by moving access outside approved provisioning, delegation, and review mechanisms.

User account sharing typically emerges where convenience, workload pressure, informal delegation, or perceived access delays are prioritized over account-use policy. Teams may rationalize the behavior as necessary for shift coverage, urgent operational tasks, peer assistance, or temporary access needs. In other cases, a subject may share or receive account credentials to avoid onboarding delays, bypass access request processes, or complete work without obtaining the permissions formally required for their role.

When user account credentials are shared, the receiving individual gains access through an identity that was not assigned, approved, or reviewed for their use. This can bypass role-based access controls, segregation of duties, conditional access policies, approval workflows, and access review assumptions. The infringement is not dependent on malicious intent; the policy violation arises from the unauthorized transfer or use of identity-bound access.

User account sharing may expose sensitive systems, regulated data, approval functions, administrative consoles, or business workflows to individuals who have not been formally authorized for that level of access. In environments with compliance obligations, privileged workflows, or strict access governance requirements, user account sharing should be treated as a significant infringement and reviewed against the organization’s Acceptable Use Policy, identity governance standards, and disciplinary or remediation processes.