Verify Credential Replacement

A new credential may pass one smoke test and still fail a nightly job, secondary region, or rarely used webhook. Replacement verification has two independent halves: the new value supports authorized work, and the old value no longer grants access. Do not treat a configuration update as proof of either half.

Start with the caller inventory and a harmless operation for each workload. Use provider-side key IDs or safe fingerprints. OWASP's secrets guidance describes credential lifecycle controls, but each provider's revoke and propagation behavior must be checked directly.

Acceptance record

The table is a worksheet, not a claim about a real deployment. Add the actual regions, jobs, and providers. Test only operations the team owns and may call. Where an old-key request would expose the value again, use provider status as rejection evidence instead of replaying it through a new tool.

Observe and close

Check application errors and provider usage for the agreed window. A service can cache a token or use a different secret path than the one you changed. Include cold starts, retries, and worker restarts. If a caller fails with the new credential, fix its scope or configuration through a reviewed change; do not re-enable an exposed old key without an explicit incident decision.

Record time, provider response class, deployment version, and owner signoff. Keep values out of logs and evidence. Mark untested callers as pending rather than asserting completion. A provider may not support immediate revocation or dual-key overlap. State that limit and the compensating controls. Verify the provider's old-key denial and the replacement caller's health; a receipt tracker cannot establish either state alone.