A condition where two objects contend for the same SPN or a confusable variant of it. Because Kerberos relies on SPNs to resolve which account owns a service key, a collision can misdirect tickets, break service access, or enable privilege escalation if write rights are too broad.
Expanded Definition
service principal Name collision occurs when two directory objects register the same SPN or a confusable variant that resolves ambiguously during Kerberos service ticket issuance. In practice, the directory becomes the source of truth for which account holds the service key, so an SPN collision can divert authentication to the wrong principal, break the service, or create an escalation path if the competing object is writable by an attacker or overly privileged operator.
Within NHI governance, this is not just a naming error. It is an identity binding failure that affects service authentication, delegation, and auditability. The issue is closely related to how service accounts are inventoried, how registrations are delegated, and how change control prevents duplicate object creation. NIST SP 800-53 Rev 5 Security and Privacy Controls emphasizes control discipline around identity lifecycle and access enforcement, which is directly relevant when SPNs are assigned, reviewed, or remediated. The most common misapplication is treating SPN uniqueness as a one-time provisioning check, which occurs when teams do not continuously scan for duplicates after directory changes, mergers, or automated app deployments.
Examples and Use Cases
Implementing SPN governance rigorously often introduces administrative overhead, requiring organisations to weigh faster application onboarding against tighter directory hygiene and collision prevention.
- A Windows service is redeployed under a new account, but the old account keeps the same SPN, causing Kerberos to issue tickets unpredictably until the duplicate is removed.
- An automation pipeline creates service accounts at scale and accidentally reuses a template SPN, producing a collision that is hard to trace without directory-wide reporting.
- A delegated admin with write access to service account attributes registers a lookalike SPN and intercepts traffic intended for a legitimate service.
- A blue team uses the guidance in the Ultimate Guide to NHIs to map service account ownership before approving SPN changes.
- Security engineering validates service principal registration patterns against NIST SP 800-53 Rev 5 Security and Privacy Controls to ensure the account lifecycle is reviewable and access is constrained.
Collisions also surface during migration projects, especially when legacy applications are moved into new domains, forests, or automation frameworks without a clean ownership model.
Why It Matters in NHI Security
SPN collision is a high-impact NHI failure because it undermines trust in service identity itself. If defenders cannot prove which account legitimately owns a service endpoint, they cannot reliably enforce least privilege, delegation boundaries, or incident containment. The problem becomes more severe when service accounts are overprivileged or poorly visible. NHI Mgmt Group reports that only 5.7% of organisations have full visibility into their service accounts, and 97% of NHIs carry excessive privileges, which means SPN errors often go undetected in environments already lacking strong control discipline.
In practical terms, SPN collisions can cause outage conditions, authentication failures, or silent redirection of Kerberos traffic to an unintended principal. They also complicate forensic analysis because ticket issuance may appear valid even when the owning account is wrong. The same NHI lifecycle problems highlighted in the Ultimate Guide to NHIs and the broader NHI governance discussion amplify this risk when ownership, rotation, and offboarding are inconsistent. Organisations typically encounter the damage only after an authentication incident, at which point SPN collision 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 and CSA MAESTRO address the attack and risk surface, while NIST SP 800-53 Rev 5, NIST Zero Trust (SP 800-207) and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | SPN collisions stem from weak NHI inventory and identity binding controls. |
| NIST SP 800-53 Rev 5 | AC-2 | Account lifecycle control applies to service accounts that own SPNs. |
| NIST Zero Trust (SP 800-207) | SC-23 | Zero Trust depends on unambiguous service identity and endpoint authenticity. |
| NIST CSF 2.0 | PR.AC-1 | Access management requires uniquely assigned and governed service identities. |
| CSA MAESTRO | Agent and service identity assurance requires collision-free credentials and bindings. |
Continuously inventory service principals and remove duplicate registrations before they affect authentication.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 11, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
