A workload identity platform becomes the root of trust for every service that uses it, and it degrades without anyone noticing: signing keys outlive their rotation plan, trust conditions widen to fix a broken deployment, and registrations for retired workloads keep issuing credentials. This page is a recurring health check for the platform that issues workload credentials and brokers federation between trust domains, whether that is a self-hosted issuer such as a SPIFFE implementation, a cloud security token service with federation trust policies, or a mix of both. It gives you 13 metrics with formulas, data source types and red, amber and green thresholds, a sign-off cadence, red flags and a findings log you can copy. It is written for platform engineers, IAM and NHI leads, and the reviewers in security operations or internal audit who check their figures.
What this health check covers
The check measures the issuer and broker as a platform: how strongly it verifies a workload before issuing a credential, how short and narrow those credentials are, how well signing keys and trust bundles are managed, whether federation trust relationships are still tight and wanted, and whether administration of the platform itself is controlled and logged. It does not explain how to design workload identity or federation; that is in the Cloud Workload Identity Guide and the Workload Identity Federation Guide, and every remediation below points back to those and related live guides.
It is deliberately separate from two neighbouring reviews. A programme-level NHI review measures outcomes such as how much of the estate has moved to federation; the Cloud Identity Health Check measures cloud account roles, keys and trusts. This page measures only the platform that mints and validates workload credentials. The check is run by the platform owner and re-performed in part by someone independent of the platform team. It produces evidence for NIST SP 800-53 Rev. 5 IA-9 Service Identification and Authentication, IA-5 Authenticator Management, SC-12 Cryptographic Key Establishment and Management and AU-6 Audit Record Review, Analysis, and Reporting, and for NIST CSF 2.0 PR.AA-01, PR.AA-03 and PR.PS-04.
Key takeaways
- Measure the proof, not the credential. A short-lived credential issued on weak evidence, such as a static selector or a reusable bootstrap secret, is only as strong as that evidence, so attestation strength comes first.
- Audience and lifetime are the blast radius. The SPIFFE JWT-SVID specification requires an audience claim and encourages the shortest reasonable validity; broad audiences and long lifetimes turn one leaked token into wide replay.
- Federation trust conditions drift wider, never narrower. Review every trust relationship for exact subject and audience conditions, and remove those that issued nothing last quarter.
- Key rotation is only proven when relying parties keep up. Track bundle and key-set propagation, not just the rotation event on the issuer.
- The issuer is tier 0. Whoever administers it can mint any workload identity in its trust domain, so its admin footprint and audit trail are measured every quarter.
How to use this template
Copy the cadence, metrics and findings log tables into your own tracker and replace text in square brackets, such as [Organisation], [Platform owner] and [Head of IAM], with your own names. At the first run, write down the scope: which issuers, trust domains, federation pools or trust policies, and which relying parties are in. Keep that scope stable so a changed figure means drift, not a change in counting. For each metric, store the raw export with the date, the person who ran it and the account used. All thresholds are NHI Mgmt Group recommended thresholds; adjust to your risk appetite and record the values you adopt. A platform in its first year may treat amber as its target and tighten later.
Cadence and sign-off
| Review | Frequency | Owner | Approver | Evidence kept |
|---|---|---|---|---|
| Core metrics run (WIP-01 to WIP-13) | Quarterly, within 15 working days of quarter end | [Platform owner] | [Head of IAM] | Raw exports, metric workbook, list of exceptions |
| Signing key and bundle propagation check (WIP-06, WIP-07) | After every planned rotation, and at least monthly | [Platform owner] | [Platform owner], escalated if red | Key inventory, relying party fetch logs |
| Federation trust relationship attestation | Quarterly | Owner of each federated trust domain or external issuer | [Head of IAM] | Signed list of trust relationships with business reason |
| Independent re-performance | Quarterly | [Security operations] or [Internal audit] | [Head of IAM] | Re-run of at least two metrics from raw data |
| Trust root rotation exercise (WIP-13) | Annual | [Platform owner] | [CISO] | Exercise record, timings, issues raised |
| Event-driven run (affected metrics only) | After an upgrade, a new trust domain, a new federation partner or a suspected compromise | [Platform owner] | [Head of IAM] | Before and after figures |
Metrics
NHI Mgmt Group recommended thresholds; adjust to your risk appetite. "Issuance" means a credential minted by the platform for a workload: an X.509 certificate, a signed token, or a cloud access token returned by a token exchange. "Trust relationship" means any configured acceptance of credentials from another issuer, such as a federation trust policy, a federated bundle or an external token issuer.
| ID | Metric | Formula (numerator / denominator) | Data source type | Green | Amber | Red |
|---|---|---|---|---|---|---|
| WIP-01 | Hardware or platform-rooted node attestation | Nodes or runtimes attested by platform evidence (instance identity document, TPM-backed key, orchestrator-signed token) / all attested nodes or runtimes | Issuer node or agent inventory with attestation method | 95% or above | 85% to below 95% | Below 85% |
| WIP-02 | Reusable bootstrap secrets | Bootstrap secrets or join credentials that are reusable or valid for more than 24 hours / all bootstrap secrets issued in the period | Issuer bootstrap or enrolment token log | 0 | Any, each with a dated exception | Any without an exception |
| WIP-03 | Over-broad registration selectors | Registration entries or issuance rules matching on a single weak property (for example a user ID alone or a whole namespace) / all registration entries or rules | Issuer registration or policy export | Below 2% | 2% to 5% | Above 5% |
| WIP-04 | Credential lifetime within policy | Issuances whose validity is within the policy maximum (record it, for example 1 hour for bearer tokens) / all issuances in a sample week | Issuance audit log | 99% or above | 95% to below 99% | Below 95% |
| WIP-05 | Audience-scoped tokens | Token issuances with a single, service-specific audience / all token issuances in the sample | Issuance audit log, token claims sample | 95% or above | 85% to below 95% | Below 85%, or any token with no audience |
| WIP-06 | Signing key age | Active issuer signing keys and intermediate authorities older than the planned rotation period / all active signing keys and authorities | Issuer key inventory | 0 | Any past period by up to 30 days | Any past period by more than 30 days |
| WIP-07 | Relying party bundle freshness | Relying parties and federated domains holding the current trust bundle or key set within the agreed window after a change / all relying parties and federated domains | Bundle endpoint fetch logs, relying party configuration export | 100% | 95% to below 100% | Below 95% |
| WIP-08 | Exactly pinned federation trusts | Trust relationships whose issuer, subject and audience conditions are exact values, with no wildcard or prefix match / all trust relationships | Federation trust policy export | 100% | 95% to below 100%, each exception approved | Below 95%, or any unapproved wildcard |
| WIP-09 | Dormant trust relationships | Trust relationships with no successful exchange or validation in 90 days / all trust relationships | Federation trust export joined to token exchange logs | Below 5% | 5% to 15% | Above 15% |
| WIP-10 | Orphaned registrations | Registration entries or issuance rules with no named owner, or pointing at a retired workload, or with no issuance in 90 days / all registration entries or rules | Registration export joined to issuance log and service catalogue | Below 3% | 3% to 10% | Above 10% |
| WIP-11 | Issuance and renewal failure rate | Failed issuance or renewal requests / all issuance and renewal requests, per month | Issuer and agent error logs | Below 0.5% | 0.5% to 2% | Above 2%, or any outage longer than the shortest credential lifetime |
| WIP-12 | Platform administration footprint | Identities able to change registrations, trust relationships or signing keys, compared with the approved named list | Issuer role export, cloud role export for the token service | Matches list, all with phishing-resistant MFA | One or more unapproved identities, each removed within 5 working days | Any unapproved identity older than 5 working days, or any standing access without MFA |
| WIP-13 | Trust root rotation time (exercise) | Hours from start of an unplanned root or signing key rotation to all relying parties validating only the new key | Exercise record | Within the agreed target, for example 24 hours | Up to twice the target | More than twice the target, or not exercised in 12 months |
Two metrics need care. WIP-04 and WIP-05 are measured on a sample of issuances because high-volume issuers mint millions of credentials a day; take one full week and record the sample size. WIP-11 has a safety edge: if the issuer is unavailable for longer than the shortest credential lifetime, workloads fail closed, and teams under pressure tend to reintroduce static secrets. Record any such fallback as a finding even when the outage is resolved.
How to collect the data
- Node and runtime inventory (WIP-01): the issuer's agent or node list with the attestation method recorded for each entry. Compare against the asset inventory so that runtimes issuing credentials without any registered node show up.
- Bootstrap and enrolment log (WIP-02): the issuer's record of bootstrap tokens, enrolment secrets or pre-shared join credentials, with creation time, expiry and use count.
- Registration or policy export (WIP-03, WIP-10): every rule that maps workload evidence to an identity, with its selectors or conditions, owner field and creation date. Join it to the service catalogue to find retired workloads.
- Issuance audit log (WIP-04, WIP-05, WIP-11): the issuer's or token service's record of each credential minted, including subject, audience, validity and outcome. Where the log does not record claims, decode a sample of tokens taken at relying parties instead, without storing the tokens themselves.
- Key inventory and bundle endpoint logs (WIP-06, WIP-07): active signing keys and authorities with creation dates, the published trust bundle or key set with its sequence number, and fetch logs from relying parties and federation partners. The SPIFFE Federation specification recommends that clients log bundle fetches for forensic use, so these logs should exist.
- Federation trust policy export (WIP-08, WIP-09): each trust relationship with its issuer URL, accepted subject and audience conditions and the role or identity it maps to, joined to exchange logs for the last 90 days.
- Role exports (WIP-12): the issuer's own admin roles and, for cloud token services, the cloud roles that can edit trust policies or pools. Compare with the approved list held outside the platform.
Collect from a read-only reviewer account. Where the platform owner and the reviewer are the same person, the independent re-performance of WIP-08 and WIP-12 is the control that matters most.
Red flags that need action now
- A federation trust policy that accepts any subject from a shared public issuer, such as a hosted CI service, rather than a pinned repository, branch or environment. See CI pipeline OIDC federation hardening guide.
- Trust bundles from two trust domains merged into one validation set. The SPIFFE Federation specification says bundles from different trust domains must never be merged, because one domain could then forge identities from the other.
- A bundle endpoint URL, trust domain name or endpoint profile changed without a change record, or a bundle endpoint that follows a permanent redirect to a new host.
- Tokens issued with no audience or with a generic audience such as an environment name; the JWT-SVID specification requires the audience claim and discourages broad values.
- A signing key or intermediate authority past its rotation date with no scheduled rotation.
- A reusable bootstrap secret stored in an image, a repository or a pipeline variable.
- Production and non-production workloads issued identities from the same trust domain and keys; SPIFFE guidance is to use separate trust domains for different security environments.
- Any workload that fell back to a static secret during an issuer outage and was never moved back.
- An administrator added to the issuer or token service outside the approval process, or audit logging for the issuer switched off.
Findings log
| ID | Finding | Metric | Severity | Owner | Due date | Status |
|---|---|---|---|---|---|---|
| HC-WIP-01 | [e.g. 4 federation trust policies accept a wildcard subject from the CI issuer] | WIP-08 | [High] | [Platform owner] | [date] | [Open] |
| HC-WIP-02 | [e.g. intermediate signing authority 45 days past planned rotation] | WIP-06 | [High] | [Platform owner] | [date] | [Open] |
| HC-WIP-03 | [e.g. 11% of token issuances carry an environment-wide audience] | WIP-05 | [Medium] | [Application team lead] | [date] | [Open] |
| HC-WIP-04 | [finding] | [WIP-xx] | [severity] | [owner] | [date] | [status] |
Set severity from the metric's band and the reach of the affected identity: anything red that touches a trust root, a trust relationship mapped to an administrative role, or production signing keys is high regardless of percentage.
Remediation map
| Finding type | Where the fix is described |
|---|---|
| Weak node or workload attestation, reusable bootstrap secrets (WIP-01 to WIP-03) | Workload Attestation Guide; Secrets Zero Problem Guide |
| Long lifetimes, broad audiences (WIP-04, WIP-05) | WIMSE Workload Identity Architecture Guide; OAuth Token Exchange and Delegation Guide |
| Key age and bundle propagation (WIP-06, WIP-07, WIP-13) | JSON Web Key Sets (JWKS) and Signing Key Rotation Guide; SPIFFE and SPIRE Guide |
| Wildcard or dormant trust relationships (WIP-08, WIP-09) | Workload Identity Federation Trust Review Checklist; Cross-cloud workload identity federation |
| Orphaned registrations (WIP-10) | Service Account Security Guide |
| Issuer availability and static fallback (WIP-11) | Multi-Cloud Workload Identity Troubleshooting Guide |
| Admin footprint and suspected misuse (WIP-12) | Workload Identity Compromise Response Playbook |
Related guides
- Cloud Workload Identity Guide: the design and controls this check measures against.
- Workload Identity Federation Guide: how federation trust relationships are built.
- Cloud Identity and CIEM Maturity Model: where the results sit in a longer-term picture.
- Identity provider (IdP) and SSO platform health check: the matching platform check for the identity provider that signs in people rather than workloads.
- Top 10 Workload Identity Mistakes: the patterns behind most red results.
- Workload Identity Compromise Response Playbook: what to do when a red flag turns out to be a compromise.
References
- SPIFFE: JWT-SVID specification
- SPIFFE: SPIFFE Federation specification
- SPIFFE: SPIFFE concepts
- IETF: Workload Identity in a Multi System Environment (WIMSE) Architecture, Internet-Draft
- IETF: RFC 8693, OAuth 2.0 Token Exchange
- NIST: SP 800-207A, A 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
- NIST: Cybersecurity Framework 2.0
Related NHI Mgmt Group resources: Cloud Workload Identity Guide · SPIFFE and SPIRE Guide · Cloud Identity Health Check · Kubernetes Workload Identity Checklist