Service account governance.

Definition

A service account is a user-like identity created in a directory (Active Directory, LDAP, Linux, a database, or a cloud IAM system) for the purpose of authenticating an application, daemon, or automated process, not a human user. It is the oldest and most numerous category of non-human identity in most enterprises.

Varieties of service account

• Active Directory service accounts, the largest category in most Windows-dominant enterprises. Includes "managed service accounts" (MSA) and "group managed service accounts" (gMSA), both of which handle password rotation automatically and are a substantial improvement over plain AD service accounts.
• Linux service accounts, local Unix accounts or directory-integrated LDAP accounts under which daemons run. Typically authenticated with a keypair rather than a password.
• Database service accounts, accounts in Oracle, SQL Server, PostgreSQL, MySQL, MongoDB, or Snowflake that applications use for database access. Often the highest-risk category because of the data access they grant.
• Cloud-native service accounts, GCP Service Accounts, AWS IAM service-account-like constructs, Azure managed identities. These are the fastest-growing category.
• Kubernetes service accounts, covered separately in our taxonomy; they are service accounts scoped to a Kubernetes cluster.
• SaaS "integration users", a user-style account in a SaaS platform (Salesforce, ServiceNow, Workday) created for an integration. Similar pattern, different host.

Top service-account risks

1. Stale accounts (OWASP NHI1)

Service accounts created for applications that no longer exist. Active Directory in a typical large enterprise contains hundreds to thousands of stale service accounts. Each is a live credential that could be compromised and used.

2. Shared or static passwords (OWASP NHI7)

A service account password set at creation and never changed. Found in configuration files, runbooks, Slack messages, and password managers across the organisation. Password rotation is often avoided because "the application will break", which it will, unless the rotation is choreographed with the application's credential-retrieval pattern.

3. Over-privilege (OWASP NHI5)

Service accounts often accumulate permissions because "it's easier to grant admin and move on." In Active Directory specifically, Domain Admin membership for a service account is a common path from application compromise to full domain compromise.

4. Human use of service accounts (OWASP NHI10)

Humans logging in as service accounts to perform operational tasks. This breaks the identity principle (who did what, when) and exposes the service-account credential to human-access risk patterns like typing it into the wrong window.

5. Password exposure in code and configs

Service-account passwords hardcoded in code, embedded in scripts, or sitting in plaintext configuration files, the secret-leakage pattern (OWASP NHI2) applied to the classical category.

A service-account governance programme

The same seven capabilities from the NHI management page apply, with service-account specifics:

• Inventory: extract service-account lists from Active Directory (filter by naming convention, by password-never-expires flag, by specific OU), from /etc/passwd on Linux hosts, from database user catalogues, from SaaS integration-user lists. Reconcile with a CMDB of applications.
• Ownership: every service account has a named owner. Orphaned ones are decommissioned. The naming convention encodes the owning application.
• Credentials: passwords move to a centralised secret store; rotation is scheduled and automated. On Active Directory, adopt gMSA where supported; for everything else, secret-store integration handles rotation.
• Privileges: right-sized at creation; annual review for the most privileged; remove local admin, remove Domain Admin, remove broad database roles.
• Lifecycle: decommissioning tied to application retirement in the CMDB. Inactive service accounts (no logon in 90 days) are flagged.
• Monitoring: behavioural baselining. A service account that has logged on from the same server for two years and suddenly logs on from elsewhere is a high-confidence signal.
• Human-use prevention: block interactive logon for service accounts; break-glass human use is logged separately.

Active Directory service account specifics

AD has specific features that matter for service-account governance:

• Managed Service Accounts (MSA) and Group Managed Service Accounts (gMSA), introduced in Windows Server 2008 R2 and 2012 respectively. AD manages the password for you, rotating it automatically. This is the recommended default for any new Windows service-account use case that supports it.
• "Password never expires" flag, historically set to avoid breakage, this creates permanently stale credentials. Inventory queries that filter by this flag often surface the highest-risk accounts in the environment.
• Service Principal Names (SPNs), the mechanism by which Kerberos authentication binds a service to an account. Misconfigured SPNs are a common exploitation vector (Kerberoasting).
• Tiered administration model, Microsoft's guidance for separating service accounts by privilege tier to prevent credential-theft pivots.

Cloud service accounts

Cloud providers call them different things:

• Google Cloud Platform, explicitly called "service accounts"; they have email-like identifiers (myapp@project.iam.gserviceaccount.com) and can use JSON key files or attached identity tokens.
• AWS, the most-analogous concept is an IAM role, assumed by a workload. AWS also has IAM users (a human-like construct that can be used for applications but is discouraged).
• Azure, "service principals" for app-based identities and "managed identities" for workload-bound identities. Managed identities are the recommended modern default.

Cloud service accounts generally have better hygiene than classical directory service accounts, they are newer, the tooling is newer, and cloud providers have pushed customers toward short-lived credentials and workload-bound identities. However, the classical failure patterns (over-privilege, orphans, unused) still apply.

Migrating off service accounts

Where possible, the modern pattern is to replace service accounts with workload identities, identities bound cryptographically to the running workload rather than carried as a static credential. The migration paths:

• Windows workloads → gMSA, then → Workload Identity Federation to Azure / Entra ID
• Linux workloads → SPIFFE/SPIRE issuing SVIDs, or cloud-native workload identity federation
• Kubernetes workloads → service account token projection with OIDC-based federation to cloud IAM
• Database access → short-lived credentials issued by HashiCorp Vault or cloud-native secrets managers
• SaaS integrations → OAuth (service-to-service patterns) in place of shared integration users where the SaaS supports it

Migration is slow and pragmatic. Most enterprises will run hybrid models for years. The important thing is to stop creating new static-credential service accounts for use cases that have a workload-identity alternative.

Frequently asked questions

What is service account management?

Service account management is the practice of controlling accounts used by applications, scripts and services rather than by people: knowing which exist, who is accountable for each, what each may access, and how their credentials are issued and rotated. It is the oldest and most familiar part of non-human identity governance, and in most organisations it is where an NHI programme starts because service accounts are already visible in directories.

How do you audit service accounts?

Start with an inventory export that includes owner, last-use timestamp, privilege level and credential age. Then run four tests: sample leavers from the last twelve months and trace the accounts they created, list accounts with no recorded use in ninety days, list accounts with non-expiring credentials, and check whether service accounts appear in access-review campaigns at all. The last test fails in nearly every first audit.

What is a good service account naming convention?

Encode the information a future responder needs when the creator is unavailable: a clear non-human prefix so the account is never mistaken for a person, the owning team or system, and the purpose. Avoid encoding environment or privilege level in the name, because those change while names rarely do. The convention matters less than enforcing it at creation, since retrofitting names across an existing estate is rarely worth the disruption.

What are the alternatives to service accounts?

For workloads, runtime-attested identity is the modern alternative: cloud workload identity federation, Kubernetes projected tokens, and SPIFFE-issued SVIDs all let a workload prove what it is without holding a static credential. For scheduled tasks and integrations, managed identities and short-lived tokens issued on demand replace the standing account. The general direction is away from accounts that persist and toward credentials that are minted per use.

What are service account governance best practices?

Five that consistently matter: every account has a named individual owner rather than a team, every credential has an expiry, privileges are scoped to observed usage rather than requested usage, unused accounts are retired automatically past a defined threshold, and exceptions are registered with an approver and a review date. The fifth is the one most often skipped and the one that turns a policy breach into a governance decision.

Are service accounts the same as non-human identities?

No. A service account is the oldest and most common type of non-human identity, but the NHI umbrella also covers API keys, OAuth tokens, cloud IAM roles, Kubernetes service accounts, certificates, SSH keys, workload identities and AI agents. Treating the two as synonymous is a common scoping error, because it leaves the fastest-growing categories outside the programme.