They Don't Need to Crack Anything: How Attackers Exploit Your Non-Human Identities

The Second Workforce Has a Security Problem

Last week I made the case that most organizations have a second workforce they never hired — thousands of non-human identities operating inside their environment that nobody can fully account for. Service accounts. API keys. OAuth tokens. Certificates. CI/CD pipeline credentials. Cloud service principals. The ratio isn't close: research consistently puts non-human identities somewhere between 45 and 144 for every human in the environment.

If you missed that post, the short version is this: you probably can't estimate your NHI population within an order of magnitude, which means you're not governing it. You're hoping.

This week I want to get into why that matters so much from an attacker's perspective. Because the reason this problem keeps showing up in breach reports isn't complicated. It comes down to one simple reality: attackers don't need to crack anything. They just need to find a credential that works, and your non-human identities are full of them.

Why Machines Are a Better Target Than People

Put yourself in an attacker's shoes for a moment. You could go after a human. Phish them, guess a password, try to slip past an MFA prompt. But humans are unpredictable. They notice suspicious login alerts. They call the help desk. They change their passwords when they get nervous. And most organizations have spent the last decade building detection around human account behavior.

Now consider the alternative. A service account that hasn't had its credentials rotated in 18 months. An OAuth token issued to a third-party integration that nobody remembers setting up. An API key hardcoded into a configuration file that's been sitting in a repository since the last administration. A cloud service principal with broad permissions that were scoped generously "just to get it working" and never revisited.

None of these will call the help desk. None of them will notice an unusual login. None of them have MFA. And in a surprising number of cases, nobody in the organization knows they exist. Or if they do know, nobody has clear ownership of them.

That's not a vulnerability. That's a welcome mat.

The Okta Breach: A Case Study in Token Exploitation

In late 2023, Okta disclosed a breach of its customer support system. The attack vector wasn't a sophisticated zero-day. It wasn't a nation-state actor with custom tooling. It was a stolen service account credential, specifically a token that gave the attacker access to Okta's support case management system, which in turn contained files uploaded by customers that included session tokens.

Those session tokens then allowed the attacker to move laterally into customer environments.

The entire chain started with one non-human identity. A service account credential. No MFA to bypass. No behavioral anomaly to trigger on. Just a valid token doing what valid tokens do: authenticating successfully and being waved through.

This isn't an isolated story. The pattern shows up repeatedly: an attacker finds a non-human credential, uses it to establish a foothold, and then moves laterally through connected systems. The non-human identity isn't the end goal. It's the door.

Access Tokens: Fragile by Design

Access tokens deserve specific attention because they've become the connective tissue of modern cloud environments, and they were never really designed with security governance in mind.

OAuth tokens, API keys, and cloud access tokens share a few common characteristics that make them attractive to attackers. They're often long-lived, issued with a broad expiration window because rotating them is operationally painful. They're frequently over-permissioned, granted wider access than the integration actually needed because scoping them correctly takes time nobody had at the moment. And they're often invisible to security tooling, because they live outside the identity governance platforms most organizations use to manage human accounts.

The math here is uncomfortable. CyberArk's 2025 research found that nearly half of non-human identities carry sensitive or privileged access. If roughly half of a population that outnumbers your humans by 50 to 1 or more has privileged access and isn't being actively monitored, that's not a gap in your security posture. That's a canyon.

And unlike a compromised human account, where you can call the user, force a password reset, and have a conversation about what happened, a compromised token often goes undetected for months. There's no behavioral baseline to deviate from. There's no user to notice something feels off. The credential just keeps working until someone thinks to look.

The Ownership Problem Makes It Worse

Here's the thing that ties all of this together, and it's the same thread I pulled on last week: most non-human identities don't have a clear owner.

A human account has an HR record, a manager, a joiner-mover-leaver process, and an access review. When something goes wrong with a human account, there's a chain of accountability to follow.

A service account created by a developer three years ago to wire up an integration? That developer may have left the company. The integration may still be running. The account may still have the same permissions it was granted at creation. And nobody may know any of this until an incident makes them go looking.

Recent industry data puts about 8% of enterprise identities in a state where there's no owner in any HR system. The person who created them is gone, but the credential and its access remain. Around 47% of non-human identities haven't had their credentials rotated in more than a year. These aren't edge cases. They're the norm.

From a governance standpoint, an identity with no owner is one that no one will ever review, rotate, or retire. From an attacker's standpoint, that's exactly the kind of identity worth finding.

What Good Looks Like

The good news is that this isn't an unsolvable problem. It's a hard one, but it has a clear starting point.

The first move is always discovery. You can't govern what you can't see, and you can't protect what you don't know exists. A proper NHI discovery effort will almost always surface more than the organization expected: orphaned service accounts, tokens connected to decommissioned systems, certificates issued by CAs that shouldn't exist, API keys living in configuration files they were never supposed to be in. The gap between "what we thought we had" and "what we actually have" is the risk.

From there, the priority is ownership assignment. Every non-human identity needs an accountable owner, a team or individual responsible for its lifecycle, its permissions, and its eventual retirement. Without that anchor, everything else is theoretical.

Then comes least privilege. Most NHIs were granted access generously because it was faster than scoping it correctly. Rightsizing that access is painstaking work, but it dramatically limits the blast radius of a compromise.

And then rotation. Which is, admittedly, harder than it sounds. That's a topic for next week.

Where This Fits in the Bigger Picture

Every Zero Trust model is built on the assumption that you can enumerate the things asking for access and make an informed decision about whether to trust them. For your human users, you mostly can. For your non-human identities, most organizations can't, and that means the foundation a lot of Zero Trust programs are built on has a hole in it the size of their largest identity population.

The organizations that are getting ahead of this aren't waiting for a breach to make the case internally. They're treating NHI governance as a discipline — not an IT housekeeping task, but a security program with dedicated ownership, tooling, and executive visibility.

At Olympus Solutions, this is foundational to how we approach identity assessments. If you're not sure where your organization stands on NHI visibility and governance, that's the right place to start the conversation. Reach out — I'm happy to talk through it.

This is the second in a series on non-human identities. Next up: why "just rotate them" is a lot harder than it sounds, and what a realistic maturity path actually looks like.