Non-Human Identities (NHIs) are finally making friends and influencing people—or at least they seem to be, given how much people are talking about them! This is great. People need to have a better sense of this brave new world of workloads, bots, and services. But this also means people need to have a better sense of what NHIs are not.
Whether you’re navigating workloads, APIs, or automated systems, the buzz around NHIs reflects their growing significance in everything from cloud computing to academic research. But as with any hot topic, there’s some confusion and waaaaaay too much marketing hype. I’ve written about NHIs before; today’s focus is on some of the main areas NHIs are different from human identities. The distinctions matter.
What NHIs Are Not
NHIs aren’t just API keys or OAuth tokens. Treating them as such would be like calling a password or a passkey a person’s digital identity—it oversimplifies their function and importance. Tokens, keys, and even credentials like X.509 certificates might help manage access, but they’re tools in the more extensive toolkit of workload identity management. (Natoma has published an interesting white paper on machine-to-machine authentication if you’re interested in more detail.)
NHIs represent software entities like batch processes, machine learning training models, or microservices operating independently of human identities. They operate at different speeds and have different selective disclosure requirements (yes, NHI use cases may include the need for selective disclosure). Proving who they are to access other systems or resources goes beyond simple authentication. Unlike human authentication, which often revolves around confirming a single user’s identity via passwords, passkeys, or biometrics, NHIs must establish trust and authorization in highly dynamic, machine-driven environments.
Comparing NHIs and Human Identities
Part of what makes understanding that NHIs are different is that, if you tilt your head just right, their requirements sound very familiar. They need to demonstrate their identity and the purpose and scope of their request. They benefit from cryptographic proofs, such as JSON Web Tokens (JWTs) or X.509 certificates, to securely bind their identity to a specific action. And, believe it or not, they have a lifecycle that must be managed. And let’s not forget they may need to cross trust boundaries in a federated workflow.
I’ll go into more detail next, but here’s the summary for those who want to get straight to the good stuff.
| Layer | Human Identities | Non-Human Identities (NHIs) |
|---|---|---|
| Contextual Validation | Role-based access; occasional risk checks | Task-specific; continuous granular checks |
| Cryptographic Assurance | Passwords, passkeys, MFA | JWTs, OAuth tokens, mTLS, certificates |
| Dynamic/Ephemeral Identities | Persistent, lifecycle-driven | Transient, task-driven |
| Cross-Boundary Trust | SSO, federation (SAML, OIDC) | Federated workload identities, SPIFFE |
Contextual Validation
For Human Identities:
- Humans typically authenticate using static credentials like passwords, passkeys, or biometric scans.
- Access is often role-based, with permissions tied to organizational hierarchies or specific job functions (e.g., an employee accessing their email).
- Context, like geolocation or time of access, may be used for risk-based decisions (e.g., blocking a login attempt from an unusual location).
For NHIs:
- NHIs rely on detailed, task-specific validation. For example, a microservice might only access a database during specific operational windows and for specific query types.
- Permissions are highly granular and tied to the NHI’s role in a larger process, such as allowing read-only access to one API endpoint while granting full control over another.
- Unlike humans, NHIs may operate across various environments, requiring continuous validation at scale.
Cryptographic Assurance
For Human Identities:
- Credentials often include usernames, passwords, or passkeys, validated via a central authentication server.
- Additional layers like multi-factor authentication (MFA) involve OTPs or hardware tokens, but the process remains human-centric.
For NHIs:
- NHIs use cryptographic credentials, such as JWTs, OAuth tokens, or X.509 certificates, to prove their identity and integrity.
- These credentials are typically short-lived and dynamically issued, ensuring they can’t be reused if intercepted.
- Cryptographic proofs (e.g., mutual TLS) are used to establish secure, trust-bound connections between services. Unlike humans, NHIs don’t rely on password-based authentication, making credential management more complex and secure when implemented correctly.
Dynamic and Ephemeral Identities
For Human Identities:
- Human identities are persistent and change only during significant lifecycle events, such as onboarding, promotions, or terminations.
- Joiner/mover/leaver workflows handle these transitions in directories like Active Directory or IAM systems.
For NHIs:
- NHIs are transient and may exist for just seconds or minutes, such as a containerized workload in Kubernetes that spins up to handle a specific task.
- Unlike human-centric workflows, they require dynamic provisioning and de-provisioning of identities without manual intervention. (It would be nice if human-centric flows did this, too, but that’s not common. Yet.)
- The absence of a natural lifecycle like “hiring” or “firing” makes traditional directory models ineffective for NHIs.
Cross-Boundary Trust
For Human Identities:
- Trust boundaries for humans are typically managed within a single organization or via federated identity systems like SAML or OpenID Connect.
- Federated access is often used to enable single sign-on (SSO) across organizational or application boundaries.
For NHIs:
- NHIs frequently operate in multi-cloud or hybrid environments, where they must authenticate across disparate trust domains.
- Identity federation for NHIs requires advanced mechanisms, such as SPIFFE or OAuth token exchanges, to securely share identity and permissions between services in different ecosystems.
- Unlike humans, NHIs may not have a single source of truth (like an HR system), necessitating more robust and decentralized trust models.
A Better Way to Think About NHIs
If you’re still thinking that NHIs belong in your human identity systems, I’m just not sure what to tell you. I would say we can agree to disagree, but getting this wrong has implications for how everyone interacts online, so I will continue to make a stand on this hill. NHIs require a different approach to identity management, including:
- Workload Identity Federation: So the NHIs can seamlessly authenticate across cloud providers.
- Dynamic Secrets and Token-Based Authentication: To enhance security and minimize exposure risks.
- Standards Efforts Like WIMSE and SPICE: Because standards to ensure consistent, secure service interactions are critical.
Final Thoughts
Embracing NHIs means rethinking your identity systems and recognizing that traditional identity paradigms need to evolve. I know it’s hard work and requires even more resources for your IAM programs, but NHIs are not magic. They cannot bring security and efficiency to your organization without investment. There are vendors out there (I am not one of them) who can guide you through designing or redesigning your systems to account for NHIs. You’ve got this.
If you or your organization need support with standards development, let me know. With my experience across various SDOs, I’m here to help guide you through the complexities of Internet standards development.