Who is accountable when a Ghost SPN leads to SYSTEM access?

Why This Matters for Security Teams

A Ghost SPN that reaches SYSTEM is not just an access-control mistake. It shows that identity lifecycle, Active Directory delegation, DNS permissions, and host hardening were allowed to drift until a dormant or misbound service principal could be coerced into privileged execution. This is why NHI governance matters: NHIs now outnumber human identities by 25x to 50x, and Ultimate Guide to NHIs notes that only 5.7% of organisations have full visibility into service accounts.

The real question is accountability across control planes. AD owners are responsible for SPN creation, ownership, and offboarding. Infrastructure teams are responsible for DNS write restrictions and coercion paths. Platform and endpoint teams are responsible for SMB signing, relay resistance, and local privilege boundaries. If any one layer assumes another team owns the risk, a Ghost SPN can become a privilege escalation path that is invisible until it is weaponised. The pattern is well aligned with the abuse patterns described in the OWASP Non-Human Identity Top 10.

In practice, many security teams discover the accountability gap only after an attacker has already chained directory abuse into SYSTEM access, rather than through intentional review of SPN ownership and DNS delegation.

How It Works in Practice

Operationally, accountability should be mapped to the control that can actually prevent the abuse. A Ghost SPN typically involves a service principal name that exists in directory records but no longer corresponds to an active, well-governed workload. If that identity can still authenticate, be impersonated, or be coerced through name resolution and relay conditions, then it has become a standing risk. Current guidance suggests treating SPN lifecycle as an NHI control, not a one-time directory cleanup task. The core issue is not just whether the SPN exists, but whether it is owned, monitored, and bounded by least privilege.

Practical control ownership usually breaks down into three lanes:

• Directory administration: track SPN ownership, remove orphaned entries, and review service account scope against actual workload need.

• Infrastructure and DNS administration: restrict who can write DNS records, delegate only necessary zones, and monitor for coercion paths that can redirect privileged authentication.

• Server and platform hardening: enforce SMB signing, disable insecure relay conditions where possible, and require protections that reduce impersonation-to-SYSTEM chains.

The strongest programs tie this to evidence, not policy intent. NHI Management Group’s Ultimate Guide to NHIs — Key Challenges and Risks highlights why visibility and rotation failures persist, while the 52 NHI Breaches Analysis shows how identity sprawl turns into real incidents when ownership is unclear. Teams should reconcile SPNs to active workloads, validate DNS delegation rights, and require explicit closure for retired services.

These controls tend to break down when legacy Windows services, broad admin delegation, and weak change management allow SPNs to persist after the workload they were meant to support has already been decommissioned.

Common Variations and Edge Cases

Tighter SPN and DNS control often increases operational overhead, requiring organisations to balance exposure reduction against service continuity and admin friction. That tradeoff is unavoidable in environments with many legacy Windows applications, clustered services, or vendor-managed integrations. Best practice is evolving, but current guidance is clear that orphaned identities should not remain trusted simply because removal is operationally inconvenient.

One edge case is shared service accounts. They can make ownership ambiguous, which weakens accountability when an exploit path is found. Another is hybrid directory design, where on-premises AD, cloud identity, and DNS management are split across teams. In those environments, the accountable party is usually the team that can prove effective control over the vulnerable boundary, not the team that merely approves policy. The OWASP Non-Human Identity Top 10 is useful here because it frames the failure as an identity governance issue, not only an exploit chain.

Another common exception is emergency access. Temporary privileges can be justified, but they should not become permanent SPN exceptions. If a Ghost SPN persists because nobody wants to break a business-critical workload, the organisation has already accepted hidden standing privilege. In those cases, accountability should be assigned to the control owner who can retire, rotate, or re-architect the identity, not merely to the incident responder who finds it later.

Related resources from NHI Mgmt Group

• Who should be accountable when a compromised mailbox leads to fraud or access loss?
• Who is accountable when an autonomous system acts on access decisions?
• Who is accountable when an exposed DevOps secret leads to unauthorised access?
• Who is accountable when sustained infrastructure attacks disrupt access and availability?