Credential Rotation and JIT Access¶

Standard procedure for scheduled rotation, JIT grants, and lockout recovery. Executes SPB-05, SPB-06, SPB-08, SPB-12.

Scheduled rotation¶

Trigger: cadence reached (default 90 days) or manual reissue.

Pre-flight.
Confirm the credential's label and current consumers.
Confirm rollback path: keep the old credential alive until the new one is verified.
Mint new. Same scope (SPB-04). Same runtime injection target.
Update consumers. Update env var binding / secret manager entry.
Verify. Run a known-good integration test. Capture pass evidence.
Revoke old. Only after verification. Audit: key_rotated (with old + new identifiers, never the secret value).
Update rotation timestamp in the credential entry.
Schedule next rotation.

Trigger: a privileged op (release tag, governance edit, bulk mutation) is requested and is approval-gated by SPB-06.

Request. Requester opens a JIT request with: action, scope, target, justification, expected duration.
Approve. Security owner approves with explicit expiry (default 1 hour).
Issue. Mint the JIT token with hard TTL ≤ approved duration.
Use. Token is bound to the requester or the named agent only; runtime-injected at execution time.
Audit each privileged action during the JIT window (SPB-12).
Auto-expire. Token expires automatically at TTL. Confirm via probe.
Post-action attestation. Requester records what was done; security owner spot-checks.

Symptom	First action
New credential rejected by service	Confirm scope; re-mint with corrected scope; do NOT widen scope to "make it work".
Old credential revoked but new not yet propagated	Re-deploy new credential to all runtimes; if any runtime is unreachable, halt that runtime until reachable.
Suspected leak post-rotation	Treat as compromise; emergency revoke; rotate dependent credentials; trigger SPB-14 incident response.
Rotation script failure mid-way	Use `orchestration-recovery.md` decision tree; never partially deploy a credential.