Service account security best practices for NHI governance

At a glance

What this is: This guide explains why service accounts create a distinct NHI risk profile and identifies persistent access, over-privilege, and stale credentials as the core governance failures.

Why it matters: It matters because IAM teams need controls that distinguish machine behaviour from human activity, reduce blast radius, and surface abuse before automation becomes a hidden persistence path.

By the numbers:

• According to Obsidian Security, organizations typically have 10-20 times more service accounts than human user accounts.

Context

Service accounts are non-human identities that applications and automated processes use to authenticate without human intervention. In this article, Obsidian Security argues that the security problem is not inventory alone, but the way persistent credentials, broad permissions, and weak ownership make these identities easy to abuse.

The governance gap appears when controls designed for human users are applied unchanged to machine identities. Service accounts run continuously, do not produce human-style behavioural signals, and often survive long after the project or team that created them has changed.

For IAM and NHI programmes, the practical question is how to treat service accounts as a governed identity class rather than as implementation residue. That means lifecycle control, credential control, and monitoring have to work together across Active Directory, cloud, and SaaS integrations.

Key questions

Q: What breaks when privileged service accounts are treated like user admin accounts?

A: Governance breaks because service accounts often need uninterrupted machine execution, not manual session approval. If teams apply human-centric PAM patterns to them, they either block operations or create exceptions that reintroduce standing privilege. The result is weak visibility into who or what can still reach critical systems.

Q: Why do privileged accounts and service accounts in Tier 1 create so much more lateral movement risk than Tier 0?

A: Tier 1 usually holds the bulk of privileged user and service accounts, so the attack surface expands far beyond tightly controlled Tier 0 assets. When access rules are inconsistent, local, or hard to apply to mixed infrastructure, attackers can reuse elevated credentials to move sideways between systems and escalate access. That is why tier boundaries must be enforced as a control, not just documented as a design.

Q: What are the signs that a service account is no longer governed properly?

A: Common signs include no named owner, permissions that have not been reviewed, credentials that have not rotated, and activity that no one can explain in the context of the account's purpose. If the account survives project changes and team turnover without reassignment, it is already drifting outside governance.

Q: When should organisations prioritise service account rotation over new monitoring tools?

A: Prioritise rotation first when the environment still relies on static passwords, long-lived tokens, or old API keys, because monitoring can only observe a credential that still exists. If the secret can persist for years, reducing its lifetime usually lowers exposure faster than adding another detection layer.

Technical breakdown

Why service accounts bypass human-centric security controls

Service accounts authenticate applications, scripts, and integrations, so they do not fit the behavioural assumptions behind MFA prompts, geolocation checks, or user activity baselines. They operate continuously and often have no individual operator to challenge or attest to their use. That makes human-centric identity controls a poor fit when the identity subject is a workload or integration rather than a person. In practice, the control problem is not simply access management; it is that the same signal model used for users fails to distinguish legitimate automation from abuse. Practical implication: design detection and access policy around machine identity behaviour, not user behaviour.

Practical implication: Design detection and access policy around machine identity behaviour, not user behaviour.

How persistent privilege turns service accounts into blast-radius amplifiers

Service accounts are often granted broad rights at creation because teams prioritise functionality over precise entitlement design. Those rights then persist, sometimes for years, even when the underlying job only needs a narrow subset of permissions. That creates an outsized blast radius if an attacker compromises the account or if the integration begins to behave unexpectedly. The technical issue is compounded by shared accounts and reused credentials, which blur accountability and make scoping harder. Practical implication: treat every service account as a potential lateral-movement path until its permissions are explicitly constrained and reviewed.

Practical implication: Treat every service account as a potential lateral-movement path until its permissions are explicitly constrained and reviewed.

Why static service account credentials are a standing compromise window

Static passwords, long-lived tokens, and unmanaged keys extend the useful life of any compromise far beyond the moment of theft. In service account environments, rotation is often delayed because dependent systems need coordination, which means stale credentials remain valid long after they should have been retired. That turns credential lifecycle into the primary security boundary. Once a service account secret is embedded in scripts, configuration files, or integration tooling, exposure can persist across multiple environments. Practical implication: align authentication design with short-lived or automatically rotated credentials so compromise does not equal indefinite access.

Practical implication: Align authentication design with short-lived or automatically rotated credentials so compromise does not equal indefinite access.

Threat narrative

Attacker objective: The attacker wants durable, low-noise access that can be reused to move through infrastructure and reach sensitive data without standing out.

1. Entry begins when an attacker obtains a service account credential from a static password, token, API key, or exposed integration secret.
2. Escalation occurs because the account already carries broad permissions, allowing legitimate-looking access across systems without triggering human-centric controls.
3. Impact follows when the attacker uses persistent access to move laterally, access sensitive data, or manipulate infrastructure while appearing to be normal automation.

Breaches seen in the wild

• Dropbox Sign breach 2024: A compromised back-end service account gave attackers Dropbox Sign customer data, including API keys, OAuth tokens and MFA information.
• Kubeflow cryptomining attacks 2020: Exposed Kubeflow dashboards and a notebook's mounted Kubernetes service account let attackers run cryptominers on tens of ML clusters.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Service account governance fails when organisations treat machine identities like disposable implementation detail. The article shows that these accounts outlive projects, owners, and sometimes the staff who created them. That is not an inventory problem alone; it is a lifecycle failure that leaves privileged identities without accountability. For NHI programmes, the discipline is to govern service accounts as durable identities with an owner, a purpose, and an end state.

Standing privilege is the real blast-radius multiplier in service account environments. Obsidian Security's examples make clear that the dangerous condition is not merely that service accounts exist, but that they often begin with broad permissions and never get reduced. This aligns directly with OWASP-NHI and NIST-CSF thinking: the exposure grows when entitlement scope is wider than function. Practitioners should treat permission review as a security boundary, not a housekeeping task.

Credential rotation is an identity control, not an operational chore. The article's emphasis on unchanged passwords and long-lived tokens shows why stale service account credentials behave like dormant backdoors. When rotation is deferred because dependencies are hard to coordinate, the organisation has already accepted an extended compromise window. The implication for IAM and PAM teams is that service account credential lifecycle has to be governed with the same seriousness as privileged human access.

Hidden automation requires hidden visibility controls: service accounts do not announce themselves through working hours, travel patterns, or other human markers. That makes behavioural context essential, but only when it is tied to the identity's expected task profile. The field should stop assuming that no alert means no risk. Practitioners need monitoring that distinguishes expected machine repetition from anomalous data access or new system reach.

Service account security is now an NHI governance baseline, not a specialist subtopic. The article spans discovery, ownership, rotation, least privilege, and detection, which means the control plane crosses IAM, PAM, and secrets governance. The named concept here is standing credential drift: credentials and permissions remain active long after the original operational need has changed. The practical conclusion is that NHI programmes must measure drift, not just count accounts.

From our research library:

• NHIs outnumber human identities by 25x to 50x in modern enterprises, according to the Ultimate Guide to NHIs.
• 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time, according to the Ultimate Guide to NHIs.
• Read next: NHI Lifecycle Management Guide

What this signals

Standing credential drift: service accounts become materially harder to govern when passwords, tokens, and permissions outlive the business purpose that created them. The operational answer is not more inventory alone, but lifecycle control that keeps ownership, entitlement scope, and credential expiry moving together.

The article's real signal for practitioners is that machine identity security now sits at the intersection of IAM, PAM, and secrets governance. Teams that still separate those responsibilities will keep missing the moment when legitimate automation turns into an abuse path.

The governance standard is shifting from knowing whether a service account exists to knowing whether its current access still matches its actual function. That is the control boundary NHI programmes need to watch most closely.

For practitioners

• Inventory every service account across AD, cloud, and SaaS Map each account to a business function, a technical owner, and a dependency set so orphaned identities are visible before they become incidents.
• Remove standing admin rights from service accounts Start with zero access, then add only the permissions each workload demonstrably needs, using boundaries and scoped roles to prevent privilege creep.
• Replace static secrets with managed rotation Move Windows service accounts to gMSAs where possible, use temporary cloud roles instead of permanent keys, and enforce automated rotation for anything that must remain secret.
• Block interactive login for service accounts Prevent human sign-in paths and alert on any attempted interactive authentication because a workload identity should only be usable in its designed execution context.
• Build behavioural baselines for machine identities Watch for new data sets, unusual timing, volume spikes, and integration paths that do not match the account's documented purpose.

Key takeaways

• Service accounts are a distinct NHI risk class because they combine persistent access, excessive privilege, and credentials that can remain valid far beyond the original business need.
• The scale of the problem is significant, with organisations typically managing far more service accounts than human users and many credentials remaining unchanged for years.
• The control answer is to govern lifecycle, ownership, privilege scope, rotation, and behavioural monitoring as one programme rather than as separate hygiene tasks.

Key terms

• Service Account: A special-purpose account used by applications, automated tools, or services rather than a human user to interact with systems, APIs, and infrastructure. Service accounts are a primary category of NHI and one of the most frequently exploited attack vectors.
• Standing Privilege: Standing privilege is access that remains active even when no immediate task requires it. For NHI programmes, it is a common failure mode because long-lived credentials and persistent roles create unnecessary exposure. Reducing standing privilege usually means tighter expiry, on-demand access, and clearer review of who or what still needs access.
• Credential Rotation: The practice of regularly replacing secrets and credentials with new values to limit the window of exposure if a credential is compromised. Automated rotation, enforced by policy, is the security-optimal approach.
• Behavior Baseline: A record of normal activity for a non-human identity, including typical consumers, resources, and actions over time. Baselines help security teams detect when an identity is being used in an unusual way and provide the context needed to enforce least privilege safely in dynamic environments.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.