I'm trying to understand what remains after replacing long-lived cloud credentials with workload identity and OIDC. Using identities for services like AWS or S3 seems to eliminate a lot of rotation work, especially for CI runners and workloads that can obtain short-lived tokens.
However, federation only works when the other system supports it. Services such as Stripe, webhook integrations, SMTP, older on-premises databases, and various vendor tools may still require static API keys, passwords, or signing secrets. There may also be bootstrap credentials, certificate keys, and break-glass access that cannot disappear entirely.
For teams that have made this transition, roughly what percentage of your credential inventory went away? What kinds of secrets remained, and did those leftovers become easier to manage once the cloud credentials were gone, or were they the most difficult part because each vendor has different rotation procedures?
3 Answers
The most important check is whether the old credentials were actually removed. After one migration, a team found a service-account key still active in an unrecreated runner and another copy in an old environment variable. Search repositories, CI settings, deployment manifests, and cloned staging configuration instead of trusting the secrets-manager inventory alone.
For each remaining credential, record its owner, where it is used, its scope, its last rotation, and whether the vendor supports two active keys. Dual-key support lets you automate a safe overlap; single-key vendors need a planned cutover and can turn rotation into an outage risk.
In several environments, workload identity removed roughly 60–90% of the cloud-side credentials. The exact number matters less than what remains: third-party API keys, webhook signing secrets, SMTP credentials, legacy database logins, private signing keys, and break-glass access.
Those leftovers are often more troublesome than the credentials they replace because every vendor has a different process, and many do not provide a rotation API or support overlapping old and new keys. We still keep them in a central secrets manager, assign an owner and expiration date to each one, and automate rotation wherever possible. The cloud side should have no long-lived access keys; the remaining secrets should be treated as a small, explicit exception list.
Greenfield systems can get very close to identity-only access, but brownfield environments usually leave a substantial tail. Anything outside your trust domain still depends on whatever authentication the other party offers, and older databases or internal appliances may not support federation at all.
Even with SPIFFE or another workload identity system, you still need to protect the signing keys or certificate authority used to issue identities, along with recovery and break-glass procedures. Federation reduces the number of application credentials; it does not eliminate the need for secure key management altogether.
The percentage can be misleading. Our count dropped dramatically, but the remaining handful consumed about the same operational effort because each one required a different dashboard, approval process, or maintenance window.