Who is accountable when a cracked service account is used for lateral movement?

Why This Matters for Security Teams

A cracked service account is not just a credential issue. Once an attacker uses it for lateral movement, the incident becomes an identity governance failure: the organisation has lost control of who owns the account, what it can reach, and how quickly it can be revoked. That is why investigations usually focus on the service identity lifecycle, not on Kerberos internals or the first alert alone.

This is also where NHI risk becomes operational. NHI Management Group research shows that only 5.7% of organisations have full visibility into their service accounts, and 71% of NHIs are not rotated within recommended time frames. Without ownership, expiry, and offboarding discipline, a compromised account can persist long enough to move across hosts, access secrets, and blend into normal service traffic. The control problem is broader than one account, as shown in the 52 NHI Breaches Analysis and the Ultimate Guide to NHIs — What are Non-Human Identities.

Security teams also need to map the event to enterprise control expectations. Standards such as the NIST SP 800-53 Rev 5 Security and Privacy Controls treat account lifecycle, access enforcement, and auditability as governed responsibilities. In practice, many security teams encounter accountability gaps only after the service account has already been used to pivot laterally, rather than through intentional identity ownership review.

How It Works in Practice

Accountability should be assigned to the team that owns the workload, the directory administrators who provisioned the account, and the approver who signed off on its privilege set. In a well-run environment, the service identity has a named business owner, a technical steward, a documented purpose, and an expiration or review cycle. That makes it possible to answer three questions quickly: who requested it, who approved it, and who can disable it.

When lateral movement occurs, response should not stop at containment. Investigators should compare the account’s expected behaviour with actual use, then trace which hosts, applications, and secrets were reachable. The attack path often resembles techniques documented in the MITRE ATT&CK Enterprise Matrix, especially where valid credentials are reused across systems. For NHI governance, the key issue is whether the account had unnecessary reach, weak rotation, or no clear offboarding owner.

• Confirm the human or system owner responsible for the service identity.
• Validate the approval trail for the privileges and target systems assigned.
• Check whether the account was supposed to be short-lived, rotated, or disabled after exposure.
• Review whether secrets were stored in code, CI/CD, or a vault with usable revocation.
• Document whether the compromise was enabled by standing access instead of just-in-time provisioning.

For practitioners, the best evidence usually comes from the identity platform, secrets manager, and endpoint telemetry together. The Dropbox Sign breach is a useful reminder that stolen credentials become far more damaging when ownership and revocation are weak. These controls tend to break down when service accounts are created ad hoc for legacy applications because no one can safely change the dependency chain.

Common Variations and Edge Cases

Tighter service-account control often increases operational overhead, requiring organisations to balance availability against revocation speed. That tradeoff is real in batch jobs, middleware, and legacy integrations where teams fear breaking production if they rotate too aggressively.

There is no universal standard for this yet, but current guidance suggests treating high-risk service identities differently from ordinary application accounts. Long-lived credentials should be replaced with short-lived tokens where possible, and access should be evaluated against runtime context rather than static role assumptions. This matters even more when an account is shared by multiple services, because shared ownership blurs accountability and slows incident response. The TruffleNet BEC Attack illustrates how stolen credentials can spread across a wide estate when identity boundaries are weak.

Another edge case is managed infrastructure where a platform team controls the directory object but an application team depends on it. In that model, accountability is shared, but it still must be explicit: one team owns the identity, another owns the workload, and both must know the kill switch. If that split is not documented, post-incident blame usually lands on the last team to notice the compromise instead of the team that approved the standing access in the first place.

Related resources from NHI Mgmt Group

• When does a service account become a compliance problem?
• Why do service account tokens increase lateral movement risk?
• Who is accountable when a service account used for API access is over-privileged?
• Who is accountable when privileged access is misused in a public service environment?