Non-human identities (NHIs) explained and how to secure them

Most organizations can't produce a complete inventory of the non-human identities (NHIs) running in their environment. Service accounts, API keys, and application credentials accumulate across Active Directory (AD) and cloud platforms, often without clear ownership, documented purpose, or a defined review cycle.

That gap carries real risk. According to the Netwrix 2025 Cybersecurity Trends Report, 46% of organizations experienced account compromise last year, up from just 16% in 2020. Machine-to-machine identities like service accounts and tokens are a growing factor in that trend, and most mid-market IT teams don't have the visibility to manage them effectively.

What are non-human identities in cybersecurity, and why do they matter?

Non-human identities (NHIs) are digital credentials that let machines, applications, and automated processes authenticate and access resources without human intervention. Service accounts, API keys, managed identities, OAuth tokens, and AI agents all fall under the NHI umbrella.

Their numbers are growing fast. Every cloud resource, CI/CD pipeline, automation workflow, and AI integration creates new NHIs that need credentials and permissions. In most organizations, machine identities outnumber human users by a factor of 10:1 or more.

When your backup software connects to a database at 2 a.m., it doesn't type in a password. It authenticates using a service account with stored credentials. That's an NHI. The same applies to the API key your ticketing system uses to pull CRM data, or the OAuth token syncing employee records to Entra ID.

As Jeff Warren, Chief Product Officer at Netwrix, noted in the 2025 Cybersecurity Trends Report, identity-driven attacks are likely to dominate even more, with "abuse of machine-to-machine identities like service accounts and tokens" among the emerging vectors.

Human identities vs. non-human identities

Human and non-human identities differ in how they're owned, authenticated, managed, and monitored:

• Ownership: Human identities have clear owners. NHIs often have shared or unclear ownership, making accountability difficult to enforce.
• Authentication: Humans use passwords combined with MFA. NHIs use keys, tokens, and certificates, and MFA doesn't apply.
• Lifecycle: Human identities follow HR-driven processes (onboarding, role changes, offboarding). NHIs are created ad hoc by developers and admins, with no equivalent lifecycle management.
• Behavior: Human access is interactive and variable. NHI access is programmatic and repetitive, making anomaly detection both easier to baseline and harder to review at scale.

Password policies, MFA, SSO, and access reviews don't translate cleanly to NHIs. That's why machine identities require their own governance approach.

The related term “machine identity” refers specifically to infrastructure-level identities like servers, VMs, and certificates. NHI is broader, covering those plus application-level credentials like API keys, tokens, and bots.

Non-human identity authentication methods

NHIs authenticate programmatically rather than through interactive login, using four primary methods:

• Token-based: API keys, bearer tokens, and JWT tokens
• Key-based: SSH keys and service account keys
• Certificate-based: X.509 certificates and mutual TLS (mTLS)
• Workload identity federation: Cloud-native mechanisms like AWS IAM roles, Azure managed identities, and GCP service accounts

The critical risk across all four is that MFA and SSO don't apply. When a credential is compromised, there's no second factor to prevent exploitation, and the attacker inherits whatever access that identity holds.

Common types of non-human identities

Understanding the different types of NHIs in your environment is the first step toward managing them effectively. The following categories represent the most common non-human identities you'll encounter across on-premises and cloud environments.

1. Service accounts and application identities

Service accounts are specialized accounts that enable applications to perform tasks without human credentials. Your backup software uses one to access SQL Server databases, and your monitoring tools use them to collect performance data. In AD environments, these are identified by the ServicePrincipalName (SPN) attribute.

The core security challenge is that passwords rarely change. Modern best practice is to migrate to Group Managed Service Accounts (gMSAs), which provide automatic password management through Active Directory and eliminate manual administrator intervention.

Application identities extend this concept to cloud-native environments, where cloud platforms assign dedicated identities to applications to access APIs, databases, and other cloud resources.

2. API keys and secrets

API keys and secrets serve the same basic function: they let one system authenticate to another without a human involved. They're embedded in internal tooling, SaaS integrations, and third-party service connections to grant programmatic access without requiring someone to log in.

That third-party category is broader than most teams realize. When a printer communicates with its manufacturer for supply monitoring, or when manufacturing equipment sends telemetry to an OEM for remote maintenance, those connections rely on API keys or embedded credentials that authenticate across organizational boundaries. These vendor-managed NHIs often fall outside standard identity governance because they're provisioned by the vendor, not by your IT team.

The challenge across all of these is their static nature. Unlike passwords tied to user accounts, API keys don't expire by default in most systems and tend to end up in configuration files, code repositories, environment variables, and even chat logs.

The same is true of secrets stored in vaults or config files, including passwords, connection strings, and encryption keys. These credentials carry the same access risk as any API key but often receive less scrutiny.

Once leaked, any of these credentials is immediately exploitable, and organizations often don't know one has been exposed until it's already been used. When the compromised credential belongs to a third-party integration, the blast radius extends beyond your environment into vendor relationships governed by frameworks like NIS2 and DORA, both of which mandate supply chain risk controls for digital service dependencies.

3. Managed identities

Managed identities represent Microsoft's modern approach to NHI authentication in Azure. System-assigned managed identities tie directly to specific Azure resources and eliminate the need to store credentials entirely. User-assigned managed identities can be shared across multiple resources.

However, managed identities only solve the problem within the Azure ecosystem. Organizations running hybrid environments still need visibility into on-premises service accounts and cross-platform credentials that managed identities don't cover.

4. OAuth tokens

OAuth tokens enable delegated access between applications. When your HR platform syncs employee data to your identity provider, or your reporting tool pulls records from a SaaS CRM, those connections rely on OAuth refresh tokens to maintain persistent access.

These tokens often have longer lifespans than intended and accumulate across your SaaS integrations as teams connect more tools together.

5. Cloud workload and container identities

Workload identities encompass the credentials assigned to containerized applications, serverless functions, and cloud workloads. Your Kubernetes deployments, Azure Container Instances, and AWS Lambda functions all require credentials to access other services.

Cloud platforms assign identities to these workloads, including VMs, containers, serverless functions, and Kubernetes pods, to access cloud resources, storage, and APIs. These workload identities are created and destroyed rapidly, often outpacing security teams' ability to track them.

6. Machine and device identities

Physical and virtual machines, IoT devices, and infrastructure components all carry their own identities. Certificates frequently authenticate these machine identities, creating a layer of NHI governance that overlaps with but extends beyond application-level credentials. As IoT adoption grows, so does this identity population.

7. Bots and AI agents

Bots and AI agents represent the newest and fastest-expanding category of non-human identities. For example:

• Microsoft Copilot needs access to your files and email to be useful
• Robotic process automation (RPA) bots need credentials to interact with business applications
• CI/CD bots need access to deploy code
• Orchestration tools and AI agents operate as non-human identities, often with broad access to enable automation workflows

Each of these creates identity relationships that require the same governance as any other NHI, but they're often provisioned quickly by business teams without security review.

The added risk is that AI tools interact with code repositories and development environments. This can inadvertently expose credentials in prompts, outputs, and logs, creating leak vectors that traditional secret scanning doesn't always catch.

Each of these identity types requires different management approaches, but all share common governance challenges: ownership tracking, credential rotation, and decommissioning when no longer needed.

How to discover non-human identities in your environment

Before you can govern NHIs, you need to find them. A structured discovery process helps you understand the scope of the problem, but most organizations quickly realize that manual approaches only scratch the surface.

Start with your identity provider

Query Active Directory for accounts with Service Principal Names, standalone managed service accounts, and group managed service accounts.

For cloud environments, pull an inventory of service principals, app registrations, and managed identities from your identity provider's admin console. Focus on four attributes for each identity: what application uses it, what credentials it holds, what resources it can access, and who owns it.

Expand to your code and automation layer

Work with your DevOps team to identify credentials stored in CI/CD pipeline configurations, infrastructure-as-code templates, and environment variables. Repository scanning tools can flag hardcoded credentials and API keys committed to version control. This is often where the most untracked NHIs live.

Audit your SaaS integrations

Review OAuth grants and API connections across your SaaS applications. Many organizations discover dozens of active OAuth tokens from integrations that were set up months or years ago by people who've since left the team or the company.

Document what you find

For every NHI you discover, record the owner (a person, not a team), the business justification, the credential type and rotation status, and the last time someone validated it's still needed. This inventory becomes the foundation for everything that follows.

One important caveat: manual discovery gives you a point-in-time snapshot, not a living inventory. Environments change daily, and a quarterly export won't catch the service account someone created last Tuesday.

Continuous, automated discovery is what separates organizations that know their NHI population from those that just think they do.

How to secure and govern non-human identities

Non-human identity management (NHIM) is the practice of discovering, governing, and securing machine identities that traditional IAM and PAM weren't built to handle.

That means governing access without a human actor, managing credentials that can't use MFA, and tracking ownership for identities created by developers and automation rather than HR processes.

Once you've identified what exists in your environment, governance ensures it stays under control. Effective NHI security treats machine identities as first-class citizens in your identity security program, with defined policies for every stage of their lifecycle.

Here's what that looks like in practice:

• Assign an owner to every NHI at creation: No identity should exist without a named individual (not a distribution list, not a team alias) accountable for its access and lifecycle. Make ownership a required field in your provisioning process.
• Enforce least privilege from day one: Grant only the specific permissions each NHI needs for its function, scoped to the narrowest resource level possible. Avoid subscription-wide or domain-wide permissions for service accounts that only need access to a single application.
• Automate credential rotation where possible: gMSAs handle this automatically for on-premises AD workloads. For cloud service principals and API keys, build rotation into your deployment pipelines or use a secrets management solution.

The right cadence depends on credential type and exposure risk, as major frameworks like NIST, CIS, and PCI DSS don't mandate a universal rotation period for privileged accounts.

• Monitor for behavioral anomalies: A service account that suddenly accesses resources outside its normal pattern, or an API key that authenticates from an unfamiliar location, should trigger an alert. Focus monitoring on deviation from established baselines rather than trying to review every event.
• Decommission aggressively: Stale NHIs are one of the most exploitable weaknesses in any environment. Build decommissioning triggers into your process: if an identity hasn't authenticated in 90 days, flag it for review. If the owner can't justify it, disable it. If no one notices for 30 more days, remove it.
• Certify access on a recurring schedule: Require NHI owners to re-validate that each identity still needs its current permissions. Annual reviews are a starting point, but quarterly is better for privileged identities.

These controls map directly to requirements already embedded in major compliance frameworks:

• CMMC Level 2 requires access control and account management for all identities, including non-human ones
• SOC 2 trust service criteria require access controls that extend to non-human identities
• HIPAA mandates audit trails for all access to Protected Health Information, including access by automated processes and service accounts
• NIS2 (EU) requires organizations to manage ICT supply chain risks, including third-party service credentials and vendor-managed identities that access your environment
• DORA (EU financial sector) mandates ICT third-party risk management with specific requirements for monitoring and governing digital service dependencies, including the machine identities that those services use

If you're building NHI governance, you're simultaneously building compliance evidence.

How Netwrix supports non-human identity security

Every governance practice above depends on one thing: knowing what non-human identities exist in your environment and what they're doing. That's the gap most organizations struggle to close on their own, and it's where Netwrix fits in.

The Netwrix 1Secure platform provides continuous visibility into identity posture across Active Directory and cloud environments. For non-human identities specifically, it surfaces inactive accounts, stale accounts, and overly permissive access configurations that violate organizational policy, giving security teams a current-state picture rather than a quarterly snapshot.

Where manual queries give you a point-in-time export, 1Secure maintains an ongoing view as new identities are created and existing ones change.

For Active Directory specifically, Netwrix Auditor tracks changes to service accounts, monitors authentication events, and audits Group Policy modifications, filling the visibility gaps that native tools leave open.

When someone creates a new service account, changes its group membership, or attempts an interactive logon, Auditor flags it. Teams can start answering audit questions about NHI activity with human-readable reports that map directly to compliance frameworks like HIPAA, SOC 2, and CMMC.

For privileged non-human identities that require elevated access, Netwrix Privilege Secure eliminates standing privileges through just-in-time provisioning with full session recording for audit trails. Instead of service accounts holding persistent admin access around the clock, Privilege Secure grants elevated permissions only when needed and revokes them automatically when the task is complete.

Ready to close the visibility gap on non-human identities? Book a demo to see how Netwrix works in your environment.