Non-Human Identity Security Starts With This Simple Question

Most security teams know they have a non-human identity problem. Fewer have a shared language for describing it.

Non-Human Identities (NHIs) are the digital gatekeepers for the automated world. They enable code, applications, services, devices, and agents to authenticate and access resources without human intervention. But in many organizations, the conversation gets muddy fast. Is the NHI the API key, the token, the certificate, or the service account?

The answer determines how you govern ownership, lifecycle, access, rotation, monitoring, and incident response.

The simplest way to reduce that ambiguity is to separate the identity subject from the authentication mechanism. In other words: separate what the identity represents from how it proves its legitimacy.

This blog focuses on that classification model as explained in CSA’s recent Defining Non-Human Identity paper.

 

What is a Non-Human Identity?

An NHI is not every non-human object in your environment. An entity qualifies as an NHI only when:

1. It can authenticate (prove who it is), and
2. Someone/thing can authorize it to access resources.

For example:

• A Kubernetes service account is an NHI.
• A workload identity assigned to a containerized application is an NHI because it represents an actor requesting access.
• An API key is not the NHI itself, but a credential that an NHI may use.
• A certificate is not the identity, but a mechanism used to prove the identity.
• A script that does not authenticate is not an NHI, even if it performs an automated task.

If teams mistake the credential for the identity, they may rotate the secret without governing the actor behind it. They may find an exposed token but fail to identify the workload, application, device, or agent that used it. They may clean up a leaked credential while leaving the underlying service account active, over-permissioned, and unowned.

A helpful analogy is a human identity with multiple physical identification documents. A person may hold both a passport and a driver’s license, but only the driver’s license authorizes them to drive. Similarly, an NHI may use an API key and an OAuth token for different actions while fulfilling its purpose.

The person is the identity. The document is the credential. For machines, the same principle applies.

 

Identity Subject vs. Authentication Mechanism

We recommend classifying NHIs across two axes:

1. Identity Subject: What the identity is bound to
2. Authentication Mechanism: How the identity proves itself

This solves a common governance problem. Organizations frequently treat API keys, tokens, or certificates as if they are the identity. In practice, they are simply authentication mechanisms. The identity subject is the actual actor.

For example, a Kubernetes workload may use OIDC tokens to access cloud APIs. It may also use mTLS certificates for service-to-service communication. Those are different credentials, but they authenticate the same underlying workload identity.

Anchor governance to the identity subject. Tailor credential controls to the authentication mechanism. Put another way: govern the actor, secure the credential.

 

What the Identity Subject Tells You

The identity subject describes who or what is requesting access. Each type requires different governance treatment.

 

Service and Integration Account Identities

These are the “legacy” workforce of automation. They are typically long-lived accounts used to enable third-party integrations or automate background tasks. Common examples include SaaS integration accounts, application service principals, middleware service accounts, and scheduled job accounts.

Their biggest challenge is persistence. These accounts often use static credentials. Organizations rarely rotate them and they may remain active long after their original purpose disappears.

 

Workload and Microservice Identities

Workload and microservice identities represent application code running inside containers, clusters, serverless environments, or service meshes. They are central to modern east-west traffic, including service-to-service communication and event-driven architectures.

Unlike traditional service accounts, these identities may be highly ephemeral. A quarterly review is not useful for identities that may only exist for minutes.

For these identities, governance needs to focus on automation, attestation, short-lived credentials, service ownership, and runtime monitoring. Security teams need to know whether a workload is operating in the right namespace, environment, and trust zone.

 

Infrastructure Identities

Infrastructure identities are assigned to compute resources such as cloud instances, virtual machines, nodes, or instance profiles. Cloud providers often provision these identities and tie them to infrastructure lifecycle events.

The governance risk is that you can decommission infrastructure without removing or restricting the associated identity. This can create “ghost resources” or lingering access paths. Tightly integrate infrastructure identities with infrastructure-as-code, asset inventory, and cloud identity controls. Revoke access when the resource lifecycle ends.

 

Device Identities

Device identities are bound to physical hardware, firmware, industrial sensors, IoT systems, smart office equipment, and other connected devices. These identities create an operational challenge of scale and updateability.

Rotating keys on a fleet of remote devices is not the same as rotating a token for a cloud workload. Hardware limitations, unreliable connectivity, field deployment, firmware constraints, and hostile physical environments can all affect how you implement identity controls. Governance for device identities needs to account for device ownership, firmware version, risk profile, telemetry, certificate revocation, and secure disposal.

 

Agent Identities

Agent identities are the newest and fastest-evolving class of NHI. Unlike static scripts, AI agents powered by LLMs can reason, plan, and execute complex chains of tasks independently.

Agent identities may possess delegated authority to act on behalf of a human user. They may take multi-step actions that you did not explicitly script. They may interact with APIs, create downstream tasks, or trigger other tools and agents. In some cases, an agent authorized to “read calendar” could attempt to “send invites” unless you tightly scope permissions.

This creates several governance challenges:

• Agent Impersonation: Can the organization verify that the agent is the legitimate actor?
• Scope Creep: Are the agent’s permissions expanding beyond its intended purpose?
• Delegated Authority: Is the agent acting within the human user’s approved permissions?
• Multi-Step Chaining: Can you trace each action back to the original approved task?
• Intervention: Is there a kill switch or revocation mechanism for high-risk behavior?

Agent identities are especially difficult because they make decisions based on context, prompts, goals, tools, and available permissions. That makes least privilege, behavioral baselining, and audit logging much more important.

 

What the Authentication Mechanism Tells You

The authentication mechanism describes how the identity asserts trust. Common mechanisms include static secrets, signed tokens, certificates, hardware/attestation-backed credentials, and cloud-native session credentials.

This dimension influences security strength, rotation policies, renewal automation, and cryptographic requirements. A practical way to think about it is to map each credential type to its most important control considerations.

 

Static Secrets

Static secrets include passwords, API keys, SSH keys, database credentials, connection strings, and other long-lived credentials. They are common because they are convenient. They are risky because they persist.

Static secrets usually require:

• Vaulted storage
• Centralized governance
• Automated rotation
• Runtime injection
• Secrets scanning
• Clear ownership
• Removal of stale or orphaned credentials

Static credentials can create a large blast radius. Attackers may be able to use them for long periods before detection. They also tend to spread across repositories, pipelines, configuration files, and developer workflows.

 

Signed Tokens

Signed tokens such as JWTs, OIDC tokens, and SAML assertions contain identity claims, permissions, and metadata. They are useful in distributed architectures because services can validate tokens without always contacting the issuer.

Signed tokens usually require:

• Short time-to-live periods
• Audience validation
• Scope limitation
• Secure storage
• Asymmetric signing where appropriate
• Refresh token rotation
• Replay protection

For machine-to-machine authentication, tightly scope tokens to their intended service, action, or resource.

 

Certificates

Certificates such as X.509 certificates or SPIFFE SVIDs provide cryptographic proof of identity through public key infrastructure. They are foundational for mTLS, service mesh architectures, and Zero Trust approaches to workload identity.

Certificates usually require:

• Automated issuance
• Automated renewal
• Private key protection
• Certificate lifecycle management
• Short-lived validity periods
• Strong binding to workload or service identity

 

Hardware-Backed or Attestation-Backed Credentials

Hardware-backed credentials use technologies such as TPMs, HSMs, or secure elements to strengthen trust. Attestation-backed credentials go further by also helping verify the integrity of the platform or execution environment.

These credentials usually require:

• Platform attestation
• Non-exportable keys
• Execution context verification
• Workload integrity checks
• Hardware trust boundaries

A valid identity alone may not be enough. Adversaries can compromise a workload, VM, container, or device while using legitimate credentials. Combine identity verification with platform attestation.

 

Cloud-Native Session Credentials

Cloud-native session credentials, such as STS-style temporary credentials, are short-lived credentials issued by cloud identity services.

Cloud-native session credentials usually require:

• Workload identity federation
• Short-lived access tokens
• Token audience binding
• No long-term keys
• Automatic refresh
• Pipeline secret scanning
• Strong upstream identity protection

For many organizations, the long-term goal should be moving toward ephemeral, secretless, or dynamically issued credentials.

 

Why This Matters for Governance

Governance and management are not the same. Governance establishes policies, ownership, monitoring, auditability, and risk alignment. Management handles the end-to-end lifecycle. This includes provisioning, maintenance, monitoring, and decommissioning.

Without the identity subject vs. authentication mechanism distinction, both governance and management become harder. Teams may know a token exists without knowing what actor it belongs to. They may rotate a secret without removing the stale identity behind it. They may revoke a certificate without understanding what systems depend on it.

Consider a common scenario: a security team discovers an exposed API key in a repository. They rotate the key and close the ticket.

On paper, they have addressed the credential issue. But what if the underlying service account still has broad production access? What if no one in the organization knows who owns it? What if they created it for a project that ended two years ago?

In that case, rotation does not fix the governance failure. The organization still has an actor with access, unclear ownership, weak lifecycle management, and limited accountability.

This is why NHI governance must go beyond credential hygiene. Organizations also need to answer:

• Who or what is the actor and who is accountable for it?
• What business or technical function does the actor support?
• What permissions does the actor have, and are necessary?
• What systems depend on it?
• What event should trigger decommissioning?
• Can you trace actions to a specific identity, owner, or delegator?

This is especially important when NHIs act on behalf of human users through delegated access. In those cases, audit logs should retain accountability by reflecting the delegator, intent, and actions. Otherwise, organizations may not be able to tell whether responsibility lies with the NHI, the human user, or both.

For security leaders and governance teams, this also turns NHI security into a business risk issue. Orphaned identities, excessive permissions, static secrets, and fragmented control planes are not just technical debt. They can increase the risk of data exposure, lateral movement, compliance gaps, and delayed incident response.

 

A Practical Way to Apply the Model

Security teams can start using this model without boiling the ocean. For each NHI, ask:

What is the identity subject: Is this identity bound to a service, workload, infrastructure resource, device, or agent?

Who owns it: Is there a human owner, technical owner, business owner, or oversight sponsor accountable for its behavior?

How does it authenticate: Does it use a static secret, signed token, certificate, hardware-backed credential, etc.?

What access does it actually need: Are permissions scoped to a specific service, API, resource, task, or environment?

How is it monitored: Can the organization detect anomalous behavior, privilege expansion, credential misuse, or behavioral drift?

How is it decommissioned: What event triggers revocation, deletion, or offboarding?

These questions help shift NHI security away from scattered credential cleanup and toward structured identity governance.

 

Applying the Model During Application Onboarding

One of the most practical places to apply this model is during application onboarding. Before a new application moves into production, teams should identify all NHIs the application creates, uses, or depends on.

A lightweight onboarding workflow could include:

1. Inventory the NHIs: Document service accounts, workload identities, infrastructure identities, integration identities, device identities, and agent identities associated with the application.
2. Classify the identity subject: Determine what each identity represents and whether it is long-lived, ephemeral, delegated, autonomous, or tied to infrastructure.
3. Assign ownership: Identify the technical owner, business owner, and escalation contact. For agent identities, assign a human sponsor or oversight owner.
4. Document permitted usage: Define what the identity can do and what systems it may access.
5. Choose the authentication mechanism: Determine whether the identity will use static secrets, signed tokens, certificates, hardware-backed credentials, etc.
6. Scope permissions: Apply least privilege based on the identity’s intended purpose, environment, and data sensitivity.
7. Define monitoring expectations: Establish expected behavior, logging requirements, anomaly triggers, and response actions.
8. Set decommissioning triggers: Define when to revoke the identity and its credentials.

 

The Bottom Line

The NHI problem is not just that there are too many machine identities. The problem is that we designed traditional IAM models around people, while NHIs originate from software lifecycle events. Security teams need a model that reflects how automated systems actually operate.

Separating the identity subject from the authentication mechanism gives organizations a clearer path forward. It improves visibility, strengthens accountability, and helps teams apply the right control to the right layer. Most importantly, it clarifies that governance controls apply to “actors with access,” not everything non-human.

Check out the full paper to learn more about NHI risk, management, frameworks, and governance.