Non-Human Identities (NHIs) Research

In 2025, Rubrik had launched its first identity-protection products for human identities, but anecdotes from earlier user interviews kept pointing at a second, less-examined risk: non-human identities (NHIs). The product manager needed evidence to justify investing in this space, so I launched a study to answer two questions: how big a problem are NHIs? — and what could Rubrik actually do about it? As the sole researcher, I sat on the strategic team alongside product, helping shape both the direction and the strategy for how Rubrik approached NHI data protection.

Research Methodology

NHIs were an evolving space at the time, with no clean ownership boundary across roles so I recruited based on responsibility, not title. In total, I ran 10 user interviews: two internal employees who own NHI risk at Rubrik (a Staff Security Identity Engineer and a Threat Hunting & Detection Engineer), and eight external users across IT/Cloud and Security/Compliance functions, at companies ranging from large enterprises to mid-sized businesses.

Answering the Core Questions

What do users actually consider an NHI?

Users understand the term "non-human identity" but often use the umbrella term "service account" instead. In practice, they define an NHI as two things together: an entity that lets applications talk to each other without a human in the loop (service principals, managed identities, agents, certificates), and the secrets tied to it (passwords, keys, tokens).

Users don't rank NHI types by what they are — they rank them by risk level. The more connections and privileges an NHI has into critical applications, the larger its attack surface, and the more urgently it needs attention.

How big a problem are NHIs, really?

Two forces are pushing NHIs to the top of the priority list:

Cloud adoption — more API usage, and NHIs increasingly created in a decentralized way, beyond any single team's view
AI adoption — more agents deployed across systems means more privileged NHIs, full stop

And three things are compounding how overwhelmed users feel about it:

Lack of visibility — NHIs often get created without an approval process, or spin up automatically from a workflow, with API secrets shared around with no other team the wiser. The result is a sprawl of unknown, untracked entities that's challenging for IAM or Security teams to understand, much less manage.
No centralized inventory — especially painful for companies migrating legacy infrastructure to the cloud, trying to get one view of all their NHIs and what they own. Without knowing who owns an NHI and what it can touch, they can't act on it responsibly.
Lifecycle management — tracking creation, rotating secrets, and decommissioning are all tasks that require manual work in large volumes

Using Frameworks to Communicate Insights

Because this was a large, abstract space, I opted for creating simple frameworks to make the findings land clearly with stakeholders.

Hierarchy of NHI needs

Almost every issue people raised traced back to one root cause: no centralized inventory of their NHIs. Even the users who felt they had a decent handle on their NHIs still struggled to manage them. Some of them were worried about NHIs holding more permissions than they should, and given the sheer volume of NHIs, everyone wanted intelligent tooling to catch issues early and automate the fix.

Three-tier pyramid: Centralized Inventory at the base, Lifecycle Management & Governance in the middle, Posture Management & Remediation at the top, each with supporting bullet points. — FIG. 01The hierarchy of NHI needs — centralized inventory as the non-negotiable foundation everything else builds on.

How Rubrik can help

Using that same pyramid, I mapped where Rubrik could realistically address each level. As we discussed Rubrik's right ot play, this led the team to realize that a centralized inventory is table-stakes but even though it was necessary, it wouldn't be where Rubrik would stand out amongst competitors. The real opportunity for most customers at this stage of their NHI journey, was Lifecycle Management & Governance.

The same three-tier pyramid annotated with how Rubrik could address each level: understanding what's out there, operationalizing processes and enforcing policies, and proactively discovering and mitigating risk. — FIG. 02Mapping Rubrik's potential role onto the same hierarchy — and finding the layer worth building first.

User Need Insights

For each need, I explained why it was a real frustration today, what it looks like inside a user's environment, and showed real user frustrations involving dealing with NHIs.

Slide on discovering and inventorying NHIs, listing desired metadata — Owner, Last Accessed/Frequency of Usage, and Permissions/API calls/Associated Applications — with reasoning for each. — FIG. 03Discovering & inventorying NHIs — what metadata users actually need to evaluate risk.

Slide on over-privileged and highly privileged NHIs, describing how legacy NHIs are often created with excess permissions and how all-or-nothing permission models leave users no real control. — FIG. 04Over-privileged & highly-privileged NHIs — legacy sprawl meets all-or-nothing permission models.

Slide on cleaning up stale NHIs, with a quote describing a company manually working through 20,000 unidentified on-prem accounts out of 160,000 total. — FIG. 05Cleaning up stale NHIs — a manual, never-ending chore with real risk attached.

Slide on leaking secrets, citing a real incident where a leaked service account credential led to a hospital site being fully encrypted, prompting investment in a third-party secrets vault. — FIG. 06Leaking secrets — when a credential in code becomes a real incident.

Slide on NHI anomaly detection, explaining that traditional behavioral signals don't map cleanly onto NHIs and that a robust behavior model is needed to filter out false positives. — FIG. 07NHI anomaly detection — why human-behavior models don't transfer cleanly to machines.

Slide on remediation for NHIs, distinguishing proactive remediation (periodic review) from reactive remediation, and noting fear of business disruption as a real deterrent to locking down a compromised NHI. — FIG. 08Remediation for NHIs — and the very real fear of breaking something critical by acting on one.

"It's the people that set up the account [...] they had a way of doing it just because it worked at the time and they didn't realize what they were doing [...] it's just the age-old problem of human error — it's funny, it's about NHIs, but humans are our biggest risk." Security & Compliance interview participant

Top Emerging Themes & Opportunities

I closed the report with a summary of every user need uncovered, how significant a concern it was, and whether Rubrik genuinely had a right to play in that space — rather than just a reason to.

Summary table of five user needs — Centralized NHI Inventory, Identifying Stale NHIs, Identifying Highly and Over-Privileged NHIs, Proactive Secrets Management, and NHI Anomaly Detection — each assessed for significance and whether Rubrik has a right to play. — FIG. 09Five user needs, weighed against significance and Rubrik's right to play in each.