A Ghost SPN is a service principal name in Active Directory that points to a hostname that no longer resolves in DNS. It matters because the identity record still exists and can be abused to redirect authentication, even when the underlying service is gone.
Expanded Definition
A Ghost SPN is an Active Directory service principal name that still exists in directory metadata after the hostname it references no longer resolves in DNS. The identity is therefore “alive” to Kerberos and directory lookups even though the service behind it is gone. In practice, that makes the SPN a stale but still trusted authentication target.
This matters because SPNs are used to map services for Kerberos authentication, delegation, and service discovery. A Ghost SPN is not just orphaned inventory; it can become an identity control gap if another host later claims the same name, if DNS is misconfigured, or if attackers register a conflicting service path. Definitions vary across vendors when they describe adjacent issues such as orphaned SPNs, stale service accounts, or unresolved service records, but the security concern is the same: directory truth no longer matches runtime truth. For background on broader NHI lifecycle risk, see the Ultimate Guide to NHIs and Microsoft’s Kerberos service principal name guidance.
The most common misapplication is treating the SPN as harmless because the service is offline, which occurs when directory cleanup is not tied to DNS validation and service decommissioning.
Examples and Use Cases
Implementing SPN hygiene rigorously often introduces change-control overhead, requiring organisations to weigh authentication stability against the cost of continuous cleanup.
- A Windows file service is retired, but its SPN remains bound to a service account. Months later, ticket requests still target that identity, creating ambiguity during incident response.
- A load-balanced application is renamed during migration, leaving the old SPN behind. If DNS later reuses the old hostname, the stale SPN can complicate Kerberos routing and service ownership.
- An admin disables a server without removing service principal records. The identity appears inactive in operations tooling, yet it remains part of the directory attack surface.
- An environment with poor service-account visibility, described in NHIMG research as having only 5.7% full visibility into service accounts, can accumulate Ghost SPNs unnoticed. See the Ultimate Guide to NHIs.
- During a service migration, teams validate hostname ownership against DNS and service records using the principles in the NIST Cybersecurity Framework 2.0, reducing the chance that stale identity artifacts are left behind.
Why It Matters in NHI Security
Ghost SPNs are dangerous because they preserve trust where operational reality has changed. That mismatch can undermine Kerberos integrity, obscure accountability, and provide attackers with a foothold for confusion, redirection, or privilege misuse if related service accounts are weakly governed. In NHI programs, stale identities are often the first sign that offboarding, rotation, and decommissioning are not aligned. NHIMG research shows that only 20% of organisations have formal processes for offboarding and revoking API keys, and the same lifecycle gap commonly affects service identities; the broader Ultimate Guide to NHIs also notes that 71% of NHIs are not rotated within recommended time frames, reinforcing how quickly stale trust accumulates.
From a governance perspective, Ghost SPNs should be treated as evidence that identity inventory and runtime dependency mapping are out of sync. The response is not just deletion, but validation of what depends on the record, who owns it, and whether the service is truly gone. Practitioners should align this work with NIST Cybersecurity Framework 2.0 practices for asset management, access control, and detection. Organisations typically encounter the risk only after authentication errors, service ticket anomalies, or an incident review exposes an identity that should have been retired, at which point the Ghost SPN becomes operationally unavoidable to address.
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 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Covers stale or unmanaged NHI secrets and identity artifacts that increase attack surface. |
| NIST CSF 2.0 | ID.AM-1 | Asset inventories must reflect live services, not orphaned directory objects. |
| NIST Zero Trust (SP 800-207) | PE | Zero Trust assumes explicit verification, which stale SPNs can undermine through trust drift. |
Continuously validate service identity bindings so retired hosts cannot retain or inherit authentication trust.
