Every bidder for a workload identity platform will say it issues short-lived credentials and supports federation, so an RFP that asks only those questions cannot tell an issuer you could run as tier 0 from one that hands out broad, long-lived tokens through a loosely configured trust. This template is a ready-to-issue request for proposal for a platform that issues identities to workloads (X.509 certificates or signed tokens, based on attestation) and brokers federation and token exchange with cloud providers, CI systems and partner trust domains. Every requirement is numbered, typed and written so it can be verified in a demonstration or proof of concept. It is vendor-neutral and draws on the SPIFFE specifications, the IETF WIMSE architecture draft and OAuth 2.0 Token Exchange (RFC 8693). For market context and evaluation themes read the Cloud Workload Identity Buyer's Guide first; for hardening the platform once bought, see Securing the workload identity platform (workload identity issuer and federation broker) itself.
How to use this template
- Replace text in square brackets, such as [Organisation], [platforms] and [number], with your own details. Delete requirements that do not apply.
- Each requirement has an ID (for example WIP-ISS-02) and a type: M mandatory (pass or fail, a single fail excludes the bid), S scored (0 to 5, weighted) or I informational (not scored, used for planning).
- Weights, lifetimes, volumes and timings in brackets are illustrative, not benchmarks. Set them from your own risk and scale before issue and do not change them after responses arrive.
- Issue sections 1 to 8 to bidders. The Implementation guidance section is for your panel only.
- If you are also buying an NHI security platform, secrets management or certificate lifecycle management, align IDs with the NHI Security Platform RFP Template, the Secrets Management RFP Template and the Certificate Lifecycle Management RFP Template so that overlapping capability is scored once and its owner is decided.
1. Purpose and scope
[Organisation] invites proposals for a workload identity platform and implementation services. The platform must issue verifiable, short-lived identities to workloads based on attestation, let those workloads authenticate to each other and to cloud and SaaS services without static secrets, and broker trust with external issuers under policy that [Organisation] controls and can audit.
- Workloads in scope: containers and pods in [number] Kubernetes clusters; virtual machines in [cloud providers and data centres]; serverless functions; CI/CD jobs on [CI platforms]; batch and legacy services on [operating systems]; AI agents and MCP servers running in [platforms].
- Relying parties in scope: internal services (mutual TLS and token validation), [cloud provider] IAM through federation, [databases, message queues, secrets managers], [SaaS APIs], and [partner trust domains].
- Out of scope: [workforce SSO]; [customer identity]; [public TLS certificates for websites, if covered by certificate lifecycle management].
- Drivers: [static cloud keys and service account keys in pipelines]; [audit findings on long-lived secrets]; [multi-cloud service authentication]; [zero trust programme milestones]; [AI agent adoption].
- Contract term: [three] years with an option to extend by [two] years.
2. Organisation background and current state
| Item | [Organisation] value |
|---|---|
| Compute estate | [number] clusters; [number] virtual machines; [number] serverless functions; regions [list] |
| Cloud providers and accounts | [providers]; [number] accounts, subscriptions or projects |
| CI/CD | [platforms]; [number] pipelines that deploy to production |
| Current service authentication | [static keys, service account key files, shared secrets, internal CA certificates, service mesh identities] |
| Existing PKI | [internal CA, HSM or cloud KMS in use, offline root] |
| Expected issuance volume | [number] workloads; peak [number] credential issuances per minute |
| Federation partners | [internal trust domains, partner organisations, SaaS providers] |
| Hosting constraints | [self-hosted required, managed service acceptable, air-gapped sites, data residency] |
| Tooling to integrate | [SIEM, NHI inventory, secrets manager, policy engine, ticketing] |
3. Instructions to bidders
- Timeline: RFP issued [date]; clarification questions by [date]; responses due [date, time, time zone]; demonstrations [dates]; proof of concept [dates]; decision [date].
- Single point of contact: [name, email]. Contact with other [Organisation] staff about this RFP may lead to disqualification.
- Response scale: for each requirement state one of: available now; available with configuration; custom development; third-party product required (name it); roadmap (committed date); not supported. Roadmap answers score zero unless the date is written into the contract.
- Standards evidence: for each standard claimed (SPIFFE X.509-SVID, JWT-SVID, Federation; OAuth 2.0 Token Exchange; WIMSE drafts), state the specification version implemented and link the product documentation. Draft standards must be identified as drafts with the version.
- Architecture: include a diagram of every component, where signing keys live, what each agent or sidecar runs as, every network path, and the trust boundaries between control plane and data plane.
- Demonstration script: shortlisted bidders run the scenarios in section 8 live, on their own test environment, before the proof of concept.
4. Functional requirements
4.1 Identity issuance and credential formats
| ID | Requirement | Type |
|---|---|---|
| WIP-ISS-01 | Issues X.509 credentials for mutual TLS and signed JWT credentials for token-based authentication, each bound to a workload identifier in a URI form under a trust domain [Organisation] names. | M |
| WIP-ISS-02 | Credential lifetimes are configurable per identity or path, with a default of [one hour or less] and automatic renewal before expiry without workload restart. | M |
| WIP-ISS-03 | JWT credentials always carry an expiry and an audience; the platform supports and defaults to single-audience tokens. The SPIFFE JWT-SVID specification strongly recommends single audiences because a multi-audience token can be replayed by one recipient against another. | M |
| WIP-ISS-04 | Restricts JWT signing algorithms to an allow list (for example RS256, ES256, PS256 families) and documents how validators reject other values. | M |
| WIP-ISS-05 | Supports proof-of-possession credentials (key-bound tokens or mutual TLS) and states where bearer tokens are still used. The WIMSE architecture draft allows bearer tokens only for legacy interoperability. | S |
| WIP-ISS-06 | Delivers credentials to workloads through a local API or socket without writing private keys to shared disk, and rotates them in place. | S |
See the SPIFFE and SPIRE Guide and mTLS vs Signed Tokens for Service Authentication.
4.2 Attestation and registration
| ID | Requirement | Type |
|---|---|---|
| WIP-ATT-01 | Attests nodes and workloads from platform evidence (cloud instance identity documents, Kubernetes service account and pod properties, TPM evidence, CI job claims) for every platform in section 2; list the attestors per platform. | M |
| WIP-ATT-02 | Bootstrap or join tokens, where needed, are single use, short lived and logged; state which platforms still need them. | M |
| WIP-ATT-03 | Registration entries map exact attested properties to identities; describe how wildcard or overly broad selectors are detected or blocked. | S |
| WIP-ATT-04 | Registration can be delegated to teams within a namespace or path they own, through API or configuration as code, with approval workflow and history. | S |
| WIP-ATT-05 | Each registration entry records an owner, a business service and a review date, exportable to [NHI inventory]. | S |
See the Workload Attestation Guide.
4.3 Federation broker and token exchange
| ID | Requirement | Type |
|---|---|---|
| WIP-FED-01 | Federates with other trust domains by fetching their trust bundles from configured endpoints. Each federation relationship requires the trust domain name, endpoint URL and endpoint profile to be configured explicitly, as the SPIFFE Federation specification requires. | M |
| WIP-FED-02 | Never merges bundles from different trust domains, and validates each credential only against the bundle of its own trust domain. | M |
| WIP-FED-03 | Accepts external tokens (cloud, CI, partner IdP) only under explicit issuer, subject and audience conditions; describe how prefix or wildcard subject conditions are flagged. | M |
| WIP-FED-04 | Acts as a token exchange service per RFC 8693: exchanges a workload credential for a scoped, short-lived token for a target audience, requires client authentication for exchange requests, and distinguishes delegation (with an act claim) from impersonation. | S |
| WIP-FED-05 | Issues credentials accepted by [cloud providers] workload federation so workloads can reach cloud APIs without static keys; list supported targets and how trust is configured on each. | M |
| WIP-FED-06 | Treats bundle endpoint redirects as temporary and keeps using the configured URL, as the SPIFFE Federation specification recommends. | I |
See the Workload Identity Federation Guide, the OAuth Token Exchange and Delegation Guide and the Workload Identity Federation Trust Review Checklist.
4.4 Signing keys, trust bundles and rotation
| ID | Requirement | Type |
|---|---|---|
| WIP-KEY-01 | Signing keys are generated and used in an HSM or cloud KMS with no export, and can chain to [Organisation]'s existing root or an offline root. | M |
| WIP-KEY-02 | Each trust domain has its own keys; key reuse across trust domains (for example staging and production) is not possible by configuration. | M |
| WIP-KEY-03 | Scheduled rotation publishes new keys in the trust bundle before they sign anything; the SPIFFE Federation specification recommends publishing 3 to 5 times the bundle refresh hint ahead of use. State the default refresh hint. | M |
| WIP-KEY-04 | Emergency rotation and revocation of a compromised intermediate or signing key, with a documented procedure and measured time for relying parties to stop accepting it. | S |
| WIP-KEY-05 | Backup and restore of configuration and key metadata, tested restore into an isolated environment, and disaster recovery targets of [RPO, RTO]. | S |
4.5 Policy and authorisation integration
| ID | Requirement | Type |
|---|---|---|
| WIP-POL-01 | Exposes workload identity to [service mesh, API gateway, policy engine] so authorisation decisions use the workload identifier, not network location. NIST SP 800-207A calls for policies based on application and service identities. | S |
| WIP-POL-02 | Supports identity path conventions [Organisation] defines (environment, team, service) so policy can be written once per path. | S |
| WIP-POL-03 | States clearly which authorisation decisions the platform makes and which remain with relying parties. Authentication does not imply authorisation. | I |
4.6 Visibility, logging and detection
| ID | Requirement | Type |
|---|---|---|
| WIP-LOG-01 | Logs every issuance (identity, attested properties, node, lifetime), registration change, federation change, key event and admin action, streamed to [SIEM] in a documented schema. | M |
| WIP-LOG-02 | Provides an inventory of active identities, last issuance and issuing node, exportable through API. | S |
| WIP-LOG-03 | Ships detections or documented queries for registration of a new identity on an unexpected node, new or widened federation trust (ATT&CK T1484.002 Trust Modification), key use from an unexpected host, and issuance spikes. | S |
| WIP-LOG-04 | Supports investigation: which credentials an identity received, from which node, and which relying parties accepted them, where relying party logs are available. | S |
See the Workload Identity Compromise Response Playbook.
5. Security of the workload identity platform
The issuer can mint any identity in its trust domain, so its own security is weighted as heavily as its features. Attackers who control the signing keys can forge credentials offline (ATT&CK T1649 Steal or Forge Authentication Certificates).
| ID | Requirement | Type |
|---|---|---|
| WIP-SEC-01 | Administrators authenticate through [Organisation] SSO with phishing-resistant MFA; admin roles separate platform administration, registration approval, federation approval and key custody. | M |
| WIP-SEC-02 | Registration entries for production paths and all federation changes can require approval by a second person. | S |
| WIP-SEC-03 | List every credential the platform itself holds (KMS or HSM access, datastore, upstream CA, bundle endpoint TLS, cloud federation configuration) and how each is scoped, rotated and revoked. | M |
| WIP-SEC-04 | Agents and sidecars run with the least privilege documented per platform; describe isolation between workloads on the same node. | M |
| WIP-SEC-05 | For managed offerings: bidder staff have no standing access to signing keys or configuration; describe support access, approval, logging and data residency. | M |
| WIP-SEC-06 | Provide a current independent assurance report, a [SIG or CAIQ] response, a published vulnerability disclosure policy, a recent penetration test summary, and a software bill of materials for self-hosted components. | M |
| WIP-NF-01 | Exit: full export of registration entries, federation configuration and logs in documented formats, a supported path to re-issue identities from another issuer, and certified deletion within [days]. | M |
6. Implementation, services and support
- Phasing: propose phases with acceptance criteria, for example [one cluster and one cloud federation target first, then CI pipelines, then virtual machines, then partner federation and AI agents].
- Coexistence: describe running alongside existing service mesh identities and internal CA certificates, and how relying parties trust both during migration.
- Static secret retirement: describe how the bidder helps find and retire the static keys each migrated workload used, and how retirement is verified.
- Scale and availability: tested issuance rate, behaviour when the control plane is unreachable (how long existing credentials remain valid), and multi-region design.
- Team and references: named roles and [two or three] references of similar scale, at least one using federation to [cloud providers] in production.
- Support: severity definitions and targets, release cadence, notice of breaking changes to specifications implemented.
7. Commercials
| Cost element | What to state |
|---|---|
| Licence metric | Per workload, per node, per cluster, per issuance or flat; how growth and short-lived workloads (jobs, functions) are counted |
| Modules | Which section 4 requirements need separate modules (federation broker, token exchange, HSM integration, detections) |
| Hosting | Managed service price, or infrastructure required to self-host at the volumes in section 2 |
| Implementation and training | Fixed price or day rate with estimated days by phase |
| Growth, renewal and exit | Price for [growth percentage] more workloads, renewal cap, exit assistance |
8. Evaluation method, demonstration and proof of concept
| Criterion | Weight | Evidence |
|---|---|---|
| Issuance, attestation and registration (4.1, 4.2) | [25%] | Demonstration, proof of concept on [platforms] |
| Federation and token exchange (4.3) | [20%] | Proof of concept against [cloud provider] and a test partner trust domain |
| Keys, rotation and logging (4.4, 4.6) | [15%] | Rotation exercise, SIEM output |
| Platform security (5) | [15%] | Assurance reports, architecture and permission review |
| Implementation approach and references (6) | [10%] | Section 6, reference calls |
| Life-cycle cost (7) | [15%] | Three-year cost at expected workload growth |
Scored requirements use 0 to 5: 0 not met; 1 roadmap only; 3 met with configuration or partly demonstrated; 5 met fully and demonstrated. A mandatory requirement not met excludes the bid. The proof of concept of [number] weeks runs in [non-production clusters and accounts] and covers at minimum:
- Attested issuance: issue identities to a pod, a virtual machine and a CI job from platform evidence only; confirm a pod with the wrong service account or namespace receives nothing.
- Cloud access without keys: a workload reads a test object in [cloud provider] through federation; confirm no static key exists anywhere in the path.
- Federation conditions: present a token from the right issuer but a different branch, repository or subject, and confirm it is rejected.
- Audience and replay: replay a token issued for service A against service B and confirm rejection.
- Rotation: run a scheduled signing key rotation, then an emergency one, and measure time until every relying party in the test accepts only the new key.
- Control plane outage: stop the issuer and record how long workloads keep working and what fails first.
- Detection: create an unapproved registration entry and widen a federation trust; confirm alerts reach [SIEM] within [minutes].
Implementation guidance
This section is for the evaluation panel, not for bidders.
- Mandatory means testable: keep M requirements to what you will verify in the proof of concept. Every M a bidder self-certifies without evidence is a risk transferred to you.
- Watch the bearer token default: many deployments start with bearer JWTs because they are easy. Score WIP-ISS-05 on what is enabled by default, not on what is possible.
- Federation is where scope widens: most real-world federation weaknesses come from subject conditions that match more than intended. Weight WIP-FED-03 and test it with negative cases, not only the happy path. See Top 10 Workload Identity Mistakes.
- Managed or self-hosted: a managed issuer removes operational load but puts the signing keys under a supplier's operations; self-hosting keeps keys in your HSM but makes availability yours. Decide which you can accept before scoring, rather than letting the scoring decide.
- Small organisations: if the estate is one cloud provider and one CI system, the provider's native workload federation may meet most of section 4.3 without a separate platform. Run this RFP when multi-cloud, on-premises or partner federation needs make a dedicated issuer worthwhile. See SPIFFE vs Cloud-Native Workload Identity.
- Drafts move: the WIMSE architecture is an Internet-Draft (draft-ietf-wimse-arch-08, July 2026, checked November 2026) with Informational intended status. Score on implemented, versioned behaviour, not on draft compliance claims.
- After award: use the Workload identity platform (workload identity issuer and federation broker) health check as the acceptance baseline and annual review.
To show auditors how the requirements map to controls, the panel can use this table.
| Requirement group | NIST SP 800-53 Rev 5 | NIST CSF 2.0 | ATT&CK technique addressed |
|---|---|---|---|
| Issuance and credential formats (4.1) | IA-5(2), IA-9 | PR.AA-01, PR.AA-03 | T1528 Steal Application Access Token |
| Federation and token exchange (4.3) | IA-9, AC-5 | PR.AA-03 | T1484.002 Trust Modification; T1550.001 Application Access Token |
| Keys and rotation (4.4) | SC-12, SC-13 | PR.AA-01 | T1649; T1552.004 Private Keys |
| Logging (4.6) | AU-9 | PR.PS-04 | T1078.004 Cloud Accounts |
| Supplier assurance (5, 7) | SA-9, SR-6, CA-8 | GV.SC-07 | Not technique-specific |
Standards and references
- SPIFFE: Federation specification
- SPIFFE: JWT-SVID specification
- SPIFFE: Overview
- IETF: RFC 8693 OAuth 2.0 Token Exchange
- IETF: Workload Identity in Multi System Environments (WIMSE) Architecture, Internet-Draft
- NIST: SP 800-207A Zero Trust Architecture Model for Access Control in Cloud-Native Applications in Multi-Cloud Environments
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls
Related NHI Mgmt Group resources: Cloud Workload Identity Buyer's Guide · Securing the workload identity platform (workload identity issuer and federation broker) itself · WIMSE Workload Identity Architecture Guide · NHI Security Platform RFP Template