A few weeks ago, Lalit Choda (aka Mr. NHI), founder of the NHI Management Group, hosted a series of discussions on non-human identities (co-located with Identiverse)—an increasingly urgent challenge in the security landscape.
I had the opportunity to join a panel alongside Kirby Fitch from SailPoint to talk about the risks, terminology confusion and the visibility gaps organizations face in managing NHIs.
One key point we discussed is the lack of consistency across the industry. Whether you call them machine identities, service accounts, or workload principals, the fact remains: NHIs are now everywhere, and they need rigorous governance. We need to draw a clearer line between credentials and identities—and ensure both are treated as first-class security concerns.
In the panel, I emphasized that how we define an identity depends heavily on the system you’re looking at—an IAM role in AWS, a service principal in Azure, or a service account in GCP or in Active Directory. What we’re lacking is not just a naming convention, but a standardized way to reason about access across these constructs. Today, most organizations can’t answer a basic question: “Who—or what—can take what action on which resource?” Without that baseline, governance efforts become reactive and fragmented. It’s not enough to see the sprawl—we need to map entitlements, link them to specific identities (human and non-human), and enforce policies continuously. Otherwise, we’re left chasing shadow identities through logs and spreadsheets.
Beyond our panel, I also appreciated the insights shared by Vincenzo Iozzo from SlashID and Michael Silva from Astrix Security. Both provided real-world context on how NHIs are actively being exploited:
- Vincenzo highlighted that in modern attacks, adversaries increasingly rely on stolen credentials to simply log in rather than break in. CrowdStrike’s threat intel shows a 6x spike in credential-based attacks, and AWS reported that 66% of customer breaches involved leaked or exposed NHI credentials.
- Michael walked through a striking demo where an attacker harvested an AWS access key and secret from a non-default GitHub branch. Using those credentials, they were able to authenticate as a CI/CD service account—moving laterally across cloud and SaaS services, persisting without detection, and exfiltrating data at will.
These aren’t theoretical risks—they’re playing out today, quietly and efficiently, through overlooked machine identities.
At P0, we believe identity security must go beyond visibility. The path forward requires posture, as well as governance and orchestration. Every identity, whether human or non-human needs to be governed, and every access needs to be short-lived, least-privileged, and passwordless (orchestrated without static credentials).
Thanks again to Lalit, Kirby, Vincenzo, Michael and all the other presenters for pushing this conversation forward.
Frequently asked questions
What is the difference between machine, workload, and service identities in the cloud?
Machine, workload, and service identities all refer to non-human identities that authenticate and act in the cloud without a human directly logging in.
Why does every non-human identity become a risk if its access is left unsecured?
Every non-human identity becomes a risk when its access is left unsecured, because attackers can exploit unmonitored service accounts just as easily as human credentials.
How do you enforce least privilege across machine and workload identities?
Teams enforce least privilege across machine and workload identities by continuously right-sizing permissions instead of granting broad, standing access by default.
How does P0 Security govern and rotate credentials for non-human identities?
P0 Security governs and rotates credentials for non-human identities by automating discovery, right-sizing, and rotation across the entire identity inventory.