Should organisations treat service account risk as part of AD hardening or NHI governance?

Why this is both an AD hardening issue and an NHI governance issue

service account sit at the intersection of directory security and identity governance. In Active Directory, they can be the mechanism attackers abuse to move laterally, persist, or expand privilege. In NHI governance, they are identities that need ownership, inventory, lifecycle control, and review like any other non-human actor with access to critical systems.

The practical distinction is scope, not ownership of the problem. AD hardening focuses on reducing exposure inside the directory, while NHI governance answers who owns the account, why it exists, what it can access, how it is authenticated, and when it should be rotated or removed.

For teams trying to separate responsibilities, the right test is whether the control changes the directory attack surface or the identity lifecycle. If it reduces privilege, disables risky AD behaviors, or constrains authentication paths, it belongs in hardening. If it governs account creation, naming, ownership, secrets, and offboarding, it belongs in NHI governance, even when the account is anchored in AD.

What service account risk looks like in practice

Service account risk is usually not a single failure. It is a cluster of conditions: stale accounts, overprivileged roles, shared ownership, weak secret handling, and poor visibility into where the account is used. Those conditions matter because service accounts often bridge systems, so compromise can have a wider blast radius than a normal user account.

Attackers value these accounts because they are often exempted from normal user workflows. A long-lived password, a reused secret, or an account with domain-level access can turn one weak point into broad access across applications, databases, and AD-connected services. That is why service account security guidance is not just a hardening topic, but also a governance topic.

Directory hardening should focus on reducing classic abuse paths such as interactive logon, unconstrained delegation, weak service principal name hygiene, and excessive rights. Governance should focus on whether the account is still needed, whether a business owner exists, and whether the credential lifecycle is controlled. When those controls are split, the account becomes both technically exploitable and organisationally invisible.

How to decide which control owner should lead

The cleanest operating model is shared responsibility with a primary owner for each control type. AD or directory engineering should own the platform settings, authentication restrictions, and baseline hardening. IAM or NHI governance should own inventory, ownership, recertification, rotation policy, and retirement of the account. Application teams should own the business justification for the account and the systems that depend on it.

A useful decision rule is this: if the remediation changes an AD configuration, it belongs with directory hardening; if the remediation changes account lifecycle or entitlement, it belongs with NHI governance. That separation prevents the common failure where a team hardens the domain but leaves orphaned, overprivileged service accounts untouched.

This is also where the broader identity model matters. Service accounts are not just “technical accounts”, they are identities with permissions, dependencies, and accountability. NHIMG’s IAM and IGA Basics is useful here because the question is really about where authorization and governance end, and where directory enforcement begins.

Risk and Threat Considerations

Service accounts create concentrated risk because they often have broad, durable access and weak human oversight. If one is stolen, reused, or left active after a system change, an attacker may gain a stable path into AD-connected services, not just a single application.

Failure mechanism: Long-lived credentials, shared usage, and excessive privileges let an attacker convert one compromised service account into persistence, lateral movement, or delegated access across multiple systems.

Impact: The result can be domain-wide exposure, hidden access that survives normal user offboarding, and a much larger incident scope than the original account suggests.

Practitioner Guidance

What to prioritise: Start with the service accounts that can authenticate to production systems, administer directories, or touch secrets stores. Those are the accounts whose compromise changes both AD security and business impact most quickly.

What to verify: Confirm that every service account has an owner, a documented purpose, a known dependency chain, and a defined rotation or retirement path. If any one of those is missing, treat the account as both a hardening gap and a governance gap.

Common mistake: Teams often harden the directory and assume the risk is solved. In practice, the dangerous accounts are the ones that remain technically functional but organisationally unmanaged, especially where shared credentials or legacy integrations make rotation hard.

Practitioner takeaway: Treat service accounts as identities first and implementation details second, then split the work so AD hardening reduces exposure while NHI governance removes unmanaged privilege and stale lifecycle risk.

Related resources from NHI Mgmt Group

• When should organisations treat an NHI as a high-priority risk?
• When should organisations treat NHI governance as part of ransomware defense?
• Should organisations treat developer tooling as part of NHI governance?
• Should organisations separate service account management from broader NHI governance?