NHI security risks are now a board-level business liability

At a glance

What this is: This analysis argues that non-human identities have become a board-level business liability because they are numerous, valuable, and often governed too weakly to withstand real-world abuse.

Why it matters: IAM, PAM, and NHI teams need to treat machine identities as core enterprise risk because weak ownership, visibility, and control can turn routine access into compliance exposure and breach impact.

By the numbers:

• 1 in 5 organisations reported a security incident related to non-human identities.
• Only 15% of companies felt confident in their ability to secure those machine identities.
• Credentials-related breaches cost organisations $4.62 million on average, according to IBM data cited by Cerbos.

Context

Non-human identities are machine credentials such as service accounts, API tokens, bots, and keys that allow systems to authenticate and call other systems. The governance gap is that many programmes still treat these identities as background infrastructure instead of governed actors with ownership, lifecycle, and access boundaries.

Cerbos frames the issue as business risk because these identities often carry direct access to data, services, and production systems. Once a machine credential is stolen or left unmanaged, attackers can move with valid access rather than noisy exploit chains, which raises both breach impact and compliance exposure.

The article also links NHI weakness to board-level outcomes such as downtime, audit failure, customer trust erosion, and multi-million-dollar loss. That framing is typical of mature NHI analysis, because the problem is no longer whether machine identities exist, but whether the organisation can govern them at enterprise scale.

Key questions

Q: How should security teams govern non-human identities at scale?

A: Security teams should treat non-human identities as a lifecycle problem with ownership, review, rotation, and revocation built in from the start. Inventory is necessary but insufficient. The control objective is to ensure every service account, token, or automation identity has a clear purpose, a bounded scope, and a reliable offboarding path when it is no longer needed.

Q: Why do unowned service accounts create more security risk?

A: Unowned service accounts create more risk because no one is responsible for reviewing their permissions, rotating their credentials, or removing them when they are no longer needed. That makes privilege creep more likely and makes it harder for analysts to respond quickly when unusual activity appears.

Q: What breaks when machine credentials are not rotated?

A: When machine credentials are not rotated, stale access accumulates and the organisation loses confidence that the secret still reflects the intended scope. Old credentials can survive after personnel, vendors, or applications change. That turns a small administrative miss into a broad exposure problem.

Q: What does good NHI governance look like for audit and compliance purposes?

A: For audit and compliance, good NHI governance requires four capabilities: complete inventory (demonstrating knowledge of all NHIs including informally created ones), ownership accountability (every NHI has an identified current owner), access control discipline (NHIs have minimum necessary permissions with regular reviews and documented findings), and audit trail integrity (ability to reconstruct what any NHI did at any point within the regulatory retention period).

Technical breakdown

Why unmanaged machine credentials become a business control gap

Non-human identities are valuable because they often sit inside trusted service paths and can reach sensitive systems without the friction of human authentication. When a service account, API token, or hard-coded credential is left unmanaged, it becomes a durable access path that can outlive the workload or team that created it. The technical problem is not simply that credentials exist, but that many are issued faster than they are inventoried, classified, or retired. Once access is valid, defenders see normal authentication rather than obvious intrusion, which makes detection and containment slower.

Practical implication: Practitioners need inventory, ownership, and lifecycle control for every machine credential before they can rely on downstream monitoring.

How NHI compromise turns into production access abuse

The article’s breach examples show a repeated pattern: attackers do not need to break cryptography when they can steal valid tokens or credentials. A service account or session token can be reused to generate more access, pull secrets, and pivot into connected systems. In identity terms, the attacker is abusing trusted delegation rather than exploiting a software flaw. That is why NHI security is tightly linked to authorization scope, token lifetime, and the blast radius of each credential. The weakest point is often not the platform itself, but the authority granted to a machine identity.

Practical implication: Security teams should scope machine credentials so that one stolen token cannot expand into broad system or customer access.

Why compliance frameworks increasingly expect NHI governance

Machine identities now sit inside the control expectations of SOC 2, ISO 27001, NIS2, GDPR, and PCI-DSS-style programs because they are part of logical access, auditability, and secure operations. A reviewer who cannot tell who owns a service account, when it was last rotated, or why it exists is looking at a governance failure, not a documentation issue. The issue is especially acute when credentials are embedded in code, shared across environments, or left active after systems are decommissioned. In compliance terms, that undermines least privilege, traceability, and evidence of control operation.

Practical implication: IAM and GRC teams need auditable ownership and rotation evidence for machine identities, not just policy statements.

Threat narrative

Attacker objective: The attacker wants to turn trusted machine access into broad operational or customer data exposure while avoiding obvious intrusion signals.

1. Entry occurs through valid machine credentials such as a leaked service account, API token, or session token rather than through exploit code.
2. Credential abuse lets the attacker act as a trusted system identity and request more data or downstream access without triggering obvious human login controls.
3. Escalation follows when the abused credential can reach production secrets, customer data, or adjacent systems with broader privileges.
4. Impact is realised through data exposure, credential rotation, incident response, compliance scrutiny, and business disruption.

Breaches seen in the wild

• Dropbox Sign breach 2024: A compromised back-end service account gave attackers Dropbox Sign customer data, including API keys, OAuth tokens and MFA information.
• Salesloft OAuth token breach: hackers stole OAuth tokens to access Salesforce data via Salesloft.

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

NHI Mgmt Group analysis

Machine identity governance is now a board issue because the attack surface is operational, not theoretical. NHIs are embedded in production workflows, customer integrations, and cloud automation, so their failure modes translate directly into downtime, disclosure, and compliance exposure. Boards do not need to understand every token type to understand the risk: if machine access is unowned or over-scoped, the business is carrying hidden operational liability.

Unmanaged machine access is a governance failure, not a tooling gap. The article shows that the core problem is not whether a scanner can find a credential, but whether the organisation can prove ownership, least privilege, rotation, and retirement across the estate. That is a programme design issue, and it belongs in identity governance, not only in security operations.

Visible breaches are the symptom; the deeper issue is credential authority without lifecycle accountability. When an API key, token, or service account remains active after its original purpose changes, access outlives the business process that justified it. That mismatch is what makes machine identity governance a recurring risk category rather than a one-time cleanup exercise.

ROI arguments for NHI security only work when teams compare control cost with real business loss. The article’s business case is strongest when it ties credential governance to avoided incident response, reduced audit friction, and lower breach impact. That framing matters because NHI programmes often stall when they are treated as technical hygiene rather than as loss prevention and operational resilience.

Compliance pressure is accelerating the need for a named concept: credential authority without accountability. This is the condition where access exists, but no one can evidence who owns it, why it exists, or when it should end. The implication for practitioners is that NHI governance must be measured as an enterprise control discipline, not a list of secrets to rotate.

From our research library:

• NHIs outnumber human identities by 25x to 50x in modern enterprises, according to the Ultimate Guide to NHIs.
• 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, according to the Ultimate Guide to NHIs.
• Read next: Ultimate Guide to NHIs

What this signals

Credential authority without accountability: The real governance failure is not the existence of machine credentials, but the fact that many remain active without a clearly owned lifecycle. That means the control point moves from login security to issuance, scope, and retirement, which is where most programmes are weakest.

Board reporting on NHI risk needs to translate machine identity exposure into business language: customer trust, downtime, audit findings, and incident cost. Once the issue is framed that way, service account governance stops looking like infrastructure cleanup and starts looking like operational resilience.

Existing IAM and PAM models often assume a stable, human-paced review cycle. NHIs move on different timelines, so the programme has to prove whether ownership, expiration, and privilege boundaries are enforced continuously rather than reviewed after the fact.

For practitioners

• Define ownership for every machine identity Assign a named business and technical owner to each service account, API token, bot, and key so that lifecycle decisions are traceable.
• Inventory credentials across all environments Build a current register of non-human identities across cloud, CI/CD, and production systems, including where each credential is used and what it can reach.
• Reduce standing access scope Trim machine permissions to the smallest viable set so a stolen token cannot access customer data, secrets, or adjacent production services.
• Prove rotation and retirement evidence Track rotation dates, expiry settings, and decommissioning records so auditors can see that machine access is not left active indefinitely.
• Tie NHI controls to board reporting Report machine identity exposure as a business risk with incident, compliance, and downtime implications rather than as a narrow infrastructure metric.

Key takeaways

• Non-human identities are a governance problem because valid machine access can be used to reach production systems and sensitive data without bypassing authentication controls.
• The article ties the risk to real scale and consequence, citing 25x to 50x more NHIs than humans, NHI incidents at one in five organisations, and average credential-breach costs of $4.62 million.
• The clearest control theme is lifecycle accountability: ownership, scope reduction, rotation, and retirement are what keep machine credentials from becoming standing business liabilities.

Key terms

• Non-Human Identity (NHI): A digital identity assigned to a non-human entity such as a software application, service account, API key, bot, machine, or AI agent that enables it to authenticate and interact with systems without direct human involvement. NHIs now outnumber human identities in most enterprises by 25 to 50 times.
• Service Account: A special-purpose account used by applications, automated tools, or services rather than a human user to interact with systems, APIs, and infrastructure. Service accounts are a primary category of NHI and one of the most frequently exploited attack vectors.
• Credential Lifecycle: Credential lifecycle is the process of issuing, rotating, expiring, and revoking secrets, certificates, and tokens across their usable life. For non-human identities, lifecycle discipline is the core control that separates temporary access from persistent exposure.
• Privilege Scope: Privilege scope is the set of actions, data, and tools an identity is allowed to use. For AI agents, scope must be defined around the task and the acceptable blast radius, because broad or persistent privileges can turn a small mistake into a production-level incident.

Deepen your knowledge

NHI governance, machine identity security, and identity lifecycle management are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM or security programme, it is worth exploring.