How to Secure Non-Human Identity Security
Learn how to discover, manage, and secure non-human identities across your hybrid Microsoft and cloud environments
Explore the chapters:
Next Chapter >
Stop AD Threats As They Happen
Cayosoft Protector provides continuous monitoring and real-time alerts across your entire Microsoft Identity stack
Like This Article?
Subscribe to our LinkedIn Newsletter to receive more educational content
Modern infrastructures consist of cloud-native architectures, microservices, automated pipelines, and AI agents. As organizations decompose monolithic and homogeneous systems into these decoupled, highly automated, and heterogeneous components, every new component, like service, container, and workflow, requires its own programmatic identity to communicate, leading to an exponential surge in non-human identities (NHIs) across the hybrid enterprise.
From a security perspective, new attack surfaces are emerging around these non-human identities, which now outnumber human identities by a large margin. As NHIs authenticate non-interactively, the controls that are tied to human identity security—such as MFA and phishing-resistant credentials—do not apply to them, making them a significant security risk.
This article provides actionable best practices for discovering, managing, and securing non-human identities across your hybrid Microsoft Active Directory, Microsoft Entra ID, and cloud workload environments for a secure machine and AI ecosystem.
Summary of NHI security best practices
| Best practice | Description |
|---|---|
| Set up automated discovery and continuous inventory | Eliminate NHI blind spots through continuous, real-time cataloging of all service accounts, app registrations, API keys, and autonomous AI agents across your hybrid Microsoft environment. Audit new and orphaned identities to prevent shadow automation. |
| Implement least privileged access | Confine NHI permissions to their precise operational boundary by avoiding default, wildcard, or broad tenant-wide permissions. |
| Emphasize human ownership and periodic access reviews | Prevent orphan sprawl by associating NHIs with a human mandating valid ownership and enforcing regular certification reviews along with automated deprovisioning. |
| Enforce short-lived and ephemeral identities | Replace static passwords and persistent client secrets with dynamic, short-lived tokens. Connect external systems using OIDC workload identity federation, use system-assigned managed identities for cloud workloads, and leverage group managed service accounts (gMSAs) for passwordless directory execution. |
| Use a secrets management system for the lifecycle | Automate the lifecycle of static secrets, database connection strings, and legacy service tokens. Centralize secrets in encrypted key vaults (such as Azure Key Vault), restrict access exclusively via managed identities, and enforce programmatic rotation with hard expiration limits. |
| Establish continuous monitoring and behavioral analysis | Track and contain compromised machine accounts or rogue AI agents in real time by establishing behavioral baselines for API call velocities, source IP ranges, and location patterns. Stream workload logs to SIEM/XDR platforms, alert on anomalous activity, and enable one-click automated rollbacks to instantly reverse unauthorized changes. |
Learn how ITDR must evolve to account for non-human identities (NHI)
Demystifying non-human identities
A non–human identity (NHI) is a programmatic digital identity used by systems rather than directly by humans, like software, automated pipelines, cloud services, and most recently AI engines and agents. NHIs are used to authenticate, authorize, and interact with other systems, infrastructure, and data without a human in the loop. While a human user proves an identity using passwords, hardware or software tokens, or MFA, an NHI uses cryptographic credentials to prove its identity to an identity provider or directory. It may also use federated access, which is a best practice, or access tokens.
NHIs are a common sprawl in modern cloud and cloud-native architectures, forming the connective tissue of a hybrid digital ecosystem. They are used to execute continuous integration and continuous deployment (CI/CD) pipelines, orchestrate containerized microservices in Kubernetes, execute database queries, synchronize data between multiple systems such as SaaS platforms, and, more recently, enable AI workflows and agents to call tools and APIs. Research from authoritative security organizations like the Cloud Security Alliance (CSA) suggests that NHIs outnumber human identities by a ratio of 45:1 in typical enterprise environments, and that number could be much higher in cloud-native environments. And they operate with less security oversight and far higher privileges than human accounts.
Understanding the NHI taxonomy is important to effectively govern them across the technology landscape. The following are common NHIs:
- Service accounts: These are similar to user accounts, are usually manually provisioned, and are commonly found in traditional on-premises and legacy hybrid environments such as Active Directory. They are used by scheduled tasks, background services, and line-of-business applications. Examples include running SQL Server agent jobs, local backup tools, or executing automated Windows services. Service accounts authenticate using static passwords or Kerberos tickets.
- Service principals: These act as digital identities for applications or automated workflows, allowing them to authenticate, access, and manage cloud resources. A service principal is created within an Entra ID tenant and contains permissions that define how it interacts with resources. For example, an external observability platform performs an automated resizing action on a VM. Service principals use client secrets or X.509 certificates for authentication.
- Managed identities (cloud): A managed identity is a special type of service principal whose lifecycle is managed by the cloud provider. For example, in Azure, a VM can have a managed identity that allows it to access other resources, such as Azure Storage. Managed identities can be system-assigned, in which case their lifecycle is tied to the resource lifecycle, or user-assigned, in which case they can live beyond the resource’s lifecycle.
- API keys: These are static, symmetric, unencrypted passcodes used for simple machine-to-machine integrations or direct API access. They lack separate authentication and authorization.
- OAuth and OpenID Connect (OIDC) tokens: OAuth is an authorization framework that determines what resources can be accessed, while OIDC is the authentication layer built on top of it that verifies the identity. These tokens, such as JSON Web Tokens, are dynamic and provide time-bound authorization grants issued by an identity provider like Microsoft Entra. They enable workload identity federation, allowing external tools such as GitHub Actions to perform secure operations on Azure resources in a CI/CD pipeline.
- Machine certificates (X.509/mTLS): These NHIs use asymmetric public-key infrastructure (PKI) to establish cryptographic identities. Both the client and the server present a certificate signed by a trusted CA, performing mutual TLS. Communication between a mobile or IoT device and a backend is an example of where such identities are used.
- Agent identities: This is a rapidly growing class of NHIs that reason autonomously, select tools, make API calls dynamically, and interact across multi-agent networks, thereby dynamically creating agent identities for these operations. Microsoft introduced Microsoft Entra Agent ID, which comprises purpose-built agent identities and agent identity blueprints that provide unique identity boundary templates for autonomous agents, enforcing federated authentication and tool-call-level auditing rather than relying on repurposed service accounts.
The following image shows a snapshot of the different types of NHIs.
NHI security challenges
The challenges associated with NHI security stem from the massive scale of creation, overprivileged access, long-lived tokens, and poor lifecycle management. NHIs can be found embedded throughout a modern hybrid enterprise infrastructure, from CI/CD pipelines and build runners to multi-cloud architectures, SaaS integrations, and AI agents, making them even more difficult to secure. Since these machine identities do not follow an onboarding and offboarding process like human identities do, they proliferate silently, operating at speeds and volumes that overwhelm traditional security management. The following paragraphs highlight these security challenges.
Once applications or pipelines reach a stable production state, the engineering teams are then reluctant to change or rotate these static identities, fearing unexpected outages or broken operational dependencies, so these client secrets or API keys end up unchanged for a long time. Typically, they also do not have an expiry date, becoming long-lived credentials that are primary targets for automated secret-scanning attacks. Additionally, if these machine identities were not centrally managed through a vault, they could end up in source repositories, environment files, or local developer workstations.
It is also common for these machine identities to have broad permissions assigned during setup or troubleshooting to avoid authentication failures and repeated permission assignments as the scope changes. Simply put, the machine identities are overprivileged due to assumptions. And since NHIs are traditionally not access-reviewed like user accounts, privilege creep goes undetected until a compromise occurs.
Another challenge is distinguishing compromised machine identities used for malicious activities from those used for legitimate operations.
The OWASP Non-Human Identities Top 10 lists the most critical risks associated with NHIs and can serve as a starting point for a security framework to identify, prioritize, and take steps to improve the overall NHI security posture.
Non-human identity security best practices
Managing and mitigating NHI risk requires building a continuous, automated, and policy-driven security framework. It requires architectural guardrails such as automated discovery, dynamic trust boundaries, the principle of least privilege, and the embedding of cryptographic controls in your directory and deployment layers. The following best practices outline how to do so.
Set up automated discovery and continuous inventory
You cannot protect NHIs if you do not know they exist. Hence, discovery and inventory are foundational for visibility into the machine and AI footprint of your hybrid identity infrastructure, especially the unknown ones.
Common operational gaps that are often observed around discovery and cataloging are:
- Shadow developer integrations resulting from app registrations, static client secrets, and personal API keys provisioned for development or testing.
- Unaccounted and shadow automation pipelines from ad hoc or local scripts or scheduled tasks using machine identities.
- Orphaned migration identities, such as legacy service accounts left enabled with default/higher privileges after migration activities.
- Unrestricted user consent resulting in unmonitored Entra ID app registrations and untracked OAuth permission grants.
- High velocity and high numbers of NHIs created posing challenges to manually discovering and cataloging them.
Through automated discovery feeds and continuous inventory across the hybrid identity infrastructure spanning Microsoft Entra ID, Active Directory, and others, you can maintain real-time visibility into NHIs, including their permissions, sources, owners, and status.
Your implementation strategies should include:
- Restricting manual NHI creation and enforcing infrastructure-as-code (IaC) provisioning through Azure Bicep templates or Terraform.
- Enforcing mandatory tags that help identify the owner, environment, workload, and validity of the NHI.
- Restricting self-service user-level app consent and routing integrations to a consent workflow that requires business justification, review, and approval.
- Automating continuous discovery and inventory of machine identities using tools such as the Microsoft Agent Registry for AI agents, the Entra Workload ID Portal for enterprise apps and managed identities, and the Microsoft Defender portal for cross-platform NHI visibility.
The Identity Inventory section in the Microsoft Defender portal displays and lets you investigate non-human identities across different platforms (currently in Preview), as shown in the image below.
Read about Microsoft 365 E7 licensing and the rise of agent identities
Implement least privileged access
Least privileged access is the policy engine that restricts non-human identities to their exact functional boundaries. Without it, a single compromised service principal, managed identity, or AI agent credential can grant sweeping lateral movement to a malicious actor, turning an isolated breach into a tenant-wide compromise. Common gaps in access provisioning include granting high-privilege application permissions (such as Directory.ReadWrite.All or RoleManagement.ReadWrite.Directory) to Entra ID app registrations, using default domain admin service accounts for on-premises Active Directory automation, and sharing a single managed identity across multiple distinct application contexts or AI agents. Each gap is a potential vulnerability for an attacker.
Least privilege access allows Microsoft Entra ID and Active Directory environments to restrict the blast radius of any machine entity, ensuring that automated systems interact only with specific enterprise applications, Graph API endpoints, or organizational units required to execute their immediate tasks.
Here are some of the most effective least privilege access strategies to implement:
- Strip away broad tenant-wide permissions and enforce application permissions that target precise resource scopes.
- Decouple shared machine contexts into isolated, workload-specific identities, such as assigning a dedicated system-assigned managed identity to each Azure workload with zero sharing.
- Replace broad wildcard assignments with granular, resource-scoped roles. Use Entra ID custom roles or administrative units to restrict the operational boundaries of automation.
- Strip all permanent global administrative directory roles from machine accounts, and convert broad application permissions into delegated permissions where the user context is available.
The following screenshot shows an example of an app registration for a GitHub Actions pipeline that uses the least privilege approach by assigning narrow Microsoft Graph application permissions with explicit admin consent.
Emphasize human ownership and periodic access reviews
Human ownership and periodic access reviews establish the governance loop that prevents non-human identities (NHIs) from turning into permanent, unmonitored backdoors. Without this, machine credentials, application registrations, and autonomous AI agents lack active ownership, lifecycle governance, or ongoing operational justification, long outliving the projects, developers, or vendors that created them. Gaps here include:
- Orphan sprawl, where the employee who created an enterprise app registration or service account departs the company without transferring administrative ownership, leaving the identity unmanaged.
- Running access reviews solely for human users while leaving highly privileged machine entities completely unreviewed. Each orphaned or unreviewed NHI represents a silent path that threat actors can compromise to gain persistent access.
Human ownership helps your organization bind programmatic identities to designated internal owners and requires that their entitlements be continuously attested, ensuring that permissions are explicitly validated or revoked based on current business requirements.
The most effective strategy to implement is to first mandate a valid human-owner attribute for every newly provisioned machine identity. You can implement this by enforcing a strict directory policy that requires at least one active, non-administrative human owner or engineering group to be assigned to every Entra ID app registration and Active Directory service account.
The following screenshot shows a GitHub Actions machine identity with a human owner:
Your next strategy should consider running automated quarterly attestation campaigns for all service principals and then disabling entities that fail to achieve explicit human ownership through re-certification. You will generally automate the lifecycle of these machine roles by mapping them to scheduled access review campaigns within your identity governance platform. If an owner leaves the organization or an AI agent completes its operational mandate, the directory governance engine must flag the identity for immediate reassignment or secure deprovisioning.
Respond Instantly to Identity Threats
Monitor AD for unwanted changes – detect for security or critical functions
Recover global enterprise-wide Active Directory forests in minutes, not days
Use a single tool to administer and secure AD, Entra ID, and Microsoft 365
Enforce short-lived and ephemeral identities
Developers generally end up embedding static and long-lived identities such as text-based keys into code repositories, build systems, and AI models, leaving secrets highly vulnerable to source code leaks, accidental log exposure, or interception. Common examples include using static client secrets valid for one or more years in CI/CD pipelines, hardcoding Active Directory service account passwords in plain-text script files, and granting permanent API keys to AI agents interacting with internal line-of-business applications. Each long-lived secret is a ticking time bomb.
With ephemeral identities, your environment utilizes dynamic, short-lived tokens that automatically expire within minutes or hours, dramatically minimizing the window of opportunity for an attacker if a credential is leaked.
Examples of effective strategies to enforce short-lived and ephemeral identities for NHIs include one or more of the following:
- Start by shifting to workload identity federation using authentication protocols such as OpenID Connect (OIDC) and cloud-native solutions like Microsoft Entra Identity Federation. This will allow workloads to authenticate directly against a centralized IdP using cryptographically signed, short-lived tokens, bypassing the need to store secrets in your code or environment variables. For example, transition external systems such as GitHub Actions or GitLab CI to use Entra ID Workload Identity Federation, ensuring that they swap OIDC tokens for short-lived Entra access tokens on demand.
- Adopt Azure managed identities for all cloud-native compute workloads to avoid generating long-term secrets. Implement this by enforcing system-assigned managed identities for all internal Azure VMs, app services, and containerized applications, completely stripping static strings from your application configuration files.
- You can take this further by coupling NHIs directly to workload lifecycles. This ensures that they are cleaned up after infrastructure teardown.
- Ensure that the ephemeral identities, though short-lived, have the least privileges required to complete a job, along with zero-trust network access to limit where the identity can travel, so it cannot fan out across other ecosystems if compromised.
The following example shows a federated credential for GitHub Actions that deploys Azure resources and does not use a static password or client secret; it uses OIDC.
Watch our recorded & upcoming educational webinars about identity protection
Use a secrets management system for the lifecycle
Not all NHIs can be dynamic and ephemeral. Certain microservices or AI applications may interface with legacy systems that do not support modern identity federation, in which case they use static credentials. Common gaps that are seen regarding the use of static secrets include:
- Failing to rotate secrets because teams fear breaking production applications
- Storing passwords in unencrypted environment variables
- Lacking audit visibility into which service or AI model actually requested a specific API token
For such scenarios, you must implement a hardened vault to inject, rotate, and securely store those credentials. A centralized secrets management system functions as this cryptographic vault for storing and rotating static NHIs, helping identity administrators control their lifecycle. Without it, secrets end up scattered across configuration files, environment variables, and unsecured local registries. A secret management system ensures that every secret is encrypted at rest, restricted by granular access control lists, and automatically cycled on a programmatic schedule. Each unmanaged secret represents a high-risk blind spot.
Follow these effective strategies:
- Consolidate all application strings into a central vault (such as Azure Key Vault or HashiCorp Vault), enforcing automated programmatic rotation for non-federated keys and isolating secret access permissions using strict identity-based access controls.
- Store all necessary database strings, third-party API keys, and legacy passwords in a dedicated Azure Key Vault, grant access exclusively via Azure Managed Identities, and enable native automated key rotation.
- Set strict secret expiration limits and configure automated alerts to trigger when a credential enters its final 30 days of lifecycle validity.
Establish continuous monitoring and behavioral analysis
Continuous monitoring and behavioral analysis form the real-time detection engine that alerts your security team when a machine identity or an autonomous AI agent is compromised. NHIs execute automated programmatic tasks at extreme speeds and across vast datasets, making traditional security approaches designed for human identities fail. Common gaps include:
- Treating machine log data identically to human user traffic
- Ignoring high-volume read operations executed by AI agents under the assumption that they are authorized
- Lacking real-time detection for rapid permission adjustments
Through continuous monitoring and behavioral analysis, your system establishes a baseline of normal operation for each service principal, tracking variables such as source IP ranges, geographic location patterns, and typical API call rates, enabling it to immediately flag and contain anomalous activity.
Effective strategies for implementing continuous monitoring and behavioral analysis begin by segregating NHI sign-in logs into a dedicated detection pipeline, configuring automated alerts for anomalous sign-ins (such as unexpected IP addresses or anomalous travel), and leveraging continuous identity monitoring to track permission changes in real time.
Next, enable Microsoft Entra ID Protection policies specifically targeted at workload identities, routing all ServicePrincipalSignInLogs and ManagedIdentitySignInLogs into a centralized SIEM or XDR platform. Configure immediate block or alert actions for any machine identity that exhibits high-risk behavior or triggers an atypical geographic location warning.
NHI security management using Cayosoft
The Cayosoft Guardian Platform treats NHIs like service accounts, service principals, and AI agents as first-class identities, continuously scanning directory changes to provide real-time visibility into the NHI footprint across your Microsoft hybrid identity stack. Its unified governance, monitoring, and recovery platform addresses several key NHI security challenges by providing real-time discovery and orphan detection across AD and Entra ID, uncovering unmonitored app registrations, stale service accounts, and shadow AI integrations before they can be exploited.
To combat default over-privileged identities and scope creep, Cayosoft tracks permission modifications for users and groups in real time, issuing immediate alerts on unauthorized changes and role elevations. It enforces strict least-privilege governance by pairing pre-hardened provisioning templates with automated group attestation workflows that also require human owners to routinely certify that an NHI still requires its assigned permissions. Furthermore, Cayosoft eliminates the risks of static, long-lived passwords by natively supporting group managed service accounts (gMSAs), enabling directory management jobs to run without elevated privileges.
Cayosoft Guardian Audit & Restore extends this NHI management and posture control by closing the gap between detection and response. It continuously monitors for directory-level changes, delivers real-time alerts, and provides automated one-click rollback in the event of unexpected behavior or changes caused by a non-human identity compromised by an attacker. This restores your identity mesh to its verified, hardened baseline in seconds without causing operational outages or requiring complex backup comparisons.
| Platform | Admin Features | Single Console for Hybrid (On-prem AD, Entra ID, M365, Teams) |
Change Monitoring/Auditing | User Governance (Roles Rules, Automation) |
Forest Recovery in Minutes |
| Microsoft AD Native Tools | ✓ | ||||
| Microsoft AD + Cayosoft | ✓ | ✓ | ✓ | ✓ | ✓ |
Conclusion
Non-human identities constitute a major part of the modern enterprise identity perimeter, outgrowing human identities by a wide margin. Securing them requires replacing static, unmonitored credentials with continuous governance, ephemeral trust, and strict least-privilege boundaries without adding friction to developer workflows or slowing innovation. As cloud-native workloads, microservices, and autonomous AI agents continue to proliferate, machine entities should be subject to the same rigorous lifecycle controls as human users—this is the most reliable way to prevent a secret leak from an isolated system from becoming a tenant-wide compromise.
Implementing this means removing default and broad privileges for NHIs across the hybrid identity infrastructure. When NHIs authenticate using short-lived identities, their permissions remain within defined boundaries, making them less appealing to a threat actor in the event of a compromise. It also requires continuous, automated monitoring and alerting for anomalies, such as permission changes.
To know more about how Cayosoft can help your enterprise with integrated, automated discovery and drift recovery, book a demo here.
Stop AD Threats As They Happen
Cayosoft Protector provides continuous monitoring and real-time alerts across your entire Microsoft Identity stack
Like This Article?
Subscribe to our LinkedIn Newsletter to receive more educational content