TL;DR: Arcon’s analysis shows three recurring NHI breach patterns: hard-coded secrets, over-privileged service accounts, and orphaned identities, each rooted in missing ownership, justification, or lifecycle control. The lesson is that NHI governance fails when identities are created faster than they are inventoried, scoped, and retired.
At a glance
What this is: This is an analysis of three common non-human identity failure modes, with the central finding that each one traces back to missing ownership, justification, or lifecycle governance.
Why it matters: It matters because IAM and PAM teams cannot govern service accounts, API keys, bots, and workload identities effectively if reviews stop at human users and do not extend to the machine estate.
👉 Read Arcon’s analysis of three recurring NHI breach failure modes
Context
Non-human identity governance fails when teams treat service accounts, API keys, tokens, bots, and workload identities as disposable infrastructure instead of governed identities. In practice, the problem is not just discovery. It is that ownership, purpose, and end dates are missing, so access accumulates outside normal identity controls.
Arcon frames the issue through three recurring failure modes: hard-coded secrets, over-privileged accounts, and orphaned identities. Each one is a different symptom of the same governance gap, and each one becomes harder to contain once the credential estate spreads across code, pipelines, cloud services, and automation.
The underlying issue is familiar to IAM teams, but the scale is not. As machine identity volume grows, the review model built for human users stops being enough, and the machine estate needs continuous lifecycle control rather than occasional inspection.
Key questions
Q: What breaks when non-human identities are not monitored and reviewed?
A: Detection, accountability, and incident response all weaken at the same time. If an NHI behaves abnormally and the organisation cannot tell whether the activity is expected, the control environment loses credibility. The result is delayed containment, harder forensics, and a higher chance that orphaned access remains active.
Q: Why do hardcoded secrets create such a large security risk?
A: Hardcoded secrets turn source code, build output, and configuration files into credential repositories, which makes exposure easy to repeat and difficult to contain. Once a secret is copied into multiple systems, revocation becomes slow and incomplete, and the attack window stays open far longer than most teams expect. That is why hardcoded credentials are a governance failure, not just a code smell.
Q: How should teams decide whether a service account has too much access?
A: Start from the workload’s actual purpose, not from what the account could theoretically do. If the account can reach systems, roles, or data that are unrelated to the task it was created for, the entitlement scope is already too broad and should be reduced.
Q: How do organisations prevent orphaned machine identities from lingering unnoticed?
A: By tying every identity to a lifecycle that includes creation, ownership transfer, review, and retirement. Continuous discovery matters because orphaning is often a process failure, not a single event. If no decommissioning trigger exists, the identity will stay alive until an incident exposes it.
Technical breakdown
Why hard-coded secrets become durable attack paths
A hard-coded secret is a credential embedded in source code, a configuration file, a container image, or a notebook. Once it is committed or shipped, it often escapes the normal lifecycle controls that protect vaulted secrets. The technical risk is not just exposure, but persistence. If the secret is not tied to an owner and a rotation process, it can remain valid long after discovery. That is why scanners matter, but only as an early-warning mechanism. The real control gap is the absence of a governed secret lifecycle across development and deployment systems. Read Guide to NHI Rotation Challenges.
Practical implication: Treat every secret in code or configuration as a lifecycle failure, not just a scanning event.
How over-privileged service accounts create lateral movement paths
Service accounts are meant to perform a defined function without human interaction, but they often inherit broad standing access because nobody revisits the original purpose. That matters because these identities can be abused for legitimate-looking access, privilege escalation, and lateral movement. Since they do not respond to MFA prompts and usually run unattended, misuse blends into expected traffic. The architectural issue is that entitlement scope drifts away from function scope. Once that happens, the account becomes an access bridge rather than a narrow workload identity. See the Service Account Security Guide.
Practical implication: Constrain service account scope to the smallest workload function and remove standing rights that are not continuously justified.
Why orphaned NHIs outlive the systems that created them
An orphaned NHI is a credential or account that still works after the application, project, or owner has moved on. The control failure is lifecycle abandonment: the identity has a valid authentication path, but no accountable owner and no retirement trigger. That makes the identity especially dangerous because there is no business process to notice misuse or decommission it on time. The governance answer is continuous discovery plus lifecycle assignment, because the threat is not novelty, but persistence without accountability. See the NHI Ownership and Accountability Guide.
Practical implication: Inventory machine identities continuously so decommissioning can happen when purpose ends, not after an incident.
Threat narrative
Attacker objective: The attacker wants durable, low-friction access that blends into normal machine traffic and opens a path to wider compromise across cloud and application services.
- Entry begins when an attacker finds a hard-coded secret in code, a config file, or a public repository and uses it to authenticate as the machine identity.
- Credential access turns into privilege abuse when the compromised service account exposes broader rights than the workload actually needs.
- Escalation and lateral movement follow when the attacker uses that standing access to reach downstream systems and additional services.
- Impact occurs when orphaned or over-privileged identities let the attacker persist, move quietly, and expand reach without normal lifecycle controls interrupting the chain.
Breaches seen in the wild
- Kubeflow cryptomining attacks 2020: Exposed Kubeflow dashboards and a notebook's mounted Kubernetes service account let attackers run cryptominers on tens of ML clusters.
- Cisco Active Directory credentials leak 2025: Kraken leaked Cisco Active Directory hashes, including service and krbtgt accounts; Cisco says they came from its 2022 breach, not a new one.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Ownership is the control that collapses the three NHI breach patterns into one governance problem. Hard-coded secrets, over-privileged accounts, and orphaned identities are not separate categories of risk so much as separate outcomes of the same missing discipline: nobody is accountable for the identity from creation to retirement. Once ownership is absent, review logic degrades into guesswork and remediation becomes reactive. The practitioner implication is simple: if an identity has no owner, the rest of the control stack is already compensating for a governance failure.
Hard-coded secrets expose a trust model built on the assumption that credentials live in managed systems, not in software artefacts. That assumption breaks as soon as secrets appear in repositories, images, or notebooks, because the credential’s lifecycle no longer matches the workload’s lifecycle. The issue is not only exposure but persistence. The implication is that secret governance has to move upstream into development and deployment paths, not remain a post-deployment audit activity.
Over-privileged service accounts show how least privilege fails when entitlement scope is never revalidated against actual workload purpose. The account is created for one task, then accumulates rights because nobody wants to break production. That drift turns legitimate automation into a lateral-movement bridge. The implication is that standing privilege for NHIs is not a neutral default; it is a governance decision that must be revisited as the workload changes.
Orphaned identities are a lifecycle failure, not just an access hygiene issue. The credential still works, but the business process that should retire it has disappeared. That means the control gap is not merely missed detection. It is the absence of an end state for machine identities. The implication is that lifecycle retirement has to be designed into NHI governance from the start, not bolted on after inventory.
Ephemeral scale creates NHI trust debt: the faster machine identities are created and forgotten, the more the organisation relies on assumptions that no human reviewer can keep up with. Discovery, ownership, and lifecycle control are therefore not separate programmes. They are the minimum condition for making machine identity governance operational.
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
NHI trust debt: the more machine identities are created without ownership and retirement triggers, the more the organisation depends on review processes that were designed for human pace, not machine scale. That gap will keep widening unless identity programmes treat discovery, ownership, and lifecycle as one operational control set.
Hard-coded secrets and orphaned identities expose the same strategic problem: machine access is being provisioned faster than it is being governed. Teams that continue to rely on periodic access review alone will keep finding the issue only after credentials have already outlived their intended purpose.
The practical shift is toward issuance-time control rather than after-the-fact inspection. If a credential can exist in code, move through pipelines, and remain live after the workload changes, then governance has to be attached to creation, rotation, and retirement, not just to the quarterly review cycle.
For practitioners
- Assign an owner to every NHI at creation Link each service account, API key, token, and workload identity to a named business and technical owner so no credential exists without accountability.
- Remove secrets from code and deployment artefacts Move credentials into a managed vault and inject them at runtime so source repositories, container images, and notebooks no longer carry reusable secrets.
- Scope service accounts to documented purpose Review each account against the workload it actually serves, then remove broad standing rights and replace them with just enough access for that function.
- Build continuous NHI discovery and retirement Inventory identities as they appear, track their purpose and dependencies, and decommission anything with no owner or no current use.
Key takeaways
- The core risk is not a single bad credential pattern but a governance model that creates machine identities without durable ownership, justification, or retirement.
- Arcon’s analysis identifies three recurring failure modes, and they all lead to the same outcome: access that outlives the workload, the team, or the application.
- Practitioners need continuous discovery, explicit ownership, and lifecycle control if they want NHI governance to work at enterprise scale.
Related NHI Mgmt Group resources: Ultimate Guide to NHIs · Service Account Security Guide · NHI Ownership and Accountability Guide · Guide to NHI Rotation Challenges
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Hard-coded secrets are the central exposure mode discussed in the article. |
| NHI-05 — Overprivileged NHI | The article centres on service accounts with rights far beyond their workload purpose. | |
| NHI-01 — Improper Offboarding | Orphaned identities persist because machine identities are not retired on lifecycle end. | |
| Recommendation — Move exposed credentials out of code and artefacts and enforce vault-backed secret handling. Reduce standing access so each NHI only retains the permissions its function requires. Build deprovisioning triggers into NHI lifecycle processes so orphaned identities are removed promptly. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Credential lifecycle, rotation, and revocation are core issues in the article. |
| Recommendation — Apply authenticator management controls to rotate, revoke, and inventory machine credentials. | ||
| CIS Controls v8 | CIS-5 — Account Management | The article is fundamentally about unmanaged machine account creation, scope, and retirement. |
| Recommendation — Use account management controls to inventory machine accounts and remove stale or excessive access. | ||
| MITRE ATT&CK | TA0006; TA0008 — Credential Access; Lateral Movement | The attack patterns described rely on exposed credentials and broad account reach. |
| Recommendation — Map exposed secrets and broad service accounts to credential access and lateral movement detection. | ||
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.
- Hardcoded Secret: A hardcoded secret is a credential written directly into source code, scripts, configuration files, or build assets. It is convenient for development but dangerous in production because it can be copied, indexed, propagated, and reused outside the intended control boundary.
- Orphaned Identity: An orphaned identity is a service account, token, or other machine credential that no longer has a clear owner, purpose, or retirement path. These identities create compliance and security risk because they are easy to forget, difficult to review, and often remain active long after they should have been removed.
- Overprivileged Service Account: A service account that has been granted more permissions than its workload needs. In cloud environments, this creates unnecessary blast radius because compromise of one non-human identity can expose multiple systems, data stores, or accounts through inherited or broad entitlements.
What's in the full article
Arcon's full post covers the operational detail this analysis intentionally leaves for the source:
- Step-by-step examples of where hard-coded secrets surface in repositories, images, and notebooks
- Practical scoping guidance for service accounts that need to stay functional without broad standing access
- A simple mapping of missing governance controls to each failure mode, useful for internal review
- The article’s own breakdown of how AI agents inherit these same NHI failure modes
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle 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 programme, it is worth exploring.
Published by the NHIMG editorial team on October 22, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org