RSA Thursday | Identity Security Series Issue #13 | Machine & Non-Human Identities: Who Manages Non-Human Identities?

When an employee leaves an organization, the next steps are usually clear. Their user account is disabled. Their access is removed. Their privileges are revoked.

But what about the thousands of identities operating inside the organization that belong to no human at all?

Service accounts, applications, APIs, bots, automation tools, cloud workloads and integrations between systems also access critical resources every day. And they often remain active far longer than human users.

The new question in identity security is no longer just "Which user is accessing the resource?" It is also "Which machine, application or service is accessing it, and why?"

Not Every Identity Is Human

In modern IT environments, systems constantly communicate with one another.

An application connects to a database. An API retrieves data from another service. An automation platform changes the infrastructure. A cloud workload accesses another resource. A service account runs a critical application.

The digital identities used to perform these operations are generally known as Non-Human Identities (NHIs) or Machine Identities. Examples include:

• Service accounts

• Application identities

• API identities

• Bot and automation accounts

• Cloud workload identities

• Container and microservice identities

• Integration accounts connecting different systems

None of these are human. But their access rights are very real.

Invisible Identities, Invisible Risks

One of the biggest challenges with non-human identities is that they can become invisible over time.

A service account may have been created years ago. API access granted for a project may still be active after the project ends. An application account may have more privileges than it needs. An integration may have been removed while its identity or credentials remain in the system.

As a result, the following can accumulate within an organization:

• Accounts with unknown owners

• Unused but active identities

• Overprivileged service accounts

• Credentials that never expire

• Integrations whose creators are unknown

Over time, these can create a significant attack surface.

When Was That Service Account Password Last Changed?

Password policies, MFA and access controls are now standard security practices for human users.

Machine identities are not always managed with the same level of control. Some service accounts may use the same credentials for long periods. API keys may be stored in code. Secrets and tokens may be scattered across systems without proper controls.

More importantly, because these identities often operate in the background, they are less visible than regular user accounts.

Protecting credentials alone is therefore not enough. Organizations need to manage the non-human identity itself and its entire lifecycle.

Machine Identities Need a Lifecycle Too

As with human users, organizations should be able to answer fundamental questions about non-human identities:

• Why was this identity created?

• Which application or service uses it?

• Who owns it?

• Which systems can it access?

• What privileges does it have?

• Is it still needed?

• When was it last used?

A machine identity should remain visible and manageable from creation to removal.

This approach helps prevent forgotten accounts and unnecessary access from becoming lasting security risks.

Least Privilege Is Not Just for People

If an application needs access to one specific database, why should it be able to access every database?

If an automation account needs to perform one specific task, why should it retain broad administrative privileges?

The principle of least privilege applies to machine identities too.

Every service, application or workload should have access only to the resources and privileges required to do its job.

This limits an attacker's room to maneuver even if a machine identity is compromised.

AI and Automation Are Expanding the Challenge

Cloud-native architectures, DevOps, the API economy and automation were already creating large numbers of non-human identities.

AI systems and AI agents are now joining them. An AI agent can connect to applications, access data, make API calls, initiate business processes and, in some cases, perform actions on systems. This raises a new question for identity security:

How do we govern access for digital identities that act on the organization's behalf without a human performing the action?

Identity security strategies must now cover not only employees, but every digital identity capable of acting on the organization's behalf.

The Scope of Identity Security Is Expanding

The identity ecosystem in modern organizations is no longer limited to employees.

People, devices, applications, services, workloads, bots and AI agents all access resources within the same digital ecosystem.

The core principles of identity security must therefore apply to non-human identities as well as human users:

Discover → Identify → Authenticate → Authorize → Monitor → Govern

An attacker does not care whether an account belongs to a person or an application.

What matters is which resources that identity can access.

Key Takeaway

Some of the most critical identities in your organization may not belong to any employee.

Service accounts, APIs, applications, workloads, bots and AI agents access critical systems, often with less visibility than human users.

Modern identity security must answer more than "Who is accessing the resource?" It must also answer: "Human or otherwise, which identity is accessing what, why, and does it still need that access?"

Zero Second | RSA – Identity Security.

RSA Thursday | Identity Security Series Issue #13, prepared by Zero Second.