NHI: Why Service Accounts Have Suddenly Become a Hot Topic

Service accounts have always existed.

Here is one example: almost every Active Directory contains dozens of them. An administrator created them long ago so that a service could access a database. The administrator has since left; the account is still running.

With cloud, APIs, microservices and CI/CD pipelines, a small number of service accounts quickly turned into a very large number. This is where the story of Non-Human Identities (NHIs) begins.

In the past, a service account was a concrete object: a Windows account in Active Directory that executed a service. Someone created it, documented it somewhere and hoped it would never cause problems. That worked because the numbers were manageable. An organisation with 500 employees might have had 50 service accounts – someone knew them all, at least roughly.

Today, the picture looks different. According to current analyses, non-human identities already clearly outnumber human identities in many enterprise environments, sometimes by a wide margin, and continue to grow rapidly.

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

No Excel sheet in the world is built for that, and no administrator can keep track manually. Many classic IAM processes were designed for human lifecycles and quickly reach their limits when NHI volumes rise sharply.

Active Directory was introduced around the year 2000. The underlying identity model was strongly geared towards human users: groups, passwords and logon policies were primarily based on people signing in to enterprise systems.

Service accounts were implemented pragmatically in many companies. When a service had to access other systems or databases without human interaction, administrators often used normal user accounts from Active Directory. They gave them technical names and frequently set “password never expires” so operations would not suddenly grind to a halt.

Microsoft later introduced Managed Service Accounts (MSAs) and Group Managed Service Accounts (gMSAs) – technically much better and with automatic password rotation – but adoption remained limited. In most environments, hundreds of classic domain accounts still run critical services and have not had a password reset in years.

With the shift in IT architecture, the numbers exploded:

• Cloud services brought SaaS models.
• Microservices turned one monolithic application into ten independent services overnight.
• DevOps led to CI/CD pipelines that automatically generate new identities.

Every API call, every integration and every script needs credentials. With the increasing use of AI agents in enterprises, the number of non-human identities is growing even further. Unlike classic automation, agentic AI systems do not just execute tasks rigidly; within defined boundaries they make independent decisions about which systems, APIs or data sources to use.

Analysts describe NHIs as identities for machines, workloads, service accounts and AI agents. Automation, cloud-native architectures and autonomous AI agents massively increase the number and complexity of non-human identities.

At the same time, a Cloud Security Alliance study shows that a relevant share of organisations have not yet systematically recorded or monitored new AI-related identities. This creates additional blind spots in governance, IAM and secrets-management processes.

This is a crucial point that many underestimate. The discussion about NHI security usually revolves around poor governance: accounts are not rotated, rights are not revoked, offboarding is forgotten. All of that is true. But beneath it lies an even more fundamental problem:

A significant proportion of NHIs are not connected to any IAM system and are therefore simply “invisible” to the organisation.

• A developer creates a service account to connect a test workflow. The test goes into production; the account stays. It never appears in the IGA tool or PAM. It exists in a blind spot.
• The same applies to API keys hardcoded directly into applications.
• To OAuth tokens automatically generated by a SaaS tool during integration.
• To CI/CD credentials living in pipeline configurations and never transferred to a secrets manager.

What is not connected cannot be governed. What cannot be governed is not rotated. And what is not rotated remains active, sometimes for years. According to OWASP, secrets often have no meaningful expiry because they are simply never reviewed. This is the starting point for many NHI attacks: an identity that was completely unknown to the IAM system.

• The GitHub Action incident (March 2025): Attackers compromised the widely used GitHub Action tj-actions/changed-files. As a result, sensitive CI/CD secrets could be extracted from thousands of repositories. The incident showed how critical non-human identities and tokens have become in modern development environments: a single compromised access token within an automated CI/CD chain was enough to gain far-reaching access to build and deployment processes.
• The Tata Motors case (2025): Hardcoded credentials in several public applications potentially allowed access to over 70 TB of data. The vulnerabilities had existed for years. The case illustrates a typical problem of modern NHI security: long-lived credentials remaining unnoticed in applications, scripts or integrations.

This exact pattern appears in numerous recent security incidents around machine identities: valid credentials, lack of transparency and identities that were never properly inventoried or controlled.

Traditional IAM systems were built around human behaviour patterns: onboarding via the HR system, role changes when switching departments, offboarding on exit. Working hours, locations and predictable behaviour serve as the baseline for anomaly detection.

NHIs follow none of these patterns. They run around the clock (24/7). They do not appear in any HR database. They have no manager to confirm their access rights in the annual review. The result shows up in three consistent gaps:

1. Missing ownership: Many organisations do not track the creation of new AI-related identities at all. What is not recorded is not owned. What is not owned is not maintained.
2. Default over-privileging: A large proportion of all NHIs have far more rights than they need for their actual function. This is a massive governance problem, because technical accounts are often granted admin rights as a blanket solution.
3. No offboarding: A microservice is shut down, but its API key stays active. A developer leaves the company, but their personal access token keeps running. Improper offboarding is one of the biggest NHI risks.

• 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.