Cloud Workload Identity Buyer's Guide: Workload IAM

Most organisations already have workload identity features in every cloud they use, yet their workloads still authenticate with static keys, client secrets and long-lived tokens copied between clouds, pipelines and SaaS. The gap is rarely a missing product; it is federation that stops at one cloud boundary, policy that nobody can read across platforms, and no record of which workload holds which credential. This vendor-neutral guide helps platform, cloud security and identity teams decide whether they need a dedicated workload identity platform at all, write requirements and an RFP, compare options on evidence, understand pricing models and run a proof of concept. It assumes you know the mechanics; for how workload identities work on each cloud see the Cloud Workload Identity Guide, and for the token exchange itself see the Workload Identity Federation Guide.

Key takeaways

Start from what the clouds already give you. Managed identities, IAM roles and federation are included in AWS, Azure and Google Cloud; buy a workload identity platform only for the gaps they leave, usually cross-cloud, on-premises, SaaS targets and central policy.
Secretless is the test, not the slogan. A credible platform removes the bootstrap secret by relying on platform attestation or federated tokens, and issues credentials that live minutes, not months.
Attestation decides how much the identity is worth. Ask exactly which properties of the node and the process are verified before an identity is issued, and what an attacker on the same host could obtain.
Policy must be readable across platforms. Workload IAM fails when every cloud has its own trust policy syntax and nobody can answer "which workloads can reach this database" in one place.
Discovery and posture are a separate purchase decision. Issuing new identities does not find the thousands of existing keys; decide whether you also need inventory, ownership and posture, or whether an NHI security platform covers it.

Define requirements

Choosing a workload identity platform starts with these decisions, written down before the first vendor meeting. They separate the problems a cloud already solves from the ones that justify new spend.

Estate and trust domains: list every place workloads run (each cloud account, subscription and project, Kubernetes clusters, virtual machines on premises, CI/CD runners, serverless) and every target they call (cloud APIs, databases, internal services, SaaS APIs). Draw the trust domains. The IETF WIMSE architecture draft defines a trust domain as "a logical grouping of systems that share a common set of security controls and policies", which is a useful way to decide where federation boundaries sit.
Credential baseline: count the long-lived credentials in use today: cloud access keys, service account key files, app registration client secrets and certificates, database passwords, SaaS API keys and CI tokens. This is the number the purchase should reduce. OWASP lists NHI7:2025 Long-Lived Secrets and NHI2:2025 Secret Leakage among its Non-Human Identities Top 10.
Native coverage first: confirm what each provider already supports. Google Cloud Workload Identity Federation accepts AWS, Azure, OIDC and SAML 2.0 identities and X.509 client certificates, and Google states it "eliminates the maintenance and security burden associated with service account keys". Microsoft Entra workload identity federation lets a user-assigned managed identity or app registration trust tokens from an external identity provider such as GitHub or Google. AWS IAM Roles Anywhere exchanges X.509 certificates from your CA for temporary credentials, and AWS "strongly" recommends against storing long-term credentials in applications outside AWS.
Gaps that justify a platform: typical ones are cross-cloud calls without hand-built trust in each direction, on-premises workloads without a usable PKI, SaaS and database targets that only accept static secrets, consistent policy and audit across clouds, and a single inventory of workload identities and their owners.
Architecture constraints: whether issuance must run inside your boundary (self-hosted control plane or agents) or may be a hosted service, availability targets for the issuer (an outage stops every workload that needs a fresh credential), data residency for audit logs, and regulated environments that cannot depend on an external control plane.
Ownership: who runs the platform (platform engineering, identity or cloud security), who approves new trust relationships, and who owns each workload identity. OWASP NHI1:2025 Improper Offboarding is usually an ownership failure, not a tooling one.

Size changes the answer. A small organisation on one cloud with one CI system should use native managed identities and federation, remove static keys, and add a secrets manager for targets that cannot federate; a separate platform is rarely justified. A large enterprise with several clouds, many clusters, on-premises estates and hundreds of teams needs consistent attestation, policy and audit across trust domains, and that is where workload identity vendors earn their place.

Capability areas and evaluation criteria

Products marketed as workload identity tools come from different starting points. A meaningful workload identity platform comparison puts like with like, so decide which of these categories you are evaluating.

Category	What it does	Strengths	Limits
Cloud-native workload identity	Managed identities, IAM roles, instance and pod identity, service accounts, inbound federation	Included in the cloud, no extra control plane, deep service integration	One provider's syntax and logs each; cross-cloud trust is built by hand per pair
SPIFFE-based identity issuance	Attests nodes and processes, issues short-lived X.509 or JWT SVIDs through a local Workload API, federates trust bundles	Open standard, platform-neutral, strong attestation model, works on premises	Self-run issuance is an always-on tier-zero service; targets must accept SVIDs or a token exchange
Workload IAM or access broker platform	Central policy that decides which workload may reach which target, then issues or brokers a short-lived credential, often federating into each cloud	One policy and audit view across clouds and SaaS, can front secrets-only targets	Another control plane in the access path; depth varies by target
Service mesh identity	Mutual TLS between services with SPIFFE-style identities and service-to-service authorisation	Encryption and service authentication without code change	Inside the mesh only; does not cover cloud API or SaaS access
Secrets manager with platform authentication	Authenticates workloads by platform identity and returns dynamic or rotated secrets	Covers databases and legacy targets that cannot federate	Still a secret at the point of use; see the Secrets Management Buyer's Guide
NHI security and posture platform	Discovers workload identities and credentials across clouds and tools, maps owners, flags risky posture	Finds what already exists, including static keys	Does not issue identities; see the NHI Security Platform Buyer's Guide

NIST SP 800-207A sets a useful bar for any of them: "Each service should present a short-lived cryptographically verifiable identity credential" (ID-SEG-REC-2), and authorisation between services should use runtime service identity (ID-SEG-REC-3). It also separates identity-tier policies, based on service and user identities, from network-tier policies, and expects the identity tier to be dynamic.

Weight the criteria to your requirements. An illustrative split for a multi-cloud estate: 25% federation coverage and secretless access, 20% attestation, 20% policy, 15% lifecycle, discovery and posture, 10% audit and detection, 10% resilience and commercial terms.

Criterion	What good looks like	Weak signs
Federation coverage	Native, documented flows into AWS (OIDC federation and IAM Roles Anywhere), Azure (federated identity credentials on managed identities or app registrations) and Google Cloud (workload identity pools and providers), plus Kubernetes, your CI/CD systems and your SaaS and database targets	"Supports any cloud" through stored access keys; SaaS coverage that means vaulting the API key
Secretless access	No bootstrap secret on the workload; identity comes from platform attestation or a projected, audience-bound token; credentials expire in minutes	An agent that needs an install token or API key on every host, which simply moves "secret zero"
Attestation	Node attestation from the platform (cloud instance identity documents, Kubernetes node and service account tokens, TPM where needed) plus workload attestation by selectors such as namespace, service account, image digest or Unix user	Identity issued on hostname, IP address or a label any deployer can set
Policy	Human-readable policy linking workload identity to target and action, version-controlled, testable before enforcement, evaluated with context such as environment and image provenance	Policy only as per-cloud trust documents generated by the tool and not readable outside it
Claim scoping	Trust bound to exact issuer, subject and audience; Google attribute conditions and Microsoft issuer, subject and audience matching set narrowly by default	Trust granted to a whole identity pool, organisation or repository wildcard
Lifecycle	Identities created and removed with the workload, owner recorded, unused trust relationships expired, credential lifetime configurable per target	Identities outlive the deployment; manual clean-up
Discovery and posture	Inventory of existing service accounts, keys, client secrets, federated credentials and role trust policies across clouds, with last use and owner	Sees only identities it issued itself
Audit and detection	Every issuance and exchange logged with workload, attestation evidence, target and decision; export to your log platform; alerts on unexpected issuers, subjects or targets	Logs only denials, or summary dashboards without raw events
Resilience	Documented behaviour when the issuer is unavailable (cached credentials, regional failover), credential lifetimes that survive short outages, tested disaster recovery	Single region control plane in the critical path of every call

Attestation and standards to probe

SPIFFE gives the vocabulary for comparing workload identity security vendors even when a product is not built on it. A SPIFFE ID is "a structured string (represented as a URI)"; an SVID "carries the SPIFFE ID itself" as an X.509 certificate, JWT or, in the current specification, a WIT token; and the Workload API lets a process obtain its SVID without a secret, because it "does not require that a calling workload have any knowledge of its own identity". In SPIRE, node attestation means each agent must "authenticate and verify itself when it first connects to a server", and workload attestation answers "Who is this process?" using selectors such as Unix user ID or the Kubernetes service account and namespace. Ask vendors to map their own model to these steps. See the Guide to SPIFFE and SPIRE.

The IETF Workload Identity in Multi-Service Environments (WIMSE) working group is standardising workload credentials across call chains and token exchange between SPIFFE-identified services and OAuth-protected resources. Its documents are Internet-Drafts (the architecture is draft-ietf-wimse-arch-08, July 2026), so treat vendor claims of "WIMSE compliance" as claims of alignment with drafts that may change.

Pricing models

Workload identity pricing is rarely published, and the unit counted changes total cost more than the list price. Ask for a three-year cost at today's estate and at double the workload count, because containerised estates grow quickly.

Model	What is counted	Watch for
Per workload or identity	Distinct workload identities, services or SPIFFE IDs	Whether each pod replica, job run or short-lived function counts separately
Per node, cluster or environment	Hosts running an agent, clusters or cloud accounts connected	Cost growth with autoscaling; charges for non-production
Per issuance or exchange volume	Credentials issued or token exchanges	Pressure to lengthen credential lifetimes to save money
Per target or connector	Clouds, databases and SaaS services protected	Core targets sold as premium connectors
Open source plus subscription	Support, hardened builds or a managed control plane for an open project	Your own operational cost of an always-on issuer

Native cloud features cost nothing extra, so price any platform against the engineering time of building and maintaining the same federation and policy by hand.

Where identity risk concentrates

The platform itself becomes a tier-zero non-human identity. It holds federation trust into every cloud, so a compromised issuer or admin account can mint access everywhere. Require separate administration from production workloads, phishing-resistant authentication for its administrators, change approval for new trust relationships, and signing keys in hardware or cloud key management. Map the main threats to controls when scoring:

Threat	Reference	What the platform should do
Stolen static workload credentials	ATT&CK T1552 Unsecured Credentials; OWASP NHI2:2025, NHI7:2025	Replace keys with short-lived federated credentials; report remaining keys
Abuse of cloud accounts and service principals	ATT&CK T1078.004 Valid Accounts: Cloud Accounts	Alert on use from unexpected networks, issuers or targets; per-workload identities
Token theft from a workload	ATT&CK T1528 Steal Application Access Token	Short lifetimes, audience binding, sender-constrained credentials where targets support them
Shared identities across workloads or environments	OWASP NHI9:2025 NHI Reuse, NHI8:2025 Environment Isolation	One identity per workload per environment; separate pools or trust domains per environment
Overprivileged workloads	OWASP NHI5:2025 Overprivileged NHI; NIST SP 800-53 AC-6	Least-privilege policy per target, unused-permission reporting
Weak service authentication	OWASP NHI4:2025 Insecure Authentication; NIST SP 800-53 IA-9; SP 800-207A ID-SEG-REC-2	Cryptographically verifiable, attested credentials; mutual TLS between services

For governance, the purchase supports NIST CSF 2.0 PR.AA (Identity Management, Authentication, and Access Control), NIST SP 800-53 IA-5 Authenticator Management and IA-9 Service Identification and Authentication, and ISO/IEC 27001:2022 Annex A 5.16 Identity management, 5.17 Authentication information and 8.5 Secure authentication.

Questions to ask vendors

Use these as the core of a workload identity RFP. Ask every shortlisted vendor the same set in writing, and have them demonstrate answers in the proof of concept rather than on a demo tenant.

For each of our clouds, which native federation mechanism do you use (AWS OIDC federation or IAM Roles Anywhere, Entra federated identity credentials, Google workload identity pools), and does any path store a long-lived key?
What does a workload need on day one to obtain its first credential? If the answer includes an install token, how is that token scoped, rotated and protected?
Exactly which node and workload attestation evidence do you verify, and which selectors can a developer with deploy rights set or forge?
How do you bind issuer, subject and audience, and can you show a trust relationship scoped to one repository branch, one Kubernetes namespace and service account, or one image digest?
Where is policy written, how is it tested before enforcement, and can we see a dry-run or audit mode that logs decisions without blocking?
Which SaaS and database targets do you reach without a static secret, and for the rest, how are secrets rotated and who can read them?
Do you discover workload identities and keys you did not issue, including service account key files, client secrets and role trust policies, with last-use data?
Do you support SPIFFE IDs and SVIDs natively, federate trust bundles, and track the IETF WIMSE drafts? Which parts are generally available today?
What happens to running workloads if your control plane is unreachable for one hour, and what credential lifetime do you recommend to survive that?
How are your own signing keys and federation trust protected, who at your company can access them, and how would you notify us of compromise?
What exactly counts toward the licence, and what does doubling our workload count cost?

Red flags

"Secretless" access that depends on a static API key or join token on every node, or on vaulting the same long-lived cloud keys you wanted to remove.
Attestation based on IP address, hostname or freely settable labels, so any deployer or any process on a shared node can claim another workload's identity.
Federation templates that trust a whole identity pool, cloud account, CI organisation or wildcard subject by default. Google warns that granting access to all identities in a pool "can incur risk".
No answer on instance metadata. Workload credentials reachable from the metadata service are what attackers took in the Capital One breach; on EKS, AWS notes that if IMDS is not restricted, containers may reach the node role and other pods' credentials.
Inventory limited to identities the product issued, leaving existing keys and pipeline secrets invisible. CI secrets were the prize in the tj-actions/changed-files compromise.
A single-region control plane in the path of every credential request, with no documented failure behaviour.
Pricing per credential issued, which rewards long credential lifetimes.

Proof of concept

Pick two real paths and define success: for example a CI pipeline deploying to two clouds, and a Kubernetes service calling a database and a SaaS API. Success means no static credential on either path, credentials under one hour, and a policy decision logged for every call.
Baseline: record the static keys, client secrets and tokens those paths use today, their age and who can read them. Use cloud key reports and secret scanning to count them.
Install with least privilege: give the platform only the cloud permissions it needs to create federation trust, in a sandbox account or subscription first. Log every permission requested and every change it makes.
Test attestation adversarially: deploy a second workload in the same namespace and on the same node, change its labels and service account, and try to obtain the first workload's identity. Then try from a host outside the trust domain. Record what is issued.
Run policy in audit mode, then enforce: write least-privilege policy, run it in dry-run for a week of real traffic, review would-be denials, then enforce and confirm the workload still runs.
Test revocation and outage: remove a workload's policy and measure time until access stops; block the control plane and observe behaviour until credentials expire.
Check discovery: plant a test service account key and a test client secret, both disabled, and confirm the platform finds them with owner and last use.
Roll back cleanly: restore the original credentials from a sealed backup (disabled, not deleted, during the trial), remove federation trust and roles the platform created, confirm in each cloud's audit log that its access has stopped, and get written confirmation that trial data is deleted.

Roll out in rings after purchase: CI/CD pipelines first (high value and easy to federate), then new Kubernetes services, then existing services by risk, leaving legacy targets on dynamic secrets until they can federate. Disable each replaced key for 30 days before deleting it, so rollback is a re-enable rather than a re-issue. Measure progress with: the number of long-lived workload credentials (falling each month), the share of workloads using federated or attested identity, median credential lifetime, the share of workload identities with a named owner, time to revoke a workload's access, and alerts on token exchanges from unexpected issuers or subjects. NHI ownership and lifecycle practice is covered in the NHI Ownership Guide.

Standards and references

How NHI Mgmt Group can help

We provide independent requirements, RFP and evaluation support. Browse vendors in our products directory or contact us.

Cloud Workload Identity Buyer’s Guide