Why do credential rotations sometimes fail to stop lateral movement?

Because rotation changes the secret, not necessarily the live artefacts already issued from that secret. Kerberos tickets, session tokens, and similar credentials can remain valid after the password changes, so access continues until those artefacts expire or are revoked. That is why rotation and access termination must be treated as different controls.

Why This Matters for Security Teams

Credential rotation is often treated as a universal cleanup step, but rotation only changes the secret value, not every live session, ticket, or token already minted from that secret. That distinction matters because attackers rarely need the original password once they have an authenticated artefact. Guidance in the OWASP Non-Human Identity Top 10 and NHIMG’s Guide to NHI Rotation Challenges both point to the same operational gap: rotation without artefact revocation leaves a window for lateral movement.

This is especially visible in machine-to-machine environments where service accounts, API keys, and cloud tokens can be copied into automation, CI/CD runners, or agentic workflows. In those cases, the attacker’s path is not limited to reusing the rotated secret. They can pivot through cached credentials, delegated tokens, or long-lived sessions that were never tied to the rotation event. NHIMG’s Guide to the Secret Sprawl Challenge explains why those artefacts are hard to inventory in the first place. In practice, many security teams discover the gap only after an intrusion has already used an old session to move laterally, rather than through deliberate validation of token revocation.

How It Works in Practice

To stop lateral movement, teams need to treat rotation, session revocation, and access reduction as separate controls. A password reset may invalidate future logins, but it does not automatically kill all derived credentials. Kerberos tickets, OAuth access tokens, cloud STS sessions, signed URLs, and cached credentials can remain valid until their own expiry or explicit revocation. NIST’s SP 800-53 Rev. 5 separates credential management from session management for that reason, and NIST SP 800-63 Digital Identity Guidelines reinforces that authenticator lifecycle actions do not automatically terminate active sessions.

In operational terms, effective response usually includes:

• Rotate the secret or key material.
• Revoke active tokens, tickets, and temporary sessions issued from that identity.
• Invalidate cached credentials in CI/CD, agents, and orchestration platforms.
• Audit downstream trusts, such as role assumptions and delegated access paths.
• Shorten TTLs so stolen artefacts decay quickly even if revocation misses one path.

For NHIs, this is not just an IAM hygiene issue. NHIMG’s NHI Lifecycle Management Guide stresses that lifecycle state, secret state, and runtime access state must be managed together. The Ultimate Guide to NHIs — Static vs Dynamic Secrets is useful here because dynamic secrets reduce the blast radius, but only if the issuing system can also revoke what was already granted. These controls tend to break down in legacy environments with long-lived Kerberos trust, distributed caches, or cloud workloads that cannot be forced to reauthenticate cleanly.

Common Variations and Edge Cases

Tighter revocation often increases operational overhead, so organisations need to balance security response speed against service continuity. That tradeoff is especially sharp in high-availability systems, where aggressively killing sessions can interrupt jobs, break pipelines, or force unhealthy retries. There is no universal standard for this yet, but current guidance suggests designing for short-lived artefacts first, then using targeted revocation only where the blast radius justifies it.

Some environments also create false confidence because rotation appears successful on paper. For example, a cloud access key may be replaced while a federation session remains active, or a service account password may change while an application continues using a cached token. That is why the strongest pattern is defense in depth: rotate secrets, reduce TTL, revoke active artefacts, and verify that dependent systems actually rebind to the new identity state. NHIMG’s 52 NHI Breaches Analysis shows how often failures are compounded by poor lifecycle visibility rather than a single broken control. The practical lesson is simple: if the attacker already has a live token, secret rotation alone is usually too late.

Related resources from NHI Mgmt Group

• How should security teams stop lateral movement after an initial foothold?
• Why do IP-based microsegmentation rules fail to stop lateral movement?
• Why do standing privileges increase lateral movement risk so much?
• What do security teams get wrong about lateral movement prevention?