Who Governs Your NHIs? The Challenge of Defining Ownership in Modern Enterprise IT

"Ownership" is one of the harder concepts to define in the modern enterprise. 

This feels deceptive because, from a personal and human level, ownership is a rather straightforward concept. When you own something as a person, like your car or your house, you control it completely, and you're accountable when things go wrong. Ownership means something fundamentally different for individuals than it does for enterprises, especially when we're talking about non-human identities (NHIs). 

What this looks like in practice is someone on the security team asks, "Who owns this workload and the access it has?" and the answer is crickets and shrugs. Or worse, it becomes a game of hot potato where everyone points to someone else. 

From the security perspective, what we're actually trying to accomplish when we are looking for the owner is shortening the time to remediation by making the lines of communication much clearer. We are not looking for the person to blame; we are looking for the person who can provide the needed context around the workload identity, its secrets, and how revoking access might affect the business. 

The Individual vs. Enterprise Ownership Divide

It's incredibly rare that a single person is ever wholly responsible for anything in the enterprise. This is especially true in the world of NHIs, where the lifecycle of a service account or API key spans multiple teams, processes, and responsibilities.

A developer might create an NHI for their application, but it is probably not the same person who will deploy it to production, manage credential rotation, monitor its usage patterns, or handle security incidents when things go wrong.

That developer isn't going to be on the hook for the security ramifications when that long-lived secret inevitably gets leaked or used by an attacker during a breach. The reality of enterprise software development means responsibility is distributed across teams, not concentrated in individuals.

Two Ways to Think About NHI Ownership

When we talk about assigning ownership to non-human identities, we're really dealing with two different concepts that often get conflated:

The classical and individual level definition of ownership means the "person we can hold accountable." This individual is on the hook for this entity's behavior and any damage from abuse or neglect. It's clean, it's simple, and it's almost never realistic in enterprise environments.

If, though, we reframe ownership to be the subject matter expert, we recognize that ownership really means becoming the person who can answer key questions about an NHI and help the entire enterprise properly manage and govern that identity at scale. If you're looking at ownership from the perspective of being "on the hook", the person to blame when things go wrong, then of course you'd want to run and hide. It makes complete sense that teams, departments, and especially individuals want to avoid outright ownership when it comes to non-human identities.

What we should actually mean by ownership is the person who can answer the basic questions about why this NHI exists, what access it has, how often credentials should be rotated, whether it's being used in a way that could introduce new risks, and whether the credentials have been properly stored or have been leaked.

The Developers' Dilemma

Quite often, the person who can answer most of the questions about an NHI is the developer who created it in the first place. That doesn't mean they're responsible for making sure secrets get rotated, just like they're not responsible for the way cloud service configurations get deployed by the DevOps team.

But they can provide the key insight that security teams need when it's time to solve incidents and put the right governance models around these identities.

Developers have a lot on their plates, though. And there is the reality that developers leave organizations. The person who created that non-human identity might be long gone by the time the security team needs to ask those pertinent questions.

The OWASP NHI Top 10: A Roadmap for What Matters

When we talk about non-human identity governance and security, we're really trying to address the major risk factors that NHIs bring to our organizations. Fortunately, OWASP has given us a roadmap with their Top 10 Non-Human Identity risks for what we should focus on.

Rather than trying to boil all of ownership down to a single person, we can define the set of questions that, if someone can answer them, they can act as the subject matter expert and help align the rest of the enterprise as they work to secure these entities and respond to security incidents.

While there are 10 items on the OWASP NHI list, the most pressing ones that hold the most danger are:

• Is the secret still active?
• Is it securely stored, or has it leaked?
• How is the NHI supposed to behave, and what permissions were granted?
• Why does it exist?
• What are the circumstances we should consider to take it out of service?

Instead of focusing solely on assigning human ownership, we should be working to ensure that the questions we would ask the owner are easily answerable by our tools. This approach makes answers persistent and usable by multiple teams over time and provides consistency across the organization. It does not rely on specific individuals being eternally available or up to speed on how the NHI they created is being used. Ultimately, it scales better than human-dependent processes.

Just as governing an application and all of the NHIs involved is almost never going to be the responsibility of one person, the ideal scenario where a single person can outright own an NHI and be responsible for every aspect is going to be a rare situation.

Focusing on Risk Management, Not Blame Assignment

We need to stay focused on the real task at hand: ensuring that attackers can't easily make use of the access we've given our NHIs. We can't accomplish that by pointing fingers and assigning blame, or by making the leap of faith that just listing someone as the owner somehow makes NHIs easier to manage at scale.

What we need to do is focus on the basics of NHI risk management and ensure that at any given time, we can answer the fundamental questions about compliance with our governance policies.

There's definitely value in assigning an ownership field, though. That person should be able to help you answer questions and fill in the story with human insight that graph data or various data points alone can't provide. 

The real goal should be to minimize risk. That means:

1. Implementing automated governance that can answer basic questions about each NHI's state and compliance
2. Maintaining clear documentation about every NHI's purpose and expected behavior
3. Establishing clear processes for all NHI lifecycle management
4. Creating accountability structures that focus on outcomes rather than blame
5. Building tooling that provides visibility into all NHI permissions and potential blast radius

From Ownership to Assurance

The conversation about ownership often gets stuck on blame. Let's reframe it around assurance. Let's ensure that if a secret exists, no matter where or how it is stored, governance questions can be answered quickly and consistently.  We help teams reduce risks around NHIs, no matter how or when they came into existence, or who put them there.

Let's leverage visibility, context, and workflows to transform ownership from a daunting liability into a structured, scalable governance practice, making ownership accountable. In the modern enterprise, having enough context to act quickly is the foundation of real security.