Service accounts have always existed.

Here's an example: There are quite a few of them in every Active Directory. A system administrator created them long ago so that a service could access a database. The sysadmin is long gone, but the account is still active.

Then came the cloud, APIs, microservices, and CI/CD pipelines, and what started as just a few service accounts quickly multiplied. That’s exactly where the story of Non-Human Identities (NHIs) begins.

 

What has changed and why volume is the problem

In the past, a service account was a concrete entity: a Windows account in Active Directory that ran a service. Someone created it, documented it somewhere (maybe in an Excel spreadsheet?), and hoped it would never cause any problems. That worked because the numbers were manageable. An organization with 500 employees might have had 50 service accounts. Someone knew them all, at least roughly.

Today, the situation is different. According to Entro Security, non-human identities significantly outnumber human ones in many enterprise environments—in some cases by a factor of several times—and continue to grow rapidly (H1 2025).

The new reality:500 employees, but tens of thousands of NHIs.

No Excel spreadsheet in the world is designed for this, and no sysadmin can keep track of it manually. Many traditional IAM (Identity and Access Management) processes were designed for human lifecycles and quickly reach their limits when faced with this rapidly growing volume of NHI data.

 

How it all came about: A brief history

Active Directory was introduced around the year 2000. At the time, the underlying identity model was heavily geared toward human users: groups, passwords, and login policies were primarily designed to accommodate people logging into corporate systems.

Service accounts have been implemented pragmatically in many companies. When a service needed to access other systems or databases without human interaction, administrators often used standard user accounts from Active Directory. They assigned technical names and frequently enabled the “Password never expires” setting to prevent operations from suddenly grinding to a halt due to an expired password.

Although Microsoft later introduced Managed Service Accounts (MSAs)and Group Managed Service Accounts (gMSAs)—which are technically far superior and feature automatic password rotation—adoption remained limited. In most environments, there are still hundreds of traditional domain accounts running critical services that haven’t had their passwords reset in years.

As IT architecture evolved, the numbers skyrocketed:

• Cloud servicesgave rise to SaaS models.
• Microservicessuddenly turned a monolithic application into ten independent services.
• DevOpsled to CI/CD pipelines that generate new identities fully automatically.

Every API call, every integration, and every script requires credentials. With the increasing use of AI agents in businesses, the number of non-human identities is now growing even further. Unlike traditional automation, agent-based AI systems do not merely execute tasks in a rigid manner; instead, they make independent decisions—within defined limits—about which systems, APIs, or data sources to use.

KuppingerCole defines NHIs as identities for machines, workloads, service accounts, and AI agents. The advisory note notes that automation, cloud-native architectures, and autonomous AI agents are increasing the number and complexity of non-human identities.

At the same time, a 2026 study by the Cloud Security Alliance (CSA) shows that a significant proportion of companies have not yet systematically tracked or monitored new AI-related identities. More than 16% of the organizations surveyed stated that they do not adequately track AI-related identities. This creates additional blind spots in governance, IAM, and secrets management processes.

 

The real problem: They aren't connected in the first place

This is a crucial point that many people underestimate. The discussion about NHI security usually revolves around poor governance: accounts aren’t rotated, permissions aren’t revoked, and offboarding is overlooked. All of that is true. But underlying it all is an even more fundamental problem:

 

A significant portion of NHIs are not integrated into any IAM system and are therefore simply “invisible” to the company.

• A service account is created by a developer to integrate a test workflow. Once the test goes live, the account remains. It never appears in OIM, the IGA tool, or PAM. It exists in a blind spot.
• The same applies to API keys that are hardcoded directly into applications.
• For OAuth tokens automatically generated by a SaaS tool during integration.
• For CI/CD credentials that are stored in pipeline configurations and have never been moved to a Secrets Manager.

What isn’t connected cannot begoverned. What cannot be governed is not rotated. And what isn’t rotated remains active, sometimes for years, sometimes for over a decade. According to OWASP, secrets often exist without meaningful expiration dates because they are simply never checked. This is the starting point for numerous NHI attacks: an identity that was completely unknown to the IAM system.

 

What this means in practice: Real-life incidents

• The GitHub Actions Incident (March 2025): Attackers compromised the widely used GitHub Action tj-actions/changed-files (CVE-2025-30066). This allowed sensitive CI/CD secrets to be extracted from thousands of repositories. According to security analyses, more than 23,000 projects were affected. The incident highlighted just how critical non-human identities and tokens have become in modern development environments: a single compromised access token within an automated CI/CD pipeline was enough to gain extensive access to build and deployment processes.
• The Tata Motors Case (made public in 2025):In October 2025, a security researcher published an analysis of Tata Motors: Hard-coded credentials in several public applications allowed potential access to over 70 TB of data, including customer data, invoices, and internal reports. The vulnerabilities had existed since 2023. The case highlights a typical problem with modern NHI security: long-lived credentials that remain unnoticed in applications, scripts, or integrations.

This exact pattern is evident in numerous recent security incidents involving machine identities: valid credentials, a lack of transparency, and identities that have never been properly inventoried or controlled. The “2026 NHI Reality Report”now describes this combination of lack of visibility, overprivileged access, and lack of rotation as one of the key risks in modern cloud and automation environments.

 

Why traditional IAM doesn't work here

Traditional IAM systems were designed around human behavior patterns: onboarding through the HR system, role changes when switching departments, and offboarding when an employee leaves. In addition, working hours, locations, and predictable behavior serve as a baseline for anomaly detection.

NHIs do not follow any of these patterns. They operate around the clock (24/7). They do not appear in any HR database. They do not have a supervisor who confirms their access rights during the annual review. The result is evident in three consistent gaps:

1. Lack of Ownership:Many organizations do not track the creation of new AI-related identities at all (Cloud Security Alliance, 2026). What is not tracked is not accounted for. What is not accounted for is not maintained.
2. Excessive Privileges by Default:The vast majority of NHIs have far more privileges than they need to perform their actual functions. This is a major governance issue, because—true to the adage “When in doubt, it’s better to grant too many privileges”—technical accounts are often granted admin privileges across the board.
3. No offboarding:A microservice is shut down, but its API key remains active. A developer leaves the company, but their personal access token continues to function. According to OWASP, improper offboarding is one of the biggest NHI risks.

 

“Many companies treat service accounts like a hotel where all the room keys are just left out in the open at the front desk.
You just grab one that works and hope nothing goes wrong.”

 

What companies can do right now

• First, let’s take stock:You can’t protect what you don’t know about. The first step is always a comprehensive inventory: Which NHIs actually exist in Active Directory, in the cloud, in SaaS integrations, and in CI/CD pipelines?
• Defining ownership:Every NHI needs a designated person in charge—a specific individual or role responsible for rotation, authorization reviews, and final decommissioning.
• Enforce the principle of least privilege:Each identity should be granted only the rights that are strictly necessary for its specific task.
• Automate the lifecycle:Automatic detection of new NHIs, regular automated rotation of secrets, and automatic offboarding when a service is shut down must become standard practice.

You can also find more information on our service page about NHI management.

 

We offer two starting points, depending on how far along you are.

NHI Assessment
We conduct a structured analysis of your environment: What non-human identities exist in Active Directory, the cloud, SaaS integrations, and CI/CD pipelines? Who is responsible? Where are the critical gaps?

The result: a clear overview of your NHI portfolio, complete with prioritized recommendations for action.

NHI Workshop: "
" Together, we’ll explore what’s already in place in your community, where governance is lacking, and what realistic next steps can be taken. No prior knowledge is required: We’ll meet you where you are right now.

Result: Clarity about your current situation and a concrete roadmap for your business.

Request an initial consultation →