Identity blind spots across core systems create hidden credential risk

At a glance

What this is: This is an identity hygiene analysis showing that blind spots across core systems create exploitable credential risk, especially where privileged accounts and service accounts are unmanaged.

Why it matters: It matters because IAM, IGA, and PAM teams cannot reduce credential-based risk if they cannot see every identity, assign ownership, and close the offboarding and remediation gaps that let abuse persist.

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.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.

👉 Read SPHERE's analysis of identity blind spots across core systems

Context

Identity blind spots are what happen when organisations cannot reliably inventory, own, and retire the identities that move through core systems. In practice, that means privileged human accounts, service accounts, and directory objects can remain active without clear accountability, leaving credential-based access exposed across the IAM and PAM stack.

The problem is not a lack of security tools so much as a lack of continuous identity governance. When discovery, ownership, offboarding, and remediation do not operate together, attackers can exploit stale access paths that teams assume have already been closed. That is typical in large, complex environments with legacy directory sprawl and fragmented administration.

Key questions

Q: How do security teams reduce identity blind spots across code and cloud?

A: They reduce blind spots by correlating GitHub activity with cloud identity signals, enforcing least privilege on repository and workflow permissions, and treating exposed secrets as lifecycle events. That approach helps teams detect drift earlier and cut the time between exposure, investigation, and revocation.

Q: Why do orphaned service accounts create so much risk after an acquisition?

A: Orphaned service accounts are dangerous because they often keep working after the original owner has left or the original environment has changed. In a merger, that persistence turns old access into live access, especially when the account still reaches production systems, cloud resources, or connected SaaS platforms.

Q: What breaks when offboarding does not include secret revocation?

A: The former identity may be removed in IAM while the credential itself remains usable by the ex-employee or by any system that still knows it. That creates a mismatch between lifecycle state and authentication state. The result is lingering access that survives the person-to-system relationship that created it.

Q: How do teams know whether identity hygiene is actually improving?

A: Look for fewer dormant accounts, fewer orphaned privileges, and shorter time-to-removal for leavers and role changes. A healthy programme can show that identity objects are being retired as fast as business context changes, rather than accumulating hidden access over time.

Technical breakdown

Why identity discovery fails in complex directory environments

Active Directory and adjacent core systems accumulate accounts faster than governance teams can reconcile them. Discovery tools may surface identities, but they do not by themselves determine whether an account is owned, still needed, or properly scoped. That is why blind spots persist: the technical inventory exists, but the governance record does not. Unmanaged privileged accounts are especially risky because they are both easier to overlook and more attractive to attackers once they are found. The failure mode is operational, not theoretical. Practical visibility has to extend beyond account counts into ownership, privilege, and lifecycle state.

Practical implication: build identity discovery around ownership and lifecycle status, not just enumeration.

How orphaned service accounts become persistent access paths

Orphaned service accounts are non-human identities that continue to authenticate even after the workload, application, or owner has changed. They often keep broad permissions, old secrets, and weak change control, which makes them ideal for long-lived abuse. Because these identities do not trigger the same joiner-mover-leaver attention as human users, they can sit outside normal recertification and offboarding workflows. The architectural problem is persistence without accountability. Once an account is detached from a real owner and a defined purpose, it becomes a hidden access path rather than a managed identity.

Practical implication: bind every service account to an owner, purpose, and expiry condition.

Why broken offboarding turns identity hygiene into a breach control gap

Offboarding is the point where access should be revoked, ownership transferred, or the identity retired. When that process is incomplete, credentials remain valid after the business need has ended, which extends the attack window and undermines least privilege. This is especially damaging in environments where directory objects, application accounts, and PAM-managed access are handled by different teams. The result is not merely poor hygiene but control failure across the identity lifecycle. Continuous remediation matters because stale identities are often the easiest route into systems that otherwise appear well defended.

Practical implication: tie offboarding to revocation, recertification, and owner verification in one workflow.

Threat narrative

Attacker objective: The attacker seeks persistent, credential-backed access to core systems that can be reused for privilege escalation and broader compromise.

1. Entry begins when an attacker finds unmanaged privileged accounts or orphaned service accounts inside core systems that were never fully inventoried or retired.
2. Escalation follows when those identities still carry broad permissions, stale secrets, or implicit trust, allowing the attacker to move from overlooked access into higher-value systems.
3. Impact occurs when hidden credentials are used to maintain access, avoid detection, and expand the blast radius across directories, applications, and administrative planes.

Breaches seen in the wild

• MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

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

NHI Mgmt Group analysis

Identity blind spots are a lifecycle failure before they are a visibility failure. Organisations often treat discovery as the finish line, but discovery without ownership, recertification, and offboarding only creates a longer list of unmanaged identities. The governance problem is that an identity no one owns is already outside control, even if it is still technically visible. Practitioners should treat inventory accuracy and lifecycle accountability as one control domain, not two.

Unmanaged privileged access is the real blast-radius amplifier. Privileged human accounts and service accounts become materially more dangerous once they are detached from regular review, because they preserve administrative reach after business need changes. That is why identity hygiene must be measured by the number of identities with validated scope, not by raw discovery counts. Teams should assume that the largest risk is often the oldest access.

Orphaned service accounts create hidden persistence for attackers. A service account with no clear owner, no expiry condition, and no enforced rotation window is not just clutter. It is a standing credential path that can survive organisational change, application retirement, and staff turnover. The implication is that identity governance has to reach beyond human user reviews and into machine access lifecycle discipline.

Identity blast-radius debt: the longer unmanaged identities remain in core systems, the more their accumulated privileges outgrow the controls originally assigned to them. This is not a tooling problem alone. It is a structural mismatch between identity complexity and governance processes that were never built to keep pace with directory sprawl. Practitioners should reframe remediation around reducing blast radius, not just cleaning up accounts.

Continuous remediation is the control that separates hygiene from assurance. Security programmes that only identify risky identities without closing them create a false sense of progress. The decisive question is whether organisations can remove, re-own, or re-scope identities fast enough to matter. That makes remediation cadence a primary identity security metric, not a back-office activity.

From our research:

• Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs.
• 97% of NHIs carry excessive privileges, which makes blind spots far more dangerous once identities are discovered and left in place.
• For a broader breakdown of lifecycle failure patterns, see 52 NHI Breaches Analysis for the recurring root causes behind exposed identities.

What this signals

Identity blast-radius debt: organisations should expect the cost of hidden accounts to rise faster than the cost of discovery unless they connect inventory to ownership and closure. A visible account that cannot be remediated is still an exposure, not an asset.

The governance signal is clear: identity programmes need tighter coupling between IAM, PAM, and lifecycle processes if they want measurable risk reduction. Where account visibility remains low, the backlog of unowned or stale identities will continue to define the attack surface.

For practitioners building mature controls, the next step is to link continuous discovery to continuous remediation and review the result against Lifecycle Processes for Managing NHIs. That is where hidden risk starts to become governable.

For practitioners

• Inventory every privileged and orphaned identity Reconcile directory accounts, service accounts, and application credentials into a single inventory that records owner, purpose, last use, and business justification.
• Attach lifecycle controls to non-human identities Require provisioning, recertification, rotation, and offboarding for service accounts and API-linked identities using the same governance ownership model as human access.
• Prioritise remediation by privilege and persistence Rank identities by administrative reach, stale ownership, and lack of rotation so the highest-risk blind spots are closed first.
• Align PAM and IGA on shared identity ownership Make privileged account reviews and access certification draw from the same ownership record so PAM and IGA are not operating against different sources of truth.
• Measure remediation latency, not just discovery volume Track how long risky identities remain active after they are identified, because detection without closure leaves the attack window open.

Key takeaways

• Identity blind spots in core systems are a governance failure because discovery without ownership and closure leaves attacker-ready accounts in place.
• Service accounts and privileged identities become high-risk when they persist without recertification, rotation, or clear retirement criteria.
• The right control objective is to shrink exposure windows by linking inventory, ownership, and remediation into one identity lifecycle process.

Key terms

• Identity Blind Spot: An identity blind spot is any gap where an organisation cannot fully see, inventory, or govern an identity and its access rights. Blind spots are especially dangerous for NHIs because they often live in code, pipelines, or third-party integrations outside normal review cycles.
• Orphaned Service Account: An orphaned service account is a non-human identity that still exists and may still have permissions, but no longer has a clear active owner or business purpose. After an acquisition, orphaned accounts are a common source of hidden access because they are easy to forget and hard to trace.
• Identity hygiene: Identity hygiene is the practice of discovering, normalizing, and enriching identity records so governance can rely on them. It reduces ambiguity across directories, platforms, and operational systems, and it makes access review and remediation possible at enterprise scale.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.

What's in the full article

SPHERE's full article covers the operational detail this post intentionally leaves for the source:

• How the article maps unmanaged privileged accounts to real identity hygiene failure points.
• The specific ways Active Directory complexity creates visibility gaps in large environments.
• Why continuous identity discovery matters operationally when remediation workflows are fragmented.
• The article's own framing of ownership and remediation as the practical next steps.

👉 SPHERE's full article covers the identity hygiene gaps, ownership failures, and remediation priorities in more detail.

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.