What Stays in Secrets Manager After Workload Identity?

I liked the question in a recent r/devops discussion: after moving workloads to identity federation, how many secrets are left?

The answer depends on where each credential crosses a trust boundary.

GitHub Actions can exchange an OIDC token for short lived cloud credentials. An application on AWS can use an IAM role instead of carrying an access key. AWS even supports temporary credentials for workloads outside AWS, provided you operate the certificate infrastructure needed to establish that trust.

Those changes remove a class of long lived credentials. They do not cause a payment provider, an older database, or a webhook sender to accept your cloud identity. Some secrets remain because the other system controls its own authentication method.

My recommendation is to migrate the paths that support federation, then give the remaining credentials more deliberate ownership. The useful measure is how much risk and work remain per credential, not the number of entries in a vault.

Draw the boundary before deleting anything

Consider a service that writes to S3, calls an external billing API, receives signed webhooks, and connects to an older SQL Server.

The S3 access key is a good candidate for removal. Give the workload an identity and a narrowly scoped role. The billing API key still exists because that API expects a key. The webhook signing secret still exists because the receiver must verify what the sender signed. The database password might remain until that particular server version, driver, and deployment can use another supported authentication path.

I would draw that as four separate edges:

The last line needs investigation, not an assumption. Some SQL Server deployments can use Microsoft Entra authentication; an older on premises deployment may have different constraints. Check the exact version and connection path before promising a passwordless migration.

There is another subtle point here. A workload role can authorize a service to read a secret from a manager. It does not remove the secret stored there. It improves how the service obtains that value and who may read it. The provider credential still needs scoping, rotation, revocation, and an owner.

A report saying “we use identity for all workloads” tells me little about the secrets inventory. I still want to know how each destination authenticates the caller.

The leftovers are often harder than the keys you removed

Cloud access keys are painful when they spread through CI settings and configuration files, but cloud platforms give us mature replacements. The remaining secrets may have awkward lifecycles.

One vendor lets you create a replacement key while the old key stays valid. Another gives you one active credential, so rotation requires a coordinated cutover. A webhook endpoint may accept more than one signing secret during a transition, or it may not. An appliance may require a manual change through a browser. A shared password may have several consumers that nobody documented.

These differences determine the operating procedure. A scheduled rotation button is useful only when the destination also changes and every consumer picks up the new value. AWS Secrets Manager's rotation documentation is explicit about updating both the stored secret and the database or service. Changing the vault entry alone is a reliable way to schedule an outage.

For each remaining credential, I would record:

Question	Why it matters
Who issues and revokes it?	Determines the actual recovery path.
Which workload uses it?	Limits access and exposes accidental sharing.
Can old and new values overlap?	Determines whether rotation can avoid downtime.
How does the workload reload it?	A new vault value is useless to a process holding the old one.
What happens if it leaks?	Sets urgency and containment steps.
Who can test the replacement?	Makes rotation an operation rather than a calendar reminder.

That inventory is more informative than “37 secrets remaining.” Two of those 37 might be broad production credentials with no tested revocation path. They deserve attention before twenty low privilege integration tokens.

Make migration reversible until the new path is proven

I would migrate one workload edge at a time. Start with a well understood cloud API call. Give the workload a role with only the permissions it needs, then run a real operation through the new identity. Check which principal appears in the audit trail. Check that the workload refreshes credentials before expiry. Run the job long enough to exercise a refresh, not merely its startup path.

Then remove the old key from the application's configuration and rerun the job. Only after that should you revoke the old key. Finally, search the places where copies tend to survive: CI secrets, deployment templates, local environment files, support scripts, and scheduled jobs. The old key may be unused by the main service but still active elsewhere.

For GitHub Actions, restrict which repository, branch, or environment can assume the cloud role. OIDC removes a stored cloud key, but a broad trust policy can still authorize the wrong workflow. The token exchange is only as narrow as the trust conditions and permissions on the role.

I would also test failure behavior. If federation is unavailable, does the job fail with a clear error? Does someone have a documented recovery path? Secretless authentication can still have a dependency on an identity provider, metadata endpoint, certificate authority, or token service. Those dependencies deserve monitoring.

Keep the secrets manager, but give it a smaller job

AWS describes Secrets Manager as a place for database credentials, application credentials, OAuth tokens, API keys, and other secrets. After federation, that list may shrink. The service still has a useful job: controlling access to values that cannot be replaced by an identity handshake.

I would organize the remaining inventory by system boundary and owner rather than by a generic prod/secrets folder. A billing key should be readable only by the billing workload. A webhook signing secret should be readable only by the verifier and rotation procedure. A database credential should have permissions that match the application's actual queries, with separate credentials for migration or administration.

Set rotation intervals according to the system's capability and exposure. Do not promise automatic rotation for a vendor that offers no safe API or overlapping credentials. For those cases, write a cutover runbook and rehearse it. A manual procedure that has been tested is better than an “automated” rotation that only changes one side of the connection.

There is a cost decision too. If a team has a small number of static credentials, it may not need another vault product or a custom broker. Reuse the secrets service already in the platform, provided it gives the team access control, audit history, and a workable recovery path. Additional infrastructure should solve a specific remaining problem.

What I would measure

The percentage of credentials replaced is easy to celebrate and easy to misread. I would track four operational results instead:

1. Which long lived cloud keys have actually been revoked?
2. Which remaining secrets have a named owner and known consumers?
3. Which credentials can be rotated without an outage, and when was that last tested?
4. How quickly can a leaked credential be identified and disabled?

Those answers tell us whether the migration changed production risk. They also expose the next improvement: a vendor integration to replace, a database auth path to modernize, or a shared key to split by workload.

Workload identity is worth adopting where it fits. It removes credentials that never needed to be stored in the first place. The interesting work begins after that, when the remaining list is short enough to read and inconvenient enough to deserve proper attention.