Pipeline Credential Rotation (Retention)

Pipeline Credential Rotation (Retention)

1. 01

   Inventory every deploy key, SSH credential, and API token the pipeline touches

   Map each secret to the client account, the environment it reaches, and the person who created it. Anything with no named owner gets revoked at the end of this pass, not carried forward.

2. 02

   Set a rotation interval per credential class and write it into the client contract

   Deploy keys tied to a single repository can run on a 180-day cycle; tokens that reach production databases or cloud provisioning APIs should rotate every 90 days. Put the interval in the retainer scope so it is billable work rather than an internal chore.

3. 03

   Confirm the rotation path works in a staging environment before touching production

   DeployHQ and Railway both let you swap a key and redeploy without downtime, but the rollback path is what you are testing. If a bad key breaks the build, you need to know that in staging.

4. 04

   Rotate on a scheduled window and log the change against the client account

   Record the date, the credential class, the operator, and the deploy that confirmed the new key. A rotation with no log entry is indistinguishable from an outage six months later.

5. 05

   Verify the old credential is dead, not merely replaced

   Attempt an authenticated call with the retired key and confirm it fails. Platforms that keep a grace period will silently accept the old secret, which defeats the purpose.

6. 06

   Re-run the client's smoke tests against the rotated environment

   FeatureFlags.app style gradual rollout controls are useful here: flip a small percentage of traffic first, watch error rates, then complete the cutover.

7. 07

   Deliver a one-page rotation summary to the client contact each cycle

   List what rotated, what was retired, and what is due next. This is the artifact that turns a maintenance task into a visible line item on the retainer.