What is the difference between HOST SPNs and custom SPNs?

Why This Matters for Security Teams

HOST SPNs and custom SPNs are both service identity bindings, but they create very different operational risks. HOST SPNs are part of the platform-managed identity surface, while custom SPNs are usually a sign that a service has its own explicit authentication and delegation needs. That distinction matters because mistakes in SPN ownership often become authentication outages, duplicate SPNs, or unintended privilege exposure.

Security teams also need to separate identity inventory from service behavior. In practice, unmanaged service identities are a common blind spot, and NHI Mgmt Group notes that only 5.7% of organisations have full visibility into their service accounts in the Ultimate Guide to NHIs — What are Non-Human Identities. That makes SPN hygiene more than an AD housekeeping task. It is part of knowing which machine identities exist, who owns them, and whether they still match the service they represent.

For a broader control baseline, the NIST Cybersecurity Framework 2.0 reinforces the need to identify, govern, and monitor identity assets consistently across the environment.

In practice, many security teams encounter SPN drift only after authentication breaks, service tickets spike, or a duplicate registration has already disrupted production.

How It Works in Practice

Think of a HOST SPN as the default identity mapping Windows expects for standard host-bound services. It is typically associated with the computer account and is commonly used when the service runs under local system or network service context. Because AD manages these registrations, the practical rule is simple: do not hand-edit HOST SPNs unless you are correcting a documented directory issue. Manual changes can create collisions or break built-in service resolution.

Custom SPNs work differently. They are registered when a service runs under a domain user account, a gMSA, or a design where multiple hosts need to present the same service name. That means the team operating the service owns the identity lifecycle too: registration, uniqueness checks, decommissioning, and periodic review. This is where directory hygiene becomes an identity governance task, not just an AD admin task.

• Use HOST SPNs for standard Windows host services that should follow the machine account.
• Use custom SPNs when the service account is separate from the computer account or when the service is shared across multiple hosts.
• Check for duplicates before registration, because duplicate SPNs can cause Kerberos failures or unpredictable ticket issuance.
• Treat SPN cleanup as part of service offboarding so abandoned registrations do not remain reachable.

For identity governance context, the Ultimate Guide to NHIs — What are Non-Human Identities is useful because SPNs are only one part of the wider non-human identity footprint that also includes service accounts, API keys, and other machine credentials. Current guidance suggests mapping SPN ownership to the service owner and validating it during access reviews, because directory rights alone do not prove operational accountability. These controls tend to break down when multiple teams reuse the same service account across environments because ownership and change control become ambiguous.

Common Variations and Edge Cases

Tighter SPN governance often increases operational overhead, requiring organisations to balance service uptime against directory control. The main edge case is when a service seems to “need” a custom SPN but is actually misconfigured and could run safely under the computer account. Another is legacy applications that hard-code a service principal name and cannot be modernised quickly. In those cases, best practice is evolving, but the safe pattern is still to document the exception, limit the account scope, and review it regularly.

There is also no universal standard for when to migrate from custom SPNs to a more constrained identity pattern, but the direction of travel is clear: reduce long-lived, manually managed bindings where possible. For teams building service governance around broader NHI risk, this aligns with the control intent highlighted in the NIST Cybersecurity Framework 2.0, especially where identity inventory and monitoring are concerned.

The biggest practical gotcha is that custom SPNs are often left behind during application replacement or domain restructuring. That creates stale identity records that can confuse troubleshooting and, in some cases, expose services to unintended reuse. In mature environments, SPN review is treated like credential hygiene: owned, scheduled, and tied to change management rather than handled ad hoc.

Related resources from NHI Mgmt Group

• What is the difference between configuration-based alias management and custom-coded alias handling in IAM?
• What is the difference between a configurable IAM platform and one that depends on custom development?
• What is the difference between an MCP host, client, and server?
• What is the difference between privilege reduction and secret rotation?