Workload Identity Platform Rollout Playbook

Most workload identity programmes stall halfway, leaving a new issuer running beside the old static keys, so the organisation carries the risk of both and the benefit of neither. A workload identity platform issues short-lived, attested credentials to services, pipelines and agents (the issuer) and exchanges credentials from other trust domains for local access (the federation broker). Its rollout is hard to reverse because trust domain names, identifier schemes and federation trusts end up embedded in authorisation policies everywhere. This vendor-neutral playbook sets out the order of work: the decisions to make before the first credential is issued, how to pilot, how to move workloads in rings, how to retire static secrets, how to roll back and how to prove the platform is working. It is written for platform, identity and cloud security engineers. How the standards work is covered in the SPIFFE and SPIRE Guide and the Workload Identity Federation Guide, and hardening the running platform is covered in Securing the workload identity platform (workload identity issuer and federation broker) itself; this page is about sequencing the rollout.

Key takeaways

Fix the naming before anything else. Trust domain names and identifier paths are written into every authorisation policy that consumes them, so agree the scheme, get it approved and treat later changes as a migration.
Build the issuer as tier 0 from day one. Signing keys in a hardware or cloud key store, a separately held root, two-person approval for registration and federation changes, and logs leaving the platform before the first production workload is onboarded.
Attestation decides who gets an identity. Prefer evidence rooted in the platform (the node, cluster or job runner) over bootstrap secrets, and make join tokens a counted exception.
Federation is a trust decision, not plumbing. Every external issuer accepted by the broker needs exact issuer, subject and audience conditions, an owner and a review date.
The rollout ends when the static secret is gone. Measure progress by revoked keys and passwords, not by credentials issued, and keep a rehearsed rollback path for each ring until then.

Before you start: decisions that are hard to change later

Write a short design record covering the decisions below and get it approved by platform, security and application owners. Every later phase is checked against it. The WIMSE Workload Identity Architecture Guide explains the architecture vocabulary; the IETF WIMSE architecture draft (draft-ietf-wimse-arch-08, an Internet-Draft last updated July 2026 and still subject to change) uses the same concepts of trust domains, credential issuance and token exchange.

Decision	Options	What to consider
Trust domain boundaries	One trust domain for the organisation; one per environment (production, non-production); one per business unit or regulatory boundary	The SPIFFE Trust Domain and Bundle specification strongly advises that each signing key serve a single trust domain, because key reuse degrades isolation such as between staging and production. Separate production from everything else at minimum.
Trust domain name	A domain name the organisation controls; an internal label	WIMSE says the identifier should be a fully qualified domain name of the defining organisation. The SPIFFE ID specification requires a lowercase host part using only letters, digits, dots, dashes and underscores. Use a name you own so it never collides with a partner's.
Identifier path scheme	By service; by namespace and service account; by team and service; by environment and service	Paths are what authorisation policies match on. Choose attributes that are stable for the workload's life. Avoid volatile data such as host names or build numbers: the SPIFFE ID specification warns that an assertion stays valid for the whole credential lifetime.
Credential types	X.509 certificates for mutual TLS; signed JWTs for proxied or HTTP paths; both	X.509 credentials are key-bound and suit service-to-service mutual TLS. JWT credentials are bearer tokens and must carry a single audience and a short expiry. See mTLS vs Signed Tokens for Service Authentication.
Key hierarchy	Issuer signs with its own key under an offline root; issuer chains to an existing internal CA; managed cloud issuer	Chaining to the existing PKI simplifies trust distribution but makes the internal CA part of the platform's blast radius. See the Enterprise PKI Design and CA Hierarchy Guide.
Federation model	Broker per cloud; one central broker; direct trust between issuers	A central broker gives one policy and audit point; per-cloud brokers reduce cross-cloud dependencies. Either way, count each external issuer as a privileged trust.
Self-hosted or managed	Self-hosted issuer; managed cloud identity federation; hybrid	Most estates end up hybrid. See SPIFFE vs Cloud-Native Workload Identity and the Workload Identity Standards Compared guide.

Small versus large organisations: a small team on one cloud usually starts with the provider's managed workload identity and federation for CI, adding a self-hosted issuer only when workloads span clouds or data centres. A large or multi-cloud estate needs a production trust domain with its own keys, a central federation policy repository, and a named platform team on call for the issuer, because an issuer outage stops every workload from renewing.

The rollout at a glance

Phase	Main outputs	Exit criteria
0. Discover and design	Inventory of static workload credentials, design record, identifier scheme, role model	Design approved; every static credential in scope has an owner and a target replacement
1. Foundations	Issuer in production trust domain, key store, admin roles, change workflow, log export, break-glass	A registration change cannot be applied by one person; admin and issuance events reach the SIEM
2. Pilot	Two or three non-production services and one CI pipeline on platform identity	Renewal, rotation, issuer outage and revocation tests passed; latency within budget
3. Production ring 1	Internal service-to-service traffic for low-risk services	No unplanned outages for an agreed period; rollback rehearsed
4. Production ring 2	Federation with clouds, partners and CI; regulated workloads	Every external trust has exact conditions and an owner; static cloud keys for migrated workloads revoked
5. Enforce and operate	Guardrails blocking new static credentials, review cadence, metrics	New workloads cannot be deployed with static secrets; quarterly trust review completed

Phase 0: discover and design

Inventory what the platform will replace. List service account keys, cloud access keys, database passwords, API keys and long-lived certificates used by workloads, with owner, consumer, age and where each is stored. Reconcile against secrets managers, CI variables and code scanning results; see NHI Inventory Reconciliation.
Map relying parties. For each credential, record what validates it: a database, a cloud API, an internal service, a partner. A relying party that cannot accept certificates or tokens from the new issuer needs a broker step or stays on secrets for now, which must be recorded.
Choose attestation per runtime. For each runtime (virtual machines, container clusters, serverless functions, CI runners, on-premises hosts), decide what evidence proves where a workload runs. RFC 9334 (RATS Architecture, Informational) gives the vocabulary: the workload or node is the attester, the issuer acts as verifier and applies an appraisal policy, and the services consuming the credential are relying parties. See the Workload Attestation Guide.
Define roles. Platform administrator, registration author, trust approver, key custodian and auditor, each mapped to a group or pipeline identity. No role both authors and approves registration or federation changes.
Set credential lifetimes. WIMSE recommends bounded lifetimes with automated renewal, set by workload sensitivity, key protection and instance lifetime. The SPIFFE JWT-SVID specification encourages the smallest reasonable expiry. Record your chosen values per credential type, and check your issuer's documented defaults rather than assuming them.

Phase 1: foundations before the first production credential

Signing keys: keep intermediate signing keys in an HSM or cloud KMS with sign-only permission, chained to a root held offline or in a separate account with its own custodians. Generate production keys only after the key ceremony is documented.
Registration as code: registration entries and issuance rules live in a version-controlled repository; changes go through pull requests reviewed by a trust approver and are applied by the platform's own pipeline identity, never by hand in a console.
Federation as code: the same pattern for external issuers: issuer URL, accepted subjects, audience and mapped local identity, each with an owner and review date. The Workload Identity Federation Trust Review Checklist gives the review questions.
Trust bundle distribution: set the bundle refresh hint deliberately. The SPIFFE Federation specification recommends publishing new keys 3 to 5 times the refresh hint before use and requires publication before a key signs anything; where no hint is set, the Trust Domain and Bundle specification suggests clients default to a low interval such as five minutes.
Logging: export admin API calls, registration and trust changes, credential issuance, attestation failures and key events to a store that issuer administrators cannot alter. Keep bearer tokens out of logs: the WIMSE draft notes that logs can leak them.
Availability: run the issuer in a highly available configuration, back up its datastore, and test a restore before production. Credentials must comfortably outlive a plausible issuer outage, or renewals will fail across the estate.
Break-glass: a sealed path to administer the issuer if its own admin identity fails, that does not depend on credentials the issuer mints. See the Break-Glass Account Guide.

Phase 2: pilot

Pick representative non-production workloads: two services that call each other, one service that calls a cloud API through the broker, and one CI pipeline that deploys with a federated token instead of a stored key. Run each test below and record the result in the design record.

Issue credentials through attestation only and confirm the identity, attestation evidence and registration entry appear in the issuance log.
Start a workload on a host or namespace that does not match any entry and confirm it receives no credential and the failure is logged.
Present a JWT credential to a service that is not its audience and confirm rejection; the JWT-SVID specification requires validators to reject tokens whose audience does not include them.
Rotate the intermediate signing key on schedule and confirm relying parties keep validating, then measure how long the new bundle takes to reach the slowest consumer.
Stop the issuer for longer than one renewal interval and record what fails and when; restore and confirm recovery without manual steps.
Remove a registration entry and confirm the workload stops receiving new credentials, then measure how long existing credentials stay valid.
Exchange the CI pipeline's token at the broker and confirm the resulting access is limited to the intended branch, environment and role; see How to Scope CI OIDC Trust to Branch and Environment.

Rollback for the pilot: keep the static credential valid but unused until all tests pass, and switch back with one configuration change. Do not revoke anything in this phase.

Phases 3 and 4: production rings

Ring 1, internal services: move low-risk service-to-service traffic first, one service pair per change, with the consuming service accepting both the old secret and the new credential during a dual-run window. Watch authentication failures and renewal errors for an agreed period (NHI Mgmt Group suggests at least two weeks) before revoking the old secret.
Ring 2, federation: replace stored cloud keys and partner credentials with broker exchanges. RFC 8693 (OAuth 2.0 Token Exchange, Standards Track) defines the grant type urn:ietf:params:oauth:grant-type:token-exchange with subject_token, optional actor_token, and audience or resource to restrict the target. Require client authentication at the broker and request one target per exchange; the RFC notes that delegation keeps the actor's identity visible while impersonation does not, so prefer delegation where the relying party supports it.
Regulated workloads: onboard last, with evidence of the attestation policy, registration approval and log retention ready for audit.
Revoke as you go: each migrated workload's static credential is revoked and deleted within an agreed window, and the inventory updated. A migrated workload that still holds a working key has not been migrated. See Workload Identity Federation vs Static Cloud Keys.
Rollback: until revocation, rollback is reverting the client configuration. After revocation it means issuing a new static credential through the secrets manager's normal approval path, which should be documented, slow by design, and alerted.

Container platforms have their own steps; the Kubernetes Workload Identity Checklist covers them. Where a service mesh consumes the issuer's certificates, sequence the mesh rollout with this one using the Service mesh rollout playbook.

Where identity fits

The platform is itself a set of non-human identities: the issuer's identity to its key store, its datastore account, the pipeline identity that applies registration changes, node join tokens and the broker's client credentials. Each one is a route to issuing any identity in the trust domain. Record them in the NHI inventory with owners and expiry, scope them narrowly, and alert on any use outside the platform's hosts. Admin rights granted to a workload identity must not be something the issuer can mint for itself without approval. Hardening detail for each is in Securing the workload identity platform (workload identity issuer and federation broker) itself.

Detection and measurement

Signal	Why it matters	Response
Registration entry created or changed outside the pipeline	Someone can map a rogue workload to a trusted identity	Revert from the repository; investigate the identity that made the change
New or changed federation trust	An external issuer can now obtain local access (ATT&CK T1484.002 Trust Modification)	Confirm a matching approved change; remove if not
Spike in attestation failures	Misconfiguration after a platform upgrade, or attempts to obtain credentials from unregistered hosts	Correlate with change records; isolate unexpected nodes
Issuance for an identity from an unusual node or region	Possible rogue node enrolment	Evict the node and revoke its credentials
Static credential used by a workload marked migrated	The old path is still live and still stealable (T1552.001 Credentials In Files)	Revoke the credential; find the consumer
Signing key events not matching the rotation calendar	Possible key misuse or forged certificates (T1649)	Treat as incident; follow the Workload Identity Compromise Response Playbook

Metrics that show the rollout is working:

Percentage of in-scope workloads authenticating with platform-issued credentials, and the count of static workload credentials revoked against the Phase 0 baseline.
Percentage of registration entries and federation trusts with an owner and a review in the last 90 days.
Percentage of credentials issued through platform-rooted attestation rather than join tokens.
Bundle propagation time to the slowest relying party after a rotation, measured at each scheduled rotation.
Number of renewal failures per week, and the longest issuer outage the estate has survived in testing.

Common failure patterns

Running both worlds indefinitely: workloads get new credentials but the old keys are never revoked, so the attack surface grows. Tie each ring's exit to revocation, not issuance.
Broad federation conditions: trusting every subject from a CI issuer or an entire partner trust domain lets any pipeline or tenant assume the mapped role. Pin issuer, subject and audience exactly.
Volatile identifiers: putting host names or build numbers in identity paths breaks authorisation policies on every redeploy, and teams respond by writing wildcard policies.
Shared keys across trust domains: one signing key for production and non-production means a compromise in the weaker environment produces credentials the stronger one accepts.
Retired keys left in trust: relying parties keep accepting keys that should have been removed, or accept a key outside the scope it was meant for. The Microsoft Storm-0558 Key Breach shows the lesson: a signing key that should have been retired stayed valid, and token validation did not check the key's scope. Remove retired keys from bundles and validate issuer and trust domain on every token.
No outage plan: credential lifetimes shorter than the issuer's realistic recovery time turn a platform incident into an estate-wide outage.

Framework mapping

Rollout element	NIST SP 800-53 Rev. 5	NIST CSF 2.0	Other
Workload authentication with issued credentials	IA-9 Service Identification and Authentication; IA-5	PR.AA-01, PR.AA-03	NIST SP 800-207A application identity infrastructure
Node and runtime attestation	IA-3 Device Identification and Authentication	PR.AA-03	RFC 9334 RATS Architecture
Signing keys and certificates	SC-12, SC-17	PR.DS-01	SPIFFE X.509-SVID and Trust Domain and Bundle specifications
Registration and federation change control	CM-3, AC-5	PR.AA-05	SPIFFE Federation specification
Least privilege for issued identities	AC-6	PR.AA-05	RFC 8693 audience and resource restriction
Platform logging and monitoring	AU-2, AU-9, SI-4	PR.PS-04, DE.CM-03	WIMSE architecture draft security considerations

Practitioner checklist

Approve a design record covering trust domains, naming, identifier paths, credential types, key hierarchy and federation model.
Inventory every static workload credential in scope with owner, consumer and target replacement.
Choose platform-rooted attestation per runtime and count join tokens as exceptions with expiry.
Put signing keys in an HSM or KMS with sign-only permission under a separately held root, one key set per trust domain.
Manage registration entries and federation trusts as code with two-person review and pipeline-only apply.
Set the bundle refresh hint, publish new keys well ahead of use, and measure propagation to the slowest relying party.
Export admin, issuance, attestation and trust events to a store issuer admins cannot change, without bearer tokens.
Pilot denial, audience, rotation, outage and revocation tests before production.
Revoke each migrated workload's static credential within an agreed window and update the inventory.
Block new static workload credentials once ring 2 completes, and review federation trusts quarterly.

Workload identity platform (workload identity issuer and federation broker) rollout playbook: phased implementation with security built in