Workload Identity Compromise Response Playbook

When a federated workload identity is abused there is usually no secret to rotate: the attacker holds a short-lived token, or the ability to mint new ones through a trust relationship you configured, so the standard "rotate the key" playbook does nothing. This guide is the response procedure for compromised secretless workload identities: OIDC trust between a CI system or external cloud and your cloud roles, Microsoft Entra federated identity credentials, Google Cloud Workload Identity Federation, Azure managed identities, SPIFFE SVIDs issued by SPIRE, and Kubernetes service account tokens. For each it sets out how to stop new tokens being minted, how to neutralise tokens already issued, and how long residual access lasts. It is written for cloud security, platform and incident response teams. For leaked static keys and service principal secrets, use the Cloud Credential Compromise Playbook; for how federation is designed, the Workload Identity Federation Guide.

Key takeaways

Two separate jobs: stop issuance (remove or narrow the trust, disable the provider, delete the registration entry) and neutralise tokens already issued (deny policies on issue time, removing role assignments, waiting out a known lifetime). Doing only the first leaves the attacker working until expiry.
Residual lifetime varies by platform: from minutes for CI OIDC tokens and default SPIRE SVIDs, through hours for AWS role sessions, to around 24 hours for cached Azure managed identity tokens affected by group or role membership changes.
The trust is the credential: a broad subject condition (any repository in an organisation, any branch) is the commonest root cause, and the fix is narrowing the trust, not rotating anything.
Look for added trust: an attacker with administrative access can add a federated credential or identity provider as persistence (MITRE ATT&CK T1484.002 Trust Modification). Enumerate every trust on the affected identity, not only the one you know about.
Prefer deny over delete: a time-bound deny or a disabled provider can be reversed quickly if you contain the wrong thing; deleting identities loses evidence and breaks role assignments.

How the compromise shows up

Signal	Likely cause	First question
Role assumed via web identity from a repository or branch you do not recognise	Over-broad OIDC `sub` condition	Which trust condition allowed it?
New federated identity credential, OIDC provider or workload identity pool provider created	Persistence by an attacker with admin rights (T1484.002, T1098.001)	Who created it and from where?
Managed identity token used from outside its resource, or unusual calls from a VM or function	Code execution on the resource, or metadata endpoint access (T1552.005)	Who can run code on that resource?
SVID presented by a workload on an unexpected node	Node compromise, or registration entry with weak selectors	Which agent issued it?
Kubernetes service account token used from outside the cluster	Token read from a pod or leaked legacy Secret token	Bound or legacy token?
Pipeline compromise reported for a CI system you federate with	Attacker can run jobs that request OIDC tokens	Which cloud roles trust that CI issuer?

Triage questions

Which identity, and which trust? Record the role, managed identity, app registration, service account or SPIFFE ID, and every trust relationship attached to it (issuer, subject, audience, conditions).
Is issuance still possible? If the attacker controls a job, node or resource that satisfies the trust, they can mint fresh tokens at will. This decides urgency.
What is the residual lifetime? Use the matrix below to set when containment is actually complete.
What can the identity reach? List its role assignments, policies and downstream secrets. Secretless identities often read secrets from a vault, which turns this into a secret rotation incident as well.
Was trust added or changed? Query control-plane audit logs for federated credential, identity provider, pool provider and registration entry changes over the last 90 days.

Containment by platform

Platforms are listed alphabetically. Each row states how to stop issuance, how to neutralise tokens already issued, and the residual window, from each provider's documentation as checked in November 2026. These are customer-side controls; confirm current behaviour in the provider's documentation.

Platform	Stop new tokens	Neutralise issued tokens	Residual window
AWS IAM roles with OIDC or SAML federation	Narrow the role trust policy: set `token.actions.githubusercontent.com:sub` to a specific repository and branch with `StringEquals`, keep `aud` set to `sts.amazonaws.com`; or remove the federated principal	Role > Revoke sessions > Revoke active sessions, which attaches `AWSRevokeOlderSessions` denying credentials issued before that time (`aws:TokenIssueTime`)	Ends at revocation, subject to eventual consistency; without it, until the role session expires
Azure managed identities	Remove the identity from the compromised resource, or stop the resource; for user-assigned identities, detach or delete	Remove direct role assignments on target resources; Microsoft states a managed identity token cannot be force-refreshed	Back-end services cache tokens per resource URI for around 24 hours, so group or role membership changes can take several hours to apply
GitHub Actions OIDC (as the issuer)	Disable the compromised workflow or repository, protect deployment environments, and narrow every cloud trust that names the repository	Tokens are valid only for a single job; neutralise the cloud credentials they were exchanged for on the cloud side	The OIDC token itself is short-lived (the documented example spans 300 seconds); cloud sessions follow the cloud row
Google Cloud Workload Identity Federation	Disable the provider (`gcloud iam workload-identity-pools providers update-oidc` or `update-aws`) or the pool (`gcloud iam workload-identity-pools update`); Google recommends disabling before deleting	Remove the IAM bindings granted to the pool principals or the impersonated service account; apply an IAM deny policy where needed	Google's page does not state how already-issued tokens behave; assume they last until expiry and remove bindings
Kubernetes service accounts	Delete the compromised pod; for legacy Secret-based tokens, delete the Secret	Remove RBAC bindings and cloud trust mapped to the service account; see the service account token rotation guide	Bound tokens expire on their set lifetime; legacy Secret tokens do not expire until the Secret is deleted
Microsoft Entra federated identity credentials	Delete the federated identity credential on the app registration or user-assigned managed identity; issuer, subject and audience match case-sensitively, so check every FIC on the object	Remove role assignments and API permissions the app or identity holds	Access tokens already issued last until expiry
SPIFFE and SPIRE	Delete the registration entry (`spire-server entry delete`); evict a compromised node with `agent evict` or prevent re-attestation with `agent ban`	For a compromised signing authority, use the `localauthority` commands (prepare, activate, taint, revoke) to move signing to a new authority and remove the old one from the bundle	SPIRE defaults: X.509 SVID 1 hour, JWT SVID 5 minutes, CA 24 hours, unless your server configuration changes them

Platform guides: How to audit AWS IAM Roles Anywhere and OIDC identity providers, Azure Managed Identities Security Guide, GitHub Actions OIDC Federation Hardening Guide, How to move GKE workloads from keys to Workload Identity Federation, Kubernetes Service Account Token Guide and SPIFFE and SPIRE Guide.

Containment priorities

Cut the issuer path (first 30 minutes): disable the workflow, node, pod or resource that the attacker uses to satisfy the trust. If you cannot identify it, narrow or disable the trust itself.
Neutralise live tokens: apply the "neutralise" column. Where the platform cannot revoke individual tokens, remove the permissions those tokens carry.
Enumerate all trusts: list every federated credential, OIDC provider, workload identity pool provider and registration entry in the affected accounts, subscriptions and projects. Disable any that no owner can explain.
Rotate what the identity could read: secrets in vaults, database passwords and API keys the identity had access to are now static credentials to handle with the Leaked Credential Response Playbook.
Protect the control plane: confirm the attacker did not gain rights to change trusts. Who can create federated credentials, OIDC providers or pool providers is the real blast radius.

Decision guidance

Situation	Choose	Trade-off
Attacker still controls the issuer (job, node, resource)	Disable the trust or provider now, then narrow it	Legitimate deployments stop until the trust is rebuilt
Issuer path is closed, tokens may still be live	Time-bound deny or permission removal, then wait out the residual window	Less disruption; containment completes only at expiry
Identity is shared by many workloads	Remove permissions on the targets the attacker touched, then split the identity	Slower, but avoids an outage across every workload
Small team, one cloud	Pre-write the three platform commands you need and test them once	Covers most cases without tooling
Large estate, several clouds and CI issuers	Automate trust inventory and a "disable trust" action in your SOAR, with owner approval logged	Build effort, but containment in minutes across platforms

Eradication and recovery

Rebuild trusts narrowly: one trust per workload, with exact subject matching (repository, branch or environment), the expected audience and, where the provider supports it, extra claim conditions such as repository owner ID or attribute conditions in CEL on Google Cloud pool providers. AWS IAM rejects a GitHub trust whose sub is only a wildcard; apply the same standard to every provider.
Replace shared identities: where several workloads shared one managed identity or service account, split them so a future compromise is contained to one workload. Microsoft notes that anyone who can run code on a resource effectively holds its managed identity.
Prefer direct assignments for fast revocation: Microsoft recommends granting permissions directly to a user-assigned managed identity rather than through a group when hours of caching delay are not acceptable.
Restore carefully: re-enable disabled providers only after the trust conditions are narrowed. Google Cloud keeps deleted pools and providers recoverable for 30 days, which also means a deleted name cannot be reused in that time.
Clean up orphans: role assignments are not deleted with the identity; remove assignments that now show as unknown principals.

Evidence to preserve

Evidence	Where	Why
Token exchange events	AWS CloudTrail `AssumeRoleWithWebIdentity`; Entra sign-in logs for service principals and managed identities; Google Cloud STS and IAM audit logs	Shows which external subject obtained which cloud identity, and when
Trust configuration history	Control-plane audit logs; infrastructure as code history	Proves whether trust was broad by design or modified by the attacker
Issuer-side job logs	CI run logs and OIDC claims for the jobs involved	Links cloud activity to a specific repository, branch and run
Workload attestation records	SPIRE server and agent logs; Kubernetes audit log	Shows which node or pod obtained the identity
Resource activity	Data plane logs on everything the identity could reach	Scopes data access for notification decisions

Export logs before retention expires and before changing the configuration you are investigating. Notification duties depend on what data the identity reached: see the Breach Notification Laws by Country Guide.

Detection and measurement

Alert on trust changes: creation or edit of OIDC providers, federated identity credentials, pool providers and SPIRE registration entries, routed to the identity owner within minutes.
Alert on unexpected subjects: web identity role assumptions whose subject is outside the expected set for that role.
Metrics (targets are ours): share of federated trusts with exact subject matching (target 100%); time from detection to issuer path cut (under 30 minutes); share of workload identities with a documented residual window and revocation step (100%); number of trusts with no named owner (zero); shared identities used by more than one workload (trending to zero).

Framework mapping

Framework	Reference	Where it applies
MITRE ATT&CK	T1078.004 Cloud Accounts; T1550.001 Application Access Token; T1552.005 Cloud Instance Metadata API; T1484.002 Trust Modification; T1098.001 Additional Cloud Credentials	Signals and persistence checks
NIST SP 800-53 Rev 5	IR-4 Incident Handling; AC-2 Account Management; AC-6 Least Privilege; IA-9 Service Identification and Authentication; SC-12 Cryptographic Key Establishment and Management	Response, trust scoping, SPIRE authority rotation
NIST CSF 2.0	RS.AN-03; RS.MI-01; RS.MI-02	Scoping, containment, eradication

Common failure patterns

Rotating nothing and declaring victory: teams look for a secret, find none, and close the incident while the trust still admits the attacker's subject.
Organisation-wide subject conditions: a trust that accepts any repository in an organisation turns one compromised repository into access to every role that trusts it.
Forgetting the cache: removing a managed identity from a group and assuming access ended, when cached tokens can carry the old membership for hours.
Missing the added trust: containing the known federated credential while a second one, added by the attacker, keeps working.
Deleting first: deleting the identity or pool destroys the link between audit events and configuration, and in some platforms blocks reuse of the name during recovery.
Ignoring downstream secrets: the identity is secretless, but the vault paths it could read are not.

Practitioner checklist

Inventory every federated trust, managed identity, pool provider and SPIRE registration entry, each with a named owner.
Record for each workload identity type the action that stops issuance, the action that neutralises issued tokens and the residual window.
Require exact subject and audience matching on all OIDC trusts; reject wildcard-only subjects.
Alert on creation or change of any trust relationship.
Pre-approve the containment actions (revoke role sessions, disable provider, delete FIC, evict agent) so responders can act without a change board.
Use one identity per workload and direct permission grants where fast revocation matters.
Exercise the playbook twice a year against a test identity on each platform, and roll back by restoring the trust from infrastructure as code.
Link this playbook to secret rotation for anything the identity could read.

Workload Identity Compromise Response Playbook: Revoking Federated Trust, SVIDs and Managed Identities