Non-Human Identity (NHI) Risk Checklist & Workload Identity Planner
Kubernetes workload identity lets a pod call cloud APIs with a short-lived token from the cluster instead of a stored secret: EKS Pod Identity or IRSA on AWS, Microsoft Entra Workload ID on AKS, Workload Identity Federation for GKE. This tool first scores each non-human identity you list (service accounts, pipeline keys, API keys, OAuth apps, bots, AI agents) and gives one prioritised fix list, then plans the keyless pattern for where your code runs. Everything runs in your browser.
Add a non-human identity
One row per identity: a service account, pod identity, pipeline credential, API key, OAuth app, bot or AI agent. Use a nickname, not the secret.
A cloud, directory or database account that software signs in as.
This is an example inventory so you can see a result. Edit any row, or add your first identity to replace it. Your own list is kept in this browser only.
MFA does not apply: software cannot answer a second factor. The compensating controls are short-lived federated credentials, a tight trust or network restriction, least privilege and monitoring.
Why it scores 52
- +3Owned by a team but no named person, so reviews and offboarding tend to slip.Fix: Record one named owner (plus the team) in your inventory or as a tag on the identity.
- +12A static secret works for whoever holds a copy, from anywhere, until someone revokes it.Fix: Replace the stored credential with a platform-issued identity (an IAM role, a managed identity or workload identity federation) so there is nothing to leak or rotate.
- +10The credential is over a year old, so old copies in logs, laptops and backups still work.Fix: Rotate it in a safe order (create new, deploy, verify, then revoke old), and set a rotation date or expiry.
- +10Broad read/write rights well beyond what the job needs.Fix: Cut permissions to the actions and resources it actually used (use last-accessed data, such as IAM Access Analyzer on AWS), and scope to one resource group, project or account.
- +8In an env var or config file on a host, readable by anyone or anything with access to that host.Fix: Move it to a secrets manager the workload reads at runtime, or remove it entirely with a keyless pattern.
- +8The same identity works in dev/test and production, so a weaker test environment leads to production.Fix: Split it: one identity per workload and per environment, each with only its own permissions.
- +4Usable from any network, so a copied credential works from an attacker’s machine.Fix: Restrict where it can be used: network or IP conditions on the key, or Conditional Access for workload identities (single-tenant service principals in Microsoft Entra).
What this tool is
- Part 1 is an inventory checklist: add each service account, pod identity, CI/CD credential, API key, OAuth app, bot or AI agent and answer eight questions about it.
- Each identity gets a 0–100 risk score with every factor explained (owner, credential type, age, privilege, last use, where the secret lives, sharing, restriction), mapped to the OWASP Non-Human Identities Top 10 (2025).
- The inventory rolls up into gaps (how many are static, unowned, over-privileged or dormant) and one prioritised fix list, biggest risk first.
- Part 2 is a workload identity planner: pick AWS, Azure or Google Cloud and where the code runs (EKS, AKS, GKE, VMs, GitHub Actions, other Kubernetes, another cloud, on-prem) and get the keyless pattern by its product name and the steps to retire the static key.
- It explains workload identity vs managed identity in plain words. Copy either part as a plain-text report. Runs in your browser; nothing is uploaded.
The NHI risk checklist, question by question
Add each identity as one of seven types: service account, workload / pod identity, ci/cd credential, api key, oauth app / integration, bot or rpa account, ai agent. Then answer eight questions. The points show how much each answer adds; the score is the total as a share of the worst possible answers, from 0 to 100 (Low under 15, Moderate 15–34, High 35–54, Critical 55 and over).
- Owner known? Named person (+0) · A team, no named person (+3) · Nobody knows (+14). An identity nobody owns is never reviewed or retired (OWASP NHI1 Improper Offboarding).
- Credential type. Federated / platform-issued (no stored secret) (+0) · Certificate or private key (+6) · Static secret, password or API key (+12) · A person’s token or account (+16). Federated means the platform issues a short-lived token and nothing is stored (OWASP NHI7 Long-Lived Secrets; NHI6 for CI/CD).
- Age / last rotation (stored credentials only). Rotated in the last 90 days (+0) · 90 days to a year old (+5) · Over a year old (+10) · Never rotated / unknown (+14).
- Scope / privilege. Scoped to what it needs (+0) · Broad (wide read/write) (+10) · Admin, owner or directory role (+20) (OWASP NHI5 Overprivileged NHI).
- Used in the last 90 days? Yes (+0) · Don’t know (+5) · No (dormant but still valid) (+12). A dormant credential that still works is risk with no value.
- Where the secret is stored. Secrets manager / key vault (+2) · CI/CD secret store (+5) · Env var or config file on a host (+8) · Code, repo, image, ticket or chat (+16) (OWASP NHI2 Secret Leakage when it is in code or chat).
- Who else uses it? Only this one workload (+0) · Several apps share it (+6) · Shared across dev/test/prod (+8) · People also sign in with it (+10) (OWASP NHI9 NHI Reuse, NHI8 Environment Isolation, NHI10 Human Use of NHI).
- Restricted? Yes (+0) · No, usable from anywhere (+4). For a stored credential: network or location conditions. For a federated one: a trust pinned to an exact subject and audience.
MFA is not on the list because software cannot answer a second factor. The controls that stand in for it are short-lived federated credentials, a tight trust or network restriction, least privilege and monitoring. In Microsoft Entra, Conditional Access for workload identities can block single-tenant service principals by location or risk (it needs Workload ID Premium licences and does not cover managed identities).
OWASP item titles are from the OWASP Non-Human Identities Top 10 (2025). NHI3 (Vulnerable Third-Party NHI) is flagged for every OAuth app or third-party integration.
Keyless patterns by cloud and where the code runs
The planner’s recommendation for every combination. Open the planner tab for the steps, the gotchas and the official docs.
Access to AWS
- Amazon EKS: EKS Pod Identity (IRSA where Pod Identity is not available)
- EC2, Lambda or ECS on AWS: IAM role attached to the compute (EC2 instance profile, Lambda execution role, ECS task role)
- GitHub Actions: GitHub Actions OIDC → IAM role (AssumeRoleWithWebIdentity)
- Kubernetes elsewhere (self-managed, other cloud, on-prem): IRSA-style federation: the cluster’s service account token → AssumeRoleWithWebIdentity
- Compute on another cloud: The other cloud’s OIDC token → IAM role (AssumeRoleWithWebIdentity)
- Other CI/CD or platform that issues OIDC tokens: Your platform’s OIDC token → IAM role (AssumeRoleWithWebIdentity)
- On-prem server with no OIDC issuer: IAM Roles Anywhere (X.509 certificate from your PKI → temporary credentials)
Access to Azure / Microsoft Entra
- Azure Kubernetes Service (AKS): Microsoft Entra Workload ID on AKS (user-assigned managed identity + federated identity credential)
- VMs, App Service or Functions on Azure: Managed identity (user-assigned preferred) on the Azure resource
- GitHub Actions: GitHub Actions OIDC → workload identity federation (federated credential on an app registration or user-assigned managed identity)
- Kubernetes elsewhere (self-managed, other cloud, on-prem): Workload identity federation from any Kubernetes cluster
- Compute on another cloud: Workload identity federation from AWS or Google Cloud
- Other CI/CD or platform that issues OIDC tokens: Workload identity federation with your platform’s OIDC issuer (or SPIFFE/SPIRE)
- On-prem server with no OIDC issuer: Stand up an OIDC issuer (such as SPIFFE/SPIRE) and federate; otherwise a certificate credential
Access to Google Cloud
- Google Kubernetes Engine (GKE): Workload Identity Federation for GKE
- Compute Engine, Cloud Run or Cloud Functions: Attached service account (Compute Engine, Cloud Run, Cloud Functions)
- GitHub Actions: GitHub Actions OIDC → Workload Identity Federation (pool + provider)
- Kubernetes elsewhere (self-managed, other cloud, on-prem): Workload Identity Federation with the cluster as an OIDC provider
- Compute on another cloud: Workload Identity Federation from AWS or Azure
- Other CI/CD or platform that issues OIDC tokens: Workload Identity Federation with your OIDC or SAML identity provider
- On-prem server with no OIDC issuer: Workload Identity Federation with X.509 client certificates (keys only as a last resort)
Workload identity vs managed identity
- Workload identity
- The umbrella term. In Microsoft Entra, workload identities are applications, service principals and managed identities: any identity software uses to authenticate. “Microsoft Entra Workload ID” is also the product name, and on AKS it means pods using workload identity federation.
- Managed identity
- A special kind of service principal whose credentials Azure creates and rotates for you. You never see them. It works for code running on an Azure resource that supports it: VMs, scale sets, App Service, Functions, AKS and others. System-assigned dies with its resource; user-assigned is a standalone resource you can share.
- Workload identity federation
- A trust from a user-assigned managed identity or an app registration to an external token issuer (a Kubernetes cluster, GitHub, Google Cloud, AWS, any OIDC IdP). The workload swaps that issuer’s token for a Microsoft Entra token, so code outside Azure, or in AKS pods, also needs no secret.
- Which to use
- Code running directly on an Azure resource: a managed identity. Pods in AKS: Microsoft Entra Workload ID, usually a user-assigned managed identity with a federated identity credential (the two work together). Anything outside Azure: workload identity federation. A client secret is the last resort in all three cases.
The same idea on each cloud
- AWS: IAM role (temporary credentials via STS). Pods: EKS Pod Identity, or IAM roles for service accounts (IRSA). CI/CD and outside workloads: IAM OIDC provider + AssumeRoleWithWebIdentity.
- Azure: Managed identity / service principal in Microsoft Entra ID. Pods: Microsoft Entra Workload ID on AKS. CI/CD and outside workloads: Federated identity credential on an app registration or user-assigned managed identity.
- Google Cloud: Service account (attached, no key). Pods: Workload Identity Federation for GKE. CI/CD and outside workloads: Workload Identity Federation pool + provider.
For a deeper look at single identities, the Identity Risk Calculator scores blast radius and governance, the GitHub Token Scope Analyzer shows what a GitHub token can reach, and the Token Lifecycle Lab trains you to spot unsafe OAuth token setups. When a key has to stay, the Key Rotation Planner gives a safe rotation order, and the IAM Policy Analyzer checks an AWS policy for least privilege.
Frequently asked questions
What is Kubernetes workload identity?
It lets a pod call cloud APIs as a cloud identity without a stored secret. The cluster projects a short-lived, signed service account token into the pod; the cloud trusts the cluster as a token issuer and swaps that token for short-lived cloud credentials mapped to one Kubernetes service account. On Amazon EKS it is EKS Pod Identity or IAM roles for service accounts (IRSA), on AKS it is Microsoft Entra Workload ID, and on GKE it is Workload Identity Federation for GKE.
What is the difference between Azure workload identity and managed identity?
Workload identity is the umbrella: in Microsoft Entra, applications, service principals and managed identities are all workload identities. A managed identity is a service principal whose credentials Azure creates and rotates, usable by code running on an Azure resource that supports it. Workload identity federation (and Microsoft Entra Workload ID on AKS) lets a user-assigned managed identity or an app registration trust tokens from an outside issuer such as a Kubernetes cluster or GitHub. Code on an Azure VM or App Service uses a managed identity directly; pods on AKS and anything outside Azure use federation, usually to a user-assigned managed identity.
How does AKS workload identity federation work?
Enable the OIDC issuer and workload identity on the cluster (both are preconfigured on AKS Automatic). Create a user-assigned managed identity or app registration and add a federated identity credential with the cluster’s issuer URL, the subject system:serviceaccount:NAMESPACE:NAME and the audience api://AzureADTokenExchange. Annotate the Kubernetes service account with azure.workload.identity/client-id and label the pod azure.workload.identity/use: "true". The webhook injects a projected token, and the Azure Identity library exchanges it for a Microsoft Entra token. It replaces the deprecated pod-managed identity.
What is machine identity security?
Managing every identity that is not a person: service accounts, workload identities, API keys, certificates, CI/CD credentials, OAuth integrations, bots and AI agents. In practice it is an inventory with an owner for each one, short-lived federated credentials instead of stored secrets wherever the platform allows, least privilege, retiring identities that are no longer used, and alerting on unusual use. This checklist scores the first five of those for each identity you list.
How do you secure service accounts?
Give each one a named owner and a single job. Remove stored keys where a keyless option exists (IAM roles, managed identities, workload identity federation); where a key must exist, keep it in a secrets manager and rotate it. Cut permissions to what it actually uses, never share it across apps, environments or people, disable it when it has not been used for 90 days, and restrict where it can be used from. Humans should never sign in with a service account.
Should I use EKS Pod Identity or IRSA?
AWS recommends EKS Pod Identity whenever possible: it needs no IAM OIDC provider per cluster, roles do not need a trust-policy edit for each new cluster, and credentials carry session tags for attribute-based access control. IRSA is still the option where Pod Identity is not available: Fargate, Windows EC2 nodes, EKS Anywhere, AWS Outposts and self-managed Kubernetes on EC2.
More free security tools
The tools people use most on PlayCISO.
Catch injected instructions hiding in content your AI agent should only read.
Score your readiness against the first international standard for AI security threats.
Critical CVEs across 21 major vendors, month by month — and what the 2026 surge means.
Build an ordered ruleset, replay labelled packets and catch shadowed and any-to-any rules.
Self-assess all six Functions, from Govern to Recover, and see your weakest one.
Search 172 threat actors across Microsoft, CrowdStrike, Mandiant and community names.