NHI threat intelligence is now a governance problem, not just a feed

At a glance

What this is: Oasis Security’s NHI Threat Center frames threat actor behaviour around live NHI attack patterns, starting with 20 observed actors and the credential-driven methods they use against cloud identities.

Why it matters: IAM teams need this lens because NHI, autonomous, and human identity programmes are all affected by the same external pressure: repeated attempts to harvest credentials, exploit standing access, and force operational failure.

By the numbers:

• The Threat Center starts with data from 20 threat actors observed in action.
• 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time.
• Only 5.7% of organisations have full visibility into their service accounts.

👉 Read Oasis Security’s introduction to the NHI Threat Center and live threat data

Context

NHI threat intelligence is the practical record of how attackers behave against machine identities in the cloud. The core problem is not just that credentials leak, but that attackers can repeatedly test, reuse, and abuse them at scale before most organisations notice.

The article’s main point is that external pressure on NHIs is constant, opportunistic, and often operationally disruptive even when access attempts fail. That matters for identity programmes because service accounts, tokens, and exposed secrets need governance that assumes continuous attack, not occasional compromise.

Key questions

Q: What breaks when service account credentials are reused across cloud services?

A: Reuse turns one exposed credential into a multi-system access path. Once a password, token, or key works in more than one place, an attacker can pivot from a single leak to broader compromise, often without triggering strong detection. The practical failure is not just exposure, but uncontrolled reach across workloads and SaaS applications.

Q: Why do NHIs complicate credential stuffing and password spraying defenses?

A: NHIs complicate these attacks because they often rely on static, reusable secrets rather than user-centric sign-in patterns. That gives attackers durable material to test at scale, while the organisation may only see noisy failures or lockouts. Defending them requires secret hygiene, not just login throttling.

Q: How do security teams know if NHI exposure is creating operational risk?

A: Look for repeated authentication failures, lockouts, and sudden spikes in access attempts against the same identities. Those signals show that an attacker is actively testing the environment, even if no login succeeds. If the same identity keeps attracting attempts, its privilege and exposure profile are likely too broad.

Q: Who is accountable when exposed NHI credentials cause repeated lockouts?

A: Accountability usually sits with the team that owns the credential lifecycle, because lockouts expose a failure in discovery, rotation, and containment. Security operations may detect the issue, but identity, platform, and application owners must each answer for why the credential remained valid and reachable.

How it works in practice

Credential enrichment against NHI attack surfaces

Attackers first build a pool of usable identities by collecting leaked credentials, public code snippets, exposed configuration files, and email addresses. In NHI environments, that pool often includes service accounts, API keys, and other secrets that are easy to reuse across systems. Once a credential is harvested, the attacker can test it across multiple clouds, SaaS apps, or developer tools without needing a bespoke exploit. This is why credential exposure is a governance failure as much as a technical one: a single secret can become a repeatable entry point across many services.

Practical implication: inventory every place secrets can leak, including code, config files, and collaboration tools, then treat each exposed credential as a live access event.

Credential stuffing and password spraying against cloud identities

Credential stuffing reuses known username and password pairs across services, while password spraying uses a small set of common passwords across many accounts to avoid lockouts. For NHIs, the same logic applies when reusable secrets, static tokens, or weakly protected access paths exist. Rate limits help, but they do not eliminate the underlying exposure if the organisation allows persistent credentials with broad reach. The attacker does not need to break the authentication system if the organisation has already left working identity material lying around in multiple places.

Practical implication: pair rate limiting with secret rotation, unique credentials, and detection for repeated low-and-slow authentication attempts.

Why failed attacks still create operational impact

The article notes that most attacks fail, but failure does not mean harmless. Repeated login attempts can cause account lockouts, trigger noisy alerts, and consume analyst time, which makes the organisation less available even before a compromise occurs. In identity terms, this is a resilience issue, not just a confidentiality issue. A mature NHI programme has to measure attacker persistence, lockout impact, and the volume of repeated authentication attempts, because those signals show where access controls are being stressed in real time.

Practical implication: monitor lockouts and repeated authentication failures as operational indicators of NHI exposure, not just as SOC noise.

NHI Mgmt Group analysis

External pressure on NHIs is now a standing governance condition, not an occasional incident pattern. The article’s 20 observed actors show that cloud identities are being probed continuously, often by opportunistic adversaries looking for whatever is easiest to reuse. That changes the baseline for identity governance: NHI programmes have to assume repeated credential testing as part of normal operating reality. Practitioners should treat attacker persistence as a control design input, not a surprise.

Credential enrichment is the real attack surface, not authentication alone. The breach pattern begins long before a login page sees traffic, because leaked credentials, exposed config files, and public code expand the accessible identity pool. This is classic OWASP-NHI territory: the control problem is not only who can sign in, but where usable secrets exist and how easily they can be harvested. Practitioners should read exposure paths as identity lifecycle failures, not just security hygiene misses.

Account lockouts are a signal of NHI governance failure, not just user inconvenience. The article’s emphasis on aggressive actors shows that repeated failed attempts can create real operational friction even when compromise does not occur. That makes lockout behaviour an identity resilience metric, because it reveals whether the organisation’s access controls can absorb attack pressure without taking down legitimate work. Practitioners should measure disruption as part of identity risk, not outside it.

Identity blast radius is the right named concept for this threat model. Once attackers can reuse one credential across many services, the damage is defined by how far that identity reaches, not by the original leak alone. The article’s own radar-style actor scoring implicitly reflects spread, persistence, and aggressiveness, which are all blast-radius variables in NHI governance. Practitioners should assess each credential by its reachable surface and downstream impact, because broad privilege turns one leak into a multi-system problem.

Visibility is the control boundary that determines whether these attacks stay invisible. The article argues that attacks are often unnoticed until they succeed, which means detection lag is part of the problem itself. NHI governance cannot rely on periodic review alone when the threat is high-frequency and low-friction. Practitioners should focus on live observability for authentication patterns, exposed secrets, and repeated lockout activity, because the absence of visibility is what allows opportunistic actors to keep working.

From our research:

• Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs.
• From our research: 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to Ultimate Guide to NHIs.
• The relevant next read is 52 NHI Breaches Analysis, which shows how these exposure paths translate into real compromise patterns.

What this signals

Identity blast radius is becoming the more useful planning unit for NHI programmes than the individual secret. When one credential can be reused across multiple services, the security question is how far that identity can travel before controls interrupt it. That makes exposure mapping and access scoping a board-relevant governance issue, not only a technical cleanup task.

With 96% of organisations storing secrets outside secrets managers in vulnerable locations including code, config files, and CI/CD tools, per Ultimate Guide to NHIs, the problem is not niche. The operational signal is simple: if your environment still assumes secret location is known and stable, attacker enrichment will keep outpacing remediation.

Teams that already track service accounts should extend that discipline into live attack monitoring and lifecycle response. The best programme shift is to connect discovery, rotation, lockout telemetry, and offboarding into one operating model, then benchmark it against the 52 NHI Breaches Analysis to see which failure modes repeat most often.

For practitioners

• Map every secret exposure path Inventory code repositories, configuration files, CI/CD systems, collaboration tools, and public-facing assets for service-account credentials, API keys, and tokens. Prioritise cleanup where the same secret could be reused across multiple cloud services.
• Reduce reuse across authentication paths Replace shared or long-lived credentials with unique, scoped identities and rotate exposed secrets immediately after discovery. Where reuse cannot be eliminated quickly, isolate the affected account and restrict its reachable systems until it is remediated.
• Treat repeated lockouts as threat telemetry Correlate account lockouts, bursts of failed logins, and unusual geographic spread to identify credential-stuffing and password-spraying campaigns early. Feed those signals into incident triage so operational disruption is investigated alongside compromise risk.
• Rank NHIs by reachable blast radius Classify service accounts and tokens by the number of systems, regions, and workflows they can touch. Use that ranking to decide which identities need tighter controls, faster rotation, and stronger monitoring first.
• Build a live attack-surface view for NHIs Maintain ongoing visibility into exposed credentials and authentication noise so the security team can see which identities are being tested in real time. Tie that view to the Ultimate Guide to NHIs for lifecycle and visibility guidance.

Key takeaways

• This article shows that NHI threats are continuous, opportunistic, and operationally disruptive even before compromise succeeds.
• The scale signal is not just the 20 observed actors, but the broader reality that exposed secrets and repeated login attempts create sustained identity pressure.
• The control that matters most is not a single defensive tool, but visibility, rotation, and reach reduction across every credential path.

Key terms

• Non-Human Identity: A non-human identity is any machine or software identity used to access systems, data, or services. In practice this includes service accounts, API keys, tokens, certificates, and workload identities. Governance depends on knowing where the identity exists, what it can reach, and when it should be rotated or removed.
• Credential Stuffing: Credential stuffing is the reuse of previously exposed username and password pairs across multiple services. The attack works because many organisations still allow credentials to remain valid long enough for reuse. For NHIs, the same pattern often affects static secrets and tokens that were never designed for broad repetition.
• Password Spraying: Password spraying is a low-and-slow login attack that tries a small set of common passwords across many accounts. It is meant to avoid lockouts and other obvious alarms. For identity teams, the key issue is that spraying exposes weak authentication posture and broad credential reuse across the environment.
• Identity Blast Radius: Identity blast radius is the amount of damage a single credential can cause once it is compromised. It is shaped by privilege scope, system reach, and how many workflows depend on that identity. The smaller the blast radius, the less useful the credential is to an attacker after exposure.

Deepen your knowledge

NHI threat intelligence and lifecycle exposure are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your team is trying to turn threat observation into governance, that course is a practical next step.

This post draws on content published by Oasis Security: Introducing the Non Human Identity Threat Center, a new resource for the cloud security community. Read the original.