Treat every harvested credential as a separate trust relationship, not a single incident artifact. Revoke from clean systems, rotate the affected identities in the correct order, and assume that browser sessions, GitHub tokens, cloud keys, and SSH credentials may all have been used by the same attacker.
How to govern harvested tokens, cookies, and keys after compromise
Stolen credentials should be managed as multiple independent trust relationships, because a browser session cookie, a GitHub token, a cloud access key, and an SSH key each imply different scope, lifetime, and blast radius. The practical job is to remove attacker access cleanly, then re-establish trust in the right order without locking yourself out of recovery paths or leaving a reused secret active.
Why this is not a single revoke-and-move-on event
After compromise, the hard part is not only revocation, it is sequencing. If you rotate the wrong credential first, you can break the very systems needed to inspect logs, preserve evidence, or rotate the next dependency. If you assume one stolen token represents one account, you can miss linked sessions, refresh tokens, API keys, and automation credentials that were all usable from the same foothold.
Browser sessions are especially deceptive because they often sit beside password-based login, federated SSO, and long-lived refresh artifacts. GitHub tokens and cloud keys are different again: one may expose source control and build pipelines, while the other may grant direct infrastructure access. Treat the incident as a set of access paths that must be unwound, not a single compromised object.
How the reset order should be decided
Start by revoking from a clean administrative context, not from the possibly compromised workstation, browser, or automation runner. Then prioritize the highest-blast-radius credentials first, especially anything that can mint new access, pivot into other systems, or authenticate without human interaction. The secret sprawl challenge is a useful reminder that exposed secrets tend to cluster, so one compromised credential often means several more are sitting nearby.
For token families, revoke the session or refresh layer before or alongside the access token if the platform permits it. For keys, rotate the key pair, invalidate the old key, and verify all downstream integrations that depended on it. For SSH and cloud credentials, inventory where each credential was accepted before rotation, because replacing the secret is only half the work if stale trust remains in automation, CI/CD, or third-party tooling.
Where the compromise appears to involve OAuth or federation, it is worth treating the token chain as a lifecycle issue rather than a one-time theft. The Salesloft OAuth token breach shows why older tokens, connected apps, and refresh paths can remain dangerous long after the first compromise is detected.
Risk and Threat Considerations
The main risk is incomplete trust closure. An attacker who has one harvested credential often looks for adjacent credentials, shared sessions, or integrations that were never meant to be independently exposed. That creates repeat access, lateral movement, and re-entry even after the original secret is changed.
Failure mechanism: Teams rotate the obvious credential but leave sibling sessions, refresh tokens, API keys, or automation secrets active, or they rotate from an already-compromised system and leak the replacement immediately.
Impact: The attacker can regain access, continue exfiltration, or abuse the same trust chain through another entry point, turning a contained incident into a recurring compromise.
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 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST SP 800-57 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Covers stolen tokens, cookies and keys as exposed identity material. |
| NHI-01 — Improper Offboarding | Compromised credentials must be removed from all active trust relationships. | |
| NHI-07 — Long-Lived Secrets | Stolen long-lived tokens and keys stay usable after compromise. | |
| Recommendation — Rotate and revoke exposed secrets immediately from clean systems. Invalidate every lingering session, token and key tied to the incident. Replace long-lived credentials with shorter-lived, bounded alternatives. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Directly addresses lifecycle, revocation and rotation of compromised authenticators. |
| AC-2 — Account Management | Compromise response requires disabling and re-establishing affected accounts and access paths. | |
| AU-6 — Audit Record Review, Analysis, and Reporting | Incident cleanup depends on reviewing which credentials were used and where. | |
| Recommendation — Revoke and reissue authenticators under controlled lifecycle management. Disable affected accounts and revalidate all associated access. Correlate logs to identify all systems touched by the stolen credential. | ||
| NIST SP 800-57 | Key Lifecycle Management | Key compromise and rotation are central to the question’s handling of stolen keys. |
| Recommendation — Retire compromised keys and reissue them under a documented lifecycle. | ||
Practitioner Guidance
What to verify: Confirm which systems can mint, refresh, or reuse the stolen credential before you rotate anything. If the artifact can be exchanged, refreshed, delegated, or replayed, the cleanup scope is broader than the visible secret alone.
Decision rule: If the credential can reach production, automation, or source control, treat it as a high-priority trust boundary and revoke from a known-clean system first. If the credential is only a browser session, still check whether it was tied to SSO, developer tools, or cloud consoles that can silently persist access.
What practitioners underestimate: Replacement secrets are often compromised by process failure, not cryptography failure. The most common miss is rotating the key but not the surrounding access path, which leaves the attacker with another usable route or a fresh credential collected during the reset.
Practitioner takeaway: The goal is not simply to invalidate one secret, but to collapse every surviving path that secret opened, in an order that preserves recovery while denying the attacker a chance to observe or reuse the replacement.
Related resources from NHI Mgmt Group
- How should security teams govern API keys used for generative AI access?
- Should organisations govern API keys and service tokens like other non-human identities?
- How should security teams handle support cases and troubleshooting artifacts so session tokens and cookies are not exposed after an account compromise?
- Why do AI coding tool campaigns go after browser cookies, SSH keys, and cloud tokens?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 12, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org