Credential Revocation

Credential revocation removes the ability to use previously trusted authentication material. In cloud incident response, it is a containment action: responders stop an attacker from continuing to access APIs, applications, or infrastructure using stolen credentials. Revocation can mean disabling an access key, invalidating a session, revoking a certificate, or applying an authorization rule that denies requests made with affected credentials. The implementation depends on what validates the credential and whether that validator supports immediate invalidation.

Begin by identifying the compromised identity, credential type, permissions, and dependent workloads. Preserve relevant audit records and credential identifiers without copying secret values into incident tickets. Investigate whether the attacker created additional keys, assumed roles, established application sessions, or modified trust policies. Disabling the originally exposed credential is insufficient if another usable access path remains.

For example, when a long-lived cloud API key appears in a public repository, disable the key promptly and examine its activity. Removing the secret from the repository does not invalidate copies already obtained by an attacker. Issue replacement credentials only through a trusted recovery process, update authorized consumers, and remove the obsolete key after preserving necessary evidence. Prefer workload identities and short-lived credentials over distributing another permanent secret.

Temporary credentials require different handling. On AWS, disabling an IAM user's access key does not automatically invalidate temporary credentials already issued using that key. Changing a role's trust policy can prevent new role assumptions but does not, by itself, stop existing role sessions. IAM role session revocation uses an explicit deny policy with a token-issue-time cutoff to deny requests from older sessions. This is authorization-based containment rather than deletion of individual AWS Security Token Service tokens. Keep the deny effective until the affected credentials have expired, and prevent the attacker from obtaining newer sessions.

Application tokens have similar limitations. A signed, self-contained token may remain acceptable until expiration unless the application checks a revocation mechanism, session state, or another authoritative control. Revoking a refresh token does not necessarily invalidate access tokens already issued from it. Likewise, changing a stored database password must change the credential at the database; merely updating a secret's stored value does not revoke the old password, and established database connections may require separate termination.

Revocation trades availability for containment. Disabling a shared credential can interrupt many healthy workloads, while gradual rotation can leave an attacker access during an overlap period. During confirmed compromise, prioritize stopping unauthorized access, scope controls carefully, and use trusted emergency access to avoid locking out responders. Account for policy propagation and application caches rather than assuming every validator changes instantly.

Credential revocation is not complete eradication or recovery. Isolate affected workloads when necessary, remove persistence, correct the exposure mechanism, and rebuild compromised resources from trusted images or restore validated backups. Network isolation alone does not stop stolen credentials from being used elsewhere. Before restoring service, verify that old credentials fail, replacement credentials work only for intended consumers, and audit activity shows no continuing unauthorized access.