A document-recognition service reads uploaded records and stores the extracted results. It originally received a permanent storage key. That key was later copied into testing, added to a recovery job and retained by an engineer for troubleshooting. Stopping the service and stopping use of its credentials are now different operations.
Workload identity ties access to a verifiable software identity. Instead of distributing a permanent key, a platform can issue temporary credentials to the appropriate workload. Secrets have not disappeared: their delivery, lifetime and the authority trusted to issue them have changed.
What the platform establishes
A workload is running software with a purpose and configuration, not necessarily an entire virtual machine. Document recognition and billing may run nearby while needing different permissions. One service can also have several instances sharing a workload identity.
The issuer links running software to an allowed identity through verifiable conditions. An arbitrary process must not be able to declare itself the billing service. The SPIFFE model describes workload identities and trust domains; isolation that prevents one workload from stealing another's credentials remains an important assumption.
This does not prove that the code is safe. A compromised program with a valid identity can exercise its legitimate permissions. The recogniser still needs a bounded input location and somewhere to write results, not access to the company's entire cloud account.
Trusting an issuer is only the beginning
For software running elsewhere, federation lets the destination accept evidence from an external identity system and grant access under agreed conditions. Google Cloud Workload Identity Federation is one example. Resource support and the actual permission-binding mechanism need checking.
The evidence must have an appropriate issuer, intended audience and workload identity. An automation provider may serve thousands of organisations. Accepting every token it issues would admit every tenant in the same office building.
Conditions should constrain the relevant organisation, application, environment and other meaningful claims. Google Cloud's recommendations discuss ambiguous identity mappings and shared issuers. A name another customer can register after deletion may also be unsuitable as permanent evidence of ownership.
Who can run software under that identity?
Access administration now extends beyond a secret store. Check who can attach the identity, replace the executable or launch other code under its authority. If a developer can give a test job the production identity, removing the permanent key has achieved little.
Separate test and production, identity assignment and permission on the destination resource. Record who obtained access, why and which operation followed, without logging the tokens themselves. One shared identity for every application would again make investigation and targeted revocation harder.
A short token lifetime does not stop repeated issuance
Stolen temporary credentials may remain usable until expiry or an additional revocation mechanism takes effect. While the issuer still accepts the compromised workload, it may obtain fresh credentials. Incident response must close that issuance path and restrict resource access rather than merely wait for one token to expire.
Existing connections can have their own lifecycle. Test access removal on both a new request and an established session. No universal promise of immediate revocation applies across every platform; establish the actual delay for the chosen arrangement.
Credential renewal is also an operational dependency. An established instance may have a valid token while a new instance cannot start. Test renewal during a long-running job, issuer unavailability and bounded retries. An expired credential must not quietly trigger fallback to a permanent administrator key.
The migration ends when the old route closes
Start with the recogniser and one storage resource. Verify access to its input documents and rejection for neighbouring data. Launch a fresh instance, exercise credential renewal and test access removal. Ensure the client library is not silently using a developer's personal account instead.
Revoke the original key after checking all necessary consumers, including recovery jobs. Leaving it indefinitely means the new mechanism was added while the old risk survived. An external API that only accepts static credentials will still need secrets management. That is a reasonable implementation boundary to record, rather than calling the whole platform keyless.