How do security teams know whether SPN-enabled accounts are actually protected?

They know protection is working when SPN-enabled accounts are inventoried, owned, screened for breached passwords, and recertified on a regular schedule. A healthy programme also shows reduced privilege on service identities and visible alerts when a password is rejected or exposed. If none of those signals exist, the account is probably still a Kerberoasting target.

Why This Matters for Security Teams

SPN-enabled accounts often look like ordinary service identities until they are abused for Kerberoasting, lateral movement, or privilege escalation. The real question is not whether an account exists, but whether it is continuously governed with ownership, rotation, monitoring, and recertification. NHI Management Group’s Ultimate Guide to NHIs notes that 97% of NHIs carry excessive privileges, which makes “protected” a misleading label unless the account is actively constrained.

Security teams should treat protection as a set of observable signals, not a claim in a spreadsheet. If the account is not inventoried, tied to a named owner, checked for breached passwords, and reviewed on a schedule, then the attack surface is still intact. The NIST Cybersecurity Framework 2.0 reinforces this by tying identity protection to continuous risk management, not one-time setup.

In practice, many security teams discover service-account weakness only after an alert, an incident, or an external disclosure forces the review.

How It Works in Practice

A protected SPN-enabled account has four visible properties: it is owned, it is monitored, it is rotated, and its permissions are tightly scoped. Ownership means the account has a business or technical custodian who can approve use and respond to findings. Monitoring means the account is covered by logging, alerting, and password exposure checks so abnormal use does not pass quietly. Rotation means the credential is changed on a defined schedule or after risk triggers, not left in place indefinitely. Scoped permissions mean the account cannot read more data, reach more systems, or request more tickets than it actually needs.

Security teams can validate this through simple control tests:

• Confirm every SPN-enabled account appears in an authoritative inventory with a named owner.
• Verify the password is screened against breached-password intelligence and alerting is enabled for rejection or exposure events.
• Check whether the account is exempt from rotation, and if so, whether that exception is formally approved and time bound.
• Review effective permissions in the directory, application, and host layers, not just the role label.
• Require regular recertification so dormant or orphaned service identities are removed or remediated.

This is also where NHI-specific guidance matters. The State of Non-Human Identity Security reports that lack of credential rotation is the top cause of NHI-related attacks, cited by 45% of organisations. That finding aligns with NIST SP 800-53 Rev 5 Security and Privacy Controls, which expects access and credential controls to be implemented and monitored as part of ongoing security operations.

These controls tend to break down in large Active Directory estates with legacy service accounts, shared ownership, and no central telemetry because the account can keep authenticating long after the business owner has lost track of it.

Common Variations and Edge Cases

Tighter SPN governance often increases operational overhead, so teams have to balance service availability against reduction in credential risk. That tradeoff is especially visible when applications depend on old authentication patterns, hard-coded passwords, or vendor-managed services that are difficult to rotate.

There is no universal standard for every SPN implementation yet, so current guidance suggests separating “cannot rotate” from “has not been rotated.” A true exception should be documented, risk-accepted, and periodically reviewed. If an account cannot support normal rotation, then compensating controls become mandatory: stronger monitoring, restricted network paths, limited delegation, and faster incident detection.

Service accounts used by third parties deserve extra scrutiny. NHI Management Group research has shown that many organisations still lack full visibility into service identities, which makes ownership and recertification harder to prove. The Schneider Electric credentials breach is a reminder that credential exposure can become material quickly when service identities are not adequately contained.

In practice, the weakest cases are shared SPN accounts, accounts with no clear owner, and environments where monitoring exists but no one is accountable for acting on the alerts.

Related resources from NHI Mgmt Group

• How do security teams know whether collaboration governance is actually working?
• How do security teams know whether an IAM backup is actually useful?
• How do security teams know whether runtime secrets are actually protected?
• How do security teams know whether SPN modifications are actually working as a control?