Non-Human Identities Should Be Part of Your Holistic Identity Strategy

Non-human identities have been quietly multiplying in the enterprise ever since software began its migration into the cloud, but it’s only in the last couple of years that we are truly starting to grapple with the security and governance implications of NHIs. NHIs have been critical in allowing some of the most serious data breaches and ransomware attacks of recent years, leading to a belated realization that the access granted to NHIs needs to be taken just as seriously as the access given to humans.

Unfortunately, Identity teams are now far behind. NHIs now outnumber human identities by as many as 50:1, leaving companies with the task of trying to exponentially scale up their security and governance efforts to accommodate them.

Causes of the NHI explosion

SaaS and IPaaS

With the rise of SaaS, companies weren’t locked into using a few giant on-premise software suites to run their business. Instead we were able to select best-in-class tools for each task and create a highly customizable and scalable stack, unique to the organization.

An important by-product was the new need for all of these tools to integrate and communicate with each other. For example, in a revenue stack, Salesforce might need to access lead data from Hubspot, revenue intelligence from Outreach, transcripts and call summaries from Gong, workflow triggers from Slack and many more. Each of these integrations requires the creation of NHIs. Even more are created for IPaaS and automation platforms to arrange bi-directional data syncing and cross-app workflows. 

The identities created to power integrations often have a high level of access, either to support the broad write actions required for data syncs, or simply because many SaaS apps don’t have the fine-grained entitlement structure that is needed to create tightly-scoped access policies. SaaS integrations can also obscure who is performing an action, as multiple human users can initiate data syncs or other actions using SaaS integrations.

Cloud computing and microservices architecture

Instead of being a single codebase, hosted as one monolithic application, modern cloud software is made up of thousands of smaller processes each individually hosted and independently scalable. This style of architecture has many benefits, but it requires the creation of access credentials for each component, so that they can communicate with each other.

This means that a cloud-based app can include thousands of NHIs, each with their own credentials and a set of entitlements. In theory, permissions for identities used by service accounts should be tightly defined to allow them to perform only the actions they need to perform their limited functions. However, these identities are typically created, owned and managed by developers, not by IAM teams, and have not been subject to the kind of security and governance oversight as human identities.

Agentic AI

Agentic AI tools offer great productivity benefits from their ability to synthesize and summarize data from multiple sources, and act independently to accomplish tasks. However, just like other NHIs, they rely on API connections to apps and data sources to gather information and execute actions. 

A key difference is that Agentic AIs tend to have a less tightly defined purpose, and might be called upon to do many different tasks. For this reason, while other NHIs can be over-permissioned through mistakes or oversight, Agentic AIs tend to be highly privileged by design. Agentic AIs also represent a double threat, either through direct compromise of the credentials they use, or indirectly through “prompt injection” or other techniques where an attacker tricks an AI into acting on their behalf.

NHIs are as vulnerable as human identities

There is little difference in the potential value of human and non-human identities from the perspective of an attacker, who can impersonate a machine as readily as a person. Both rely on credentials that can be compromised, and both have a scope of permissions which may or may not be useful to the attacker. In other words, access is access and permissions are permissions.

However, on top of the vulnerabilities they share with Human identities, NHIs have some additional weaknesses all of their own.

Credential management

It’s always possible (if not as common as we’d like) for a human to simply remember a password, or at least to use a password manager locked to a physical or biometric key. For NHIs, the credentials need to be encoded somewhere, which makes them vulnerable to discovery. Tools like Secrets Managers exist to help manage this, but their use is difficult to enforce and it’s still common for hackers to find API credentials hard-coded into publicly accessible source code. 

Additionally credentials used for integrations often need to be shared outside the organization, leaving you dependent on a third party and with no direct control over how securely they are stored. The 2024 hacks of Snowflake customers demonstrated the risk posed by credentials entrusted to third parties.

Human-centric security design

Human identities can be further secured by additional authentication factors, like SMS codes, digital fobs or biometrics. NHIs typically rely on only a single authentication factor. Additional steps can be taken to secure requests from NHIs, such as accepting requests only from pre-defined IP addresses, but these are difficult to set up at scale and can introduce unacceptable brittleness into critical processes.

Similarly, processes like just-in-time access (JIT) as administered by traditional PAM tools require humans to request access to critical systems through a graphical UI, making it difficult to apply these security measures to NHIs.

Unclear purpose

NHIs are created by humans to serve a particular purpose. But when the creator moves on to other projects or other organizations, that critical context is easily lost, presenting a challenge to security and governance teams. How can you determine if the access granted to an NHI is necessary, if you don’t know what it’s supposed to do? The long-term success and security of NHIs is dependent on consistent ownership and clear documentation, which are often not prioritized by hard-pressed development teams.

Lifecycle 

All the above problems are exacerbated by the unique lifecycle of NHIs. While a new human employee is carefully onboarded from day one with consideration for their access to production data, NHIs typically begin their lives in development or test environments, interacting only with dummy data. At this stage, spending time carefully defining a safe level of access, or setting up an entry in a secrets manager can seem like an unnecessary waste of time for a process that may never even make it to production. 

Later, as a feature nears completion, and deadlines come and go, pressure to ship builds, and there often isn’t time to go back and write a dedicated access policy, or refactor credential management, so overpermissioned and undersecured identities find their way into production where they can be harnessed by attackers.

How to secure NHIs

We’ve seen how attackers can misuse the permissions of NHIs in exactly the same way as human identities. We’ve also seen that NHIs have unique vulnerabilities that need to be addressed. Therefore we need a two-pronged approach to securing NHIs.

NHI-specific posture management

The first and more straight-forward task is to create an NHI-specific posture-management strategy. This strategy must cover the following:

• Discover and catalogue all NHIs across all systems
• Ensure credential strength and enforce best practices, including secret rotation.
• Scan all public and private source code for hard-coded credentials.
• Enforce a standardized process for initializing NHIs and destroying them when they are no longer needed.

Existing tools like Secrets Managers, as well as the emerging category of NHI Management tools, can help you with these tasks.

Roll human and non-human identities into a holistic least-privilege strategy

Secrets managers and NHI management tools help you manage the identities themselves, and to secure them against potential attacks. However, you still need to consider the access these identities have. We prioritize least-privilege for human identities because we assume that they will sometimes be compromised, whatever we do to try and prevent it. The same holds true for non-human identities. While NHIs require their own separate methods of authentication, they do not need a separate system of authorization. NHIs can and should use the same processes as human identities for requesting and receiving access, and be subject to the same level of scrutiny in audits and access reviews to ensure least privilege.

Adapting your identity processes for NHIs

However, your current tools and processes for identity security and governance are already struggling just to manage human identities. They’re simply not built to handle the scale, scope and complexity of NHIs. To successfully create a holistic identity strategy, you’ll need to make improvements in three key areas.

Connectivity

NHIs can’t use the same UI that humans do to request the access they need. To apply modern techniques like just-in-time access (JIT) and time-based access, your identity tools need to take an API-first approach so that NHIs can request and receive access programmatically when they need it.

Metadata

Just as humans in your HR system have a manager, NHIs need to be linked to a human owner who is responsible for maintaining the NHI and understanding the work it does. Your identity system needs to be capable of recording a human owner. You also need to update your human lifecycle management to ensure that, when NHI owners change roles or leave the organization, new owners are assigned.

Scale

This is the big challenge. Most identity governance tools were designed for the on-prem era and are already struggling to cope with the number of apps, and specificity of entitlements that employees use today. Adding in NHIs makes an already difficult problem 20 times larger. This requires you to rethink how you approach identity governance from the ground up.

• Take a risk-based approach to security and governance by harnessing access intelligence and AI tools to identify outliers, risky access and new or altered permissions.
• Automate as many rote processes as possible. For example, establish auto-approval workflows for most access requests, detect and remove unneeded access automatically, automate compilation of access reviews across all your systems, etc.
• Build capacity to make correct access decisions at scale. Focus human effort on defining and improving access policies, and let AI and automated processes handle enforcement.

The Lumos Advantage

The permissions granted to NHIs is their most significant impact on your identity governance and security. While NHIs themselves have unique management and lifecycle requirements, their permissions form part of your holistic identity attack surface and need to be managed as part of that whole. However, this means massively scaling up your identity processes far beyond what legacy tools are capable of. Lumos is the first Autonomous Identity platform, to automatically discover and manage access across all your apps. Lumos applies a four-step framework to applying least privilege at modern scale:

• Perceive - Lumos connects with all systems: on-premise and cloud, SaaS and custom, to give you complete visibility into all identities and their permissions. In addition to capturing federated identities managed by your identity platforms, like Okta and Active Directory, Lumos also captures the local accounts at the app level that are often used by NHIs.
• Analyze - To handle the exponentially increased scale of identity management encompassing NHIs, Lumos provides smart analysis of identities and access to help you triage work and focus on risky, unusual, or altered access.
• Act - Lumos integrates with your apps to directly act on identities and systems to grant needed access, and remove excessive or dangerous access. For example, with Lumos you can:
  
  • Automatically grant requests for most apps to human or machine identities based on access rules.
  • Automatically remove access that isn’t used within a given time period.
  • Implement decisions made in access reviews, like removing rejected access or downgrading identities to a more appropriate permission level.
  • Integrate with ITSMs like Jira and ServiceNow to create audit-ready evidence of access removal for compliance.
• Learn - Lumos uses AI to learn from all of your identity, access and activity data across all systems in order to:
  
  • Suggest ideal birthright access for all identities including NHIs
  • Create adaptive access policies that optimize for least privilege across all systems.

To learn how Lumos can help you scale up your identity processes to encompass NHIs, schedule a personalized demo today.