Who is accountable when a former employee account or stolen token is used in a breach?

Accountability sits with the organisation that failed to revoke, monitor, or scope the identity before it was abused. In practice that means IAM, platform, application, and security owners all share responsibility for lifecycle closure and privileged access oversight. If no one owns revocation, no one controls persistence.

Why This Matters for Security Teams

When a former employee account or stolen token is used in a breach, the failure is usually not the theft itself but the persistence of access after trust should have ended. That makes this an identity lifecycle problem, not just an incident response problem. A revoked user, an unexpired API token, or a still-authorised service credential can all become the attacker’s shortest path to data exfiltration, lateral movement, or privilege escalation.

NHIMG’s reporting on the 52 NHI breaches Report shows how often compromised identities remain exploitable long after ownership should have changed. The same pattern appears in token abuse cases such as the Salesloft OAuth token breach, where the identity was not “hacked” in a traditional sense so much as reused after it should no longer have been trusted. External guidance increasingly points in the same direction, including the Anthropic AI-orchestrated cyber espionage report, which highlights how quickly valid credentials can be operationalised once obtained.

In practice, many security teams encounter this only after an old account or token has already been used for access, rather than through intentional lifecycle closure.

How It Works in Practice

Accountability for abuse of a former employee account or stolen token sits with the organisation because the control failure is usually internal: access was not revoked fast enough, token scope was too broad, monitoring was too weak, or ownership was unclear. The practical issue is that traditional IAM often assumes identities are relatively static. Real breaches do not. They exploit accounts that were left active, refresh tokens that outlived the employee, or service credentials embedded in scripts and applications.

For practitioners, the response should treat human and non-human access as one lifecycle problem with separate enforcement points:

• Disable accounts and sessions immediately on termination, role change, or suspected compromise.
• Revoke refresh tokens, API keys, certificates, and delegated consent, not just passwords.
• Bind access to business context, so a token cannot be reused beyond its intended system, time window, or network zone.
• Log and alert on unusual reuse, such as login from new geographies, impossible travel, or API calls outside normal automation windows.
• Review privileged and service identities as rigorously as employee accounts, because both can persist after ownership changes.

NHIMG’s Guide to the Secret Sprawl Challenge is relevant here because stolen tokens usually succeed where secrets were never scoped, rotated, or inventoried properly. For implementation, current guidance from zero trust and identity security programs aligns with this: identities should be continuously verified, not trusted forever. The most useful control question is not “who had the account?” but “was the credential still valid, still monitored, and still limited at the moment of use?” These controls tend to break down when legacy applications share credentials, because ownership is diffuse and revocation can disrupt production unexpectedly.

Common Variations and Edge Cases

Tighter revocation often increases operational friction, requiring organisations to balance rapid containment against service continuity. That tradeoff becomes sharp when the “former employee account” is really a shared mailbox, a dormant admin profile, or a service account owned by multiple teams. Best practice is evolving, but current guidance suggests there is no universal standard for how much residual access is acceptable in these edge cases.

Stolen token cases also vary. An access token may expire quickly, while a refresh token, OAuth grant, or certificate can remain useful much longer. If the attacker already has a valid token, password resets alone may not matter. If the token belongs to a non-human identity, the breach can persist until the secret is rotated at the source and every dependent integration is updated. That is why incidents such as the MongoBleed breach and the Cisco Active Directory credentials breach matter to this question: they show that persistence often comes from identity sprawl, not a single failure point.

In high-autonomy environments, such as AI-driven workflows and service-to-service orchestration, valid credentials can be chained faster than teams can manually review them. That is why lifecycle ownership, short TTLs, and real-time monitoring must be assigned before a breach, not argued after one.

Related resources from NHI Mgmt Group

• Who is accountable when a supplier account is used in a breach?
• Who is accountable when a certificate expires and enables a breach?
• How should security teams govern API keys used for generative AI access?
• When does a service account become a compliance problem?