Revoke or rotate first — the first action and the rationale that forces it

Once scope is established, the first remediation action is revocation or rotation, not history rewrite. The rationale is forced by the physics: the credential is the access, and the attacker is using it from the moment the credential was committed. A history rewrite without a rotation is detective hygiene presented as a fix.

Why revoke or rotate first

The response sequence is forced by three facts:

flowchart LR
    A["secret committed"] --> B["attacker has access now"]
    A --> C["detector will alert eventually"]
    A --> D["audit channels have captured it"]
    B --> E["rotation stops access"]
    C --> F["history rewrite hides evidence"]
    D --> G["audit captures what happened"]
    E --> H["incident resolved"]
    F --> H
    G --> H

• Access is what the attacker uses. The attacker calls the API; the attacker does not care about the repository’s future.
• History rewrite is detective, not preventive. It stops the next scanner from alerting. It does not change the attacker’s ability to use the credential.
• Audit channels have already captured the secret. CI logs, registries, mirrors, and backups may have copies. Rotation makes them inert.

The order — disable, update consumers, rotate, revoke — is the only order in which each step builds on the previous.

Disable versus revoke versus rotate

The sequence that survives the audit is disable first, rotate second, revoke last.

The consumer-update sequence

Consumers must update before the old credential is revoked: CI runners, Terraform automation, GitOps controllers, local developer environments, vendors with cross-account roles. The sequence: issue the new credential, add it to each consumer’s secret store, verify each consumer authenticates against a non-destructive API call, roll the consumers over, confirm the old credential is no longer in use, then revoke.

Documenting the rotation

The rotation is documented with five fields: credential identifier, action with timestamp, operator, verification API call, and consumers updated.

Production discipline

1. Disable before revoke. Disable is reversible; revoke is not.
2. Consumers before revoke. Every consumer must hold the new credential before the old one is revoked.
3. Document the rotation. A rotation that is not documented did not happen for the audit team.

Cross-course references

• Linux for Production Sysadmins - Part XXXIV (KeyMgmt) covers the SSH and GPG key rotation patterns.
• Ansible for Production Sysadmins - Part XXXVIII (IncidentRunbooks) covers the runbook structure for credential rotation in automation.
• Terraform for Production Sysadmins - Part XV (CredentialRotation) covers the rotation patterns for Terraform-managed cloud credentials.

Quiz