Non-human identity governance is still lagging cloud reality

At a glance

What this is: This is an Unosecur article framing non-human identity as a core IAM and cloud security problem, with emphasis on overprivilege, key rotation, and overlooked automation accounts.

Why it matters: It matters because service accounts, API keys, and bot identities can become hidden access paths if teams do not govern them with the same discipline they apply to human users.

By the numbers:

• Only 5.7% of organisations have full visibility into their service accounts.
• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
• 30.9% of organisations store long-term credentials directly in code.

👉 Read Unosecur's article on non-human identity security and governance

Context

Non-human identity governance is the discipline of controlling the service accounts, API keys, tokens, certificates, bots, and workloads that software uses to authenticate and act. The problem is not that these identities exist. The problem is that they often accumulate broad permissions, weak ownership, and inconsistent lifecycle controls while remaining outside the strongest parts of IAM review.

In cloud and DevOps environments, that gap becomes operational rather than theoretical. Automation accounts often need fast access and broad data reach, but without clear scope, rotation, and monitoring they become durable access paths for attackers. The article’s starting position is typical for the market: most teams understand the concept of machine identity, but fewer have a reliable governance model for the broader non-human identity estate.

Key questions

Q: How should security teams govern non-human identities in cloud environments?

A: Start with inventory, ownership, and privilege scope. Every service account, API key, token, and bot should have a named owner, a documented purpose, and an expiry or review cycle. Then enforce least privilege, rotation, and revocation so the identity cannot become a durable backdoor when workloads change or teams forget it exists.

Q: Why do non-human identities increase the blast radius of a breach?

A: Because they often authenticate machine-to-machine and carry permissions that are broader than a single human session. If an attacker steals one secret, they may gain direct access to data pipelines, deployment systems, or APIs without triggering the same friction as interactive login controls. That turns one exposed credential into a high-speed lateral movement path.

Q: What is the difference between human identity governance and NHI governance?

A: Human governance focuses on people, roles, and interactive access reviews. NHI governance focuses on credentials that are embedded in code, pipelines, services, and automation, where ownership is weaker and runtime access is often continuous. The control model must therefore emphasise lifecycle, rotation, and machine-scoped privilege rather than only user-centric authentication.

Q: When should organisations replace static secrets with ephemeral credentials?

A: Use ephemeral credentials whenever a workload can tolerate short-lived access and the secret would otherwise persist across deploys, environments, or teams. That is especially important for CI/CD pipelines, privileged APIs, and automation that touches sensitive data. Ephemeral access reduces exposure, but only if the organisation also enforces revocation and monitoring.

Technical breakdown

Why non-human identity sprawl creates hidden access risk

Non-human identity sprawl happens when service accounts, API keys, tokens, and bot credentials grow faster than ownership and review processes. Unlike human identities, these accounts are often created by application teams, embedded in pipelines, or inherited across environments, so they evade standard joiner-mover-leaver thinking. The result is a fragmented control surface where access is real but poorly mapped. In practice, the security issue is not only how many identities exist, but whether each one has a purpose, an owner, and a revocation path.

Practical implication: Inventory every non-human identity and assign a named owner before applying policy or rotation.

How excess privileges turn automation into an attack path

A non-human identity becomes high risk when it can read, write, or administer more systems than its workflow requires. Excess privilege is especially dangerous for service accounts because compromise usually yields direct machine-to-machine access, not a visible user login event. That shortens attacker dwell time and expands blast radius. Good governance uses least privilege, segmented scopes, and task-specific entitlements so a compromised secret does not translate into broad platform access.

Practical implication: Reduce permission scope before introducing new automation, then re-certify privileges on a fixed schedule.

Why credential rotation and offboarding are the real control points

Non-human identities fail when their credentials outlive the workload that created them. Long-lived keys, unrotated tokens, and missing offboarding steps mean that abandoned automation can remain a live entry point long after the business need has changed. Rotation matters, but rotation without revocation and monitoring only hides the problem. The architecture needs lifecycle controls that tie issuance, usage, expiry, and retirement together so access cannot persist by accident.

Practical implication: Build automated rotation with enforced expiry and revocation checks for every credential class.

Threat narrative

Attacker objective: The attacker wants trusted machine access that bypasses human authentication controls and enables silent expansion into sensitive systems.

1. Entry via exposed or unrotated service credentials tied to automation, APIs, or CI/CD workflows.
2. Escalation through overly broad permissions that let the attacker read, modify, or reuse adjacent systems.
3. Impact through lateral movement or data exfiltration using the compromised non-human identity as a trusted access path.

Breaches seen in the wild

• Sisense breach — unauthorized GitLab access led to exfiltration of access tokens, API keys and certificates.
• Dropbox Sign breach — compromised Dropbox Sign service account exposed API keys and OAuth tokens.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Non-human identity is now an IAM domain, not a niche DevOps concern. The article reflects a broader market reality: automation identities are part of core access architecture, not an edge case. Once service accounts and bots can read data, deploy code, or call sensitive APIs, their governance belongs in the same conversation as human access reviews and privileged controls. The practitioner conclusion is simple: if IAM does not own NHI policy, nobody effectively does.

Identity blast radius is the right concept for this problem space. The article points to a familiar pattern where one compromised credential can touch many systems because the account was built for speed, not containment. That is why the control question is not only whether a secret leaks, but how far the resulting trust chain extends. The practitioner conclusion is to measure and reduce blast radius, not just count credentials.

Static credential dependency creates trust debt. When automation relies on long-lived keys and tokens, every day of runtime adds more exposure to reuse, leakage, and forgotten access. That debt compounds when credentials are embedded in code or pipeline tooling. The practitioner conclusion is to replace persistent trust with short-lived, task-scoped access wherever possible.

Lifecycle governance is the missing operating model for NHIs. Creation without ownership, rotation without revocation, and access without review are the recurring failure modes in this category. This is why NHI governance has to move from one-time hardening to continuous control. The practitioner conclusion is to treat every non-human identity as a lifecycle object with start, scope, expiry, and retirement.

Machine identity controls alone are not enough. The article correctly distinguishes machine identities from the wider NHI set, which includes bots, APIs, and service accounts that are not tied to a single device. That distinction matters because governance must cover the identity pattern, not just the endpoint. The practitioner conclusion is to manage the entire non-human estate under one policy model, then segment by risk.

From our research:

• Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs.
• 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage.
• For the control path behind those numbers, see Guide to the Secret Sprawl Challenge for a practical look at where credentials escape and how teams can contain them.

What this signals

Identity sprawl for automation is becoming a structural governance issue. As non-human identities multiply across pipelines, services, and bots, security teams need a control model that tracks owner, scope, and expiry rather than assuming infrastructure teams will self-govern. The practical shift is from periodic cleanup to continuous identity hygiene, because unattended access becomes persistent access.

Only 97% of NHIs carry excessive privileges, according to Ultimate Guide to NHIs, so the default enterprise posture is still over-permissioned. That means privilege reduction is not an optimisation project, it is the baseline condition for controlling automation risk. Teams should expect board-level scrutiny once NHI exposure is mapped into access review and incident response workflows.

Static secret reliance creates trust debt that will keep surfacing in CI/CD and API-heavy environments. The forward-looking programme question is whether your organisation can shift high-risk workflows to short-lived credentials without breaking delivery velocity. The answer usually depends on whether IAM, platform engineering, and application owners are working from the same identity model.

For practitioners

• Inventory all non-human identities Build a complete register of service accounts, API keys, tokens, certificates, bots, and workload identities. Include owner, system, environment, privilege scope, rotation date, and retirement status so hidden access paths can be reviewed and removed.
• Enforce least privilege on automation accounts Remove broad read and write access from pipelines and bots, then align permissions to the narrowest task scope possible. Re-certify access after every material workflow change so privilege creep does not accumulate unnoticed.
• Automate rotation and revocation together Set policy-based expiry for secrets and require revocation checks when workloads are decommissioned or rebuilt. Rotation alone is incomplete if old credentials still work or remain embedded in deployment tooling.
• Move high-risk use cases to short-lived credentials Replace static secrets with ephemeral credentials for high-value pipelines and privileged services where operationally feasible. Use short TTLs, scoped tokens, and monitored issuance so compromise windows stay small.

Key takeaways

• Non-human identity risk is primarily a governance problem, not a tooling problem, because ownership and lifecycle controls are still weak in most environments.
• The scale of the issue is material, with service accounts frequently hidden from full visibility and commonly assigned more privilege than they need.
• Practitioners should prioritise inventory, least privilege, and automated revocation before trying to optimise advanced detection or reporting.

Key terms

• Non-Human Identity: A non-human identity is any account or credential used by software, services, bots, APIs, or workloads rather than a person. It can be a service account, token, certificate, or key. In practice, these identities often outnumber human users and need dedicated governance across their lifecycle.
• Service Account: A service account is a non-human identity created for an application, job, or automated workflow to authenticate to systems. It is useful because it enables machine-to-machine access, but risky when ownership, permission scope, or retirement is unclear. Treat it as a governed identity, not a technical leftover.
• Secret Rotation: Secret rotation is the replacement of credentials such as keys, tokens, or certificates on a regular or event-driven schedule. For non-human identities, rotation only reduces risk when old secrets are revoked, usage is monitored, and the workflow can continue without manual exceptions.
• Identity Blast Radius: Identity blast radius is the amount of systems, data, and operational capability exposed if a single identity is compromised. For non-human identities, blast radius is often larger than teams expect because one credential may power automation across multiple services or environments.

What's in the full article

Unosecur's full blog post covers the operational detail this post intentionally leaves for the source:

• The article’s practical examples of where non-human identities appear in cloud and DevOps workflows.
• The vendor’s discussion of how exposed automation credentials can be discovered and abused.
• The specific management practices it recommends for rotating, scoping, and monitoring service credentials.
• The article’s own framing of the Atlassian API key case as an example of hidden NHI exposure.

👉 Unosecur's full post covers the NHI definition, cloud risk patterns, and the Atlassian API key case.

Deepen your knowledge

Non-human identity governance and lifecycle controls are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your programme is still mapping service accounts and automation credentials, it is the right place to start.