How Do You Prove an Old CI Cloud Credential Is Retired?

Close a CI credential migration with evidence of the replacement identity, disabled legacy access, resolved consumers and existing-session handling. Separate a quiet...

A passing deployment leaves the old access path untested

A pipeline can authenticate through workload identity while its previous cloud access key remains active. The release succeeds, the migration ticket closes and the forgotten credential can still be used elsewhere. Retirement needs evidence from both sides: the replacement works for the intended jobs, and the old access path has been closed. Removing one secret from a repository proves only that one stored copy was removed.

Consider an illustrative migration with a release workflow, a nightly integration test and an infrequent recovery job. The release workflow now uses a deployment role. The other jobs have not run since the migration. If the engineer disables the shared key after checking only the release, the nightly test might fail. If the engineer keeps the key active to avoid that possibility, the access migration remains unfinished. Neither outcome should be hidden behind a successful release. This scenario is proposed guidance, not a report about an Ampity customer or an audit of your accounts.

The owner should close three separate questions: which consumers still depend on the old credential, whether the credential can authorize new activity, and whether sessions or effects created earlier still need handling. Each question needs its own evidence and completion state. A status such as retired is useful only when the scope behind it is explicit.

Inventory consumers without copying the secret into the review

Start with an account, principal and credential identifier, then connect that identifier to known consumers. Record repository or project, environment, job, owner, execution frequency and source of configuration. Use identifiers in a restricted record rather than pasting secret values into tickets or chat. The review should let an authorized engineer trace a dependency without creating another credential copy.

Inspect the configuration surfaces used by the actual CI system. Candidate surfaces include organization secrets, repository secrets, environment secrets, runner configuration, deployment scripts and external secret stores. These are places to investigate, not a claim that every pipeline has them. A job can inherit an environment variable or load a credentials file without referencing the secret name used in the repository. A search for that name may miss the effective runtime source.

Include scheduled and manual workflows, release tags, reusable workflows and recovery procedures that run less often than normal deployments. For each consumer, mark observed replacement, still dependent, obsolete with approval, or unresolved. Give unresolved entries an owner and follow-up date. Do not turn an unexecuted disaster-recovery job into an observed migration result because its YAML resembles the main release job.

Search secret-bearing artifacts through approved security tooling and access controls. Avoid downloading build artifacts to a personal folder merely to hunt for a key. If evidence suggests exposure, follow the incident process, with prompt containment appropriate to the case. Routine migration scheduling should not delay handling a potentially compromised credential. The article's planned retirement sequence assumes there is no known active compromise.

Last-used data helps find work, but cannot close the ticket alone

AWS provides credential reports and access-key last-used information, including a last-used date, service and Region where available. That helps prioritize investigation and compare known consumers with observed usage. See AWS guidance on finding unused credentials. Keep the observation time with the report so another engineer can tell when the evidence was collected.

An old last-used date does not prove that a credential has been disabled. A dormant job may need it next month. A manually invoked recovery script may need it only during an incident. Treat inactivity as a lead for investigation, then establish the provider-side state and resolve the consumers. Choose an observation period based on their schedules and criticality rather than declaring one universal number of quiet days sufficient.

Evidence has collection limits. Record which accounts, principals and jobs were inspected, which activity records were available and which time interval was covered. If a consumer owner cannot be identified, keep the dependency unresolved. If the audit trail has a gap, show the gap. The resulting record can support a scoped conclusion, such as the listed release and integration jobs migrated successfully, without pretending to establish organization-wide absence of credential use.

Exercise the replacement without an automatic legacy fallback

For each required job, verify the effective identity and intended cloud target during a controlled execution. A successful deploy command is insufficient if the SDK obtained credentials from an unexpected source. Review precedence and inherited configuration for the actual toolchain. Capture the principal or role used, target environment and run identifier with sensitive values removed. The evidence should identify which authentication path produced the successful operation.

Test the replacement with the old credential unavailable to that execution. Otherwise the pipeline may quietly succeed through fallback configuration. Scope this test to the job under review; removing a shared secret across every consumer before inventory is complete creates an avoidable outage. Use a harmless target or isolated environment where feasible, and retain what was tested. Production-only behavior may require a separate approved release check.

Treat permissions and authentication as different results. The replacement can authenticate yet lack permission for a deployment step. It can also have broader permissions than intended. Record the needed operations and relevant denied operations, then reconcile failures with the correct layer. The companion article on workload identity trust policies covers accepted identity and resource scope. This retirement review asks whether the legacy path remains usable after the replacement is established.

Use a retirement record with separate acceptance states

The following five-row record is a proposed acceptance artifact for the illustrative migration. It keeps operational readiness separate from access closure. Each row needs an owner, observation time and restricted evidence location in the real change record. Use pending when a result has not been observed; do not fill every cell with pass because the main release succeeded.

| Review boundary | Evidence to retain | Unresolved condition | | --- | --- | --- | | Required consumer migration | Intended identity and successful controlled run | A scheduled or recovery job has not been tested | | Provider-side legacy key state | Credential identifier, disabled state and observation time | Only a repository secret was removed | | Existing temporary sessions | Relevant session scope and documented closure decision | Session lifetime or access remains unknown | | Stored legacy copies | Inspected locations and disposition under retention controls | Unowned runner configuration or artifact copies | | Migration reversal | Approved replacement access path and responsible owner | The old key can be re-enabled without review |

The stored-copy row has a different purpose from provider-side closure. An inactive copy should not restore authentication while the provider keeps the key disabled, but leaving sensitive material in uncontrolled locations still requires cleanup. Follow retention and incident requirements when deciding whether artifacts can be removed. Do not promise that removing a current secret purges historical logs, backups or external stores.

Disable, observe and handle existing sessions deliberately

For routine IAM access-key retirement, AWS documents deactivation and deletion separately and recommends verifying that a key is no longer used before permanent deletion. See AWS access-key management guidance. Plan the change with the authorized owner. Record the exact credential identifier and resulting state, then observe the known workloads for missed dependencies before the approved deletion step.

Do not rely on one failed request as sole proof of deactivation. A request can fail because the test used the wrong account, lacked an unrelated permission or could not reach the endpoint. Combine provider-side readback with correctly scoped verification. Any test involving a legacy secret must use the approved secure execution path, without revealing the value or granting unnecessary resource authority.

Existing temporary credentials need their own treatment. AWS explains that their permissions are evaluated on requests and that permission changes may take time to take effect. It also documents considerations for resource-based grants. See AWS guidance on disabling temporary credential permissions. Identify the relevant session type and grants before choosing a containment or closure mechanism. Disabling the original access key should not be described as universal instant revocation of every session it may have helped create.

For IAM roles, AWS's documented session-revocation procedure applies a deny policy based on the session issue time and can disrupt other users of that role. See AWS role-session revocation guidance. Review affected users and automation before such a change. A shared role makes the scope broader than one migrated CI job. Keep completed changes and business effects separate from future access: blocking a session does not undo an artifact upload or infrastructure change already accepted.

Close unresolved dependencies instead of keeping an unnamed fallback

A migration fails when an infrequent consumer breaks and the team re-enables the old key without recording why. Establish a reversal owner and permitted recovery path before deactivation. If temporary replacement access is required, make its scope, approval, expiry and follow-up explicit. Do not label the key retired while the normal rollback procedure restores it automatically.

There are limits to this review. It covers the identified CI consumers and credential path. It does not establish that every cloud identity in the organization is safe, that no historical exposure occurred or that every completed action was authorized. Those questions need separate investigations. Keep the conclusion narrow enough that the evidence can support it.

The next action is to select one legacy CI credential and complete the five-row record with its owner. Resolve scheduled and recovery jobs, exercise the replacement without legacy fallback, and agree the provider-side closure and session-handling steps before changing access. Bring that record to a cloud security review if dependencies or permissions remain unclear. For the separate question of which executable code the credentialed job may run, use the AI software supply-chain paper.