Service Account Security Guide: Finding, Reducing and Governing Service Accounts

Service accounts are the oldest and most common non-human identity, and still one of the most exploited. They run scheduled jobs, connect applications to databases, integrate SaaS platforms and hold standing access to production systems. Many were created years ago, have passwords that never change, belong to nobody and have far more privilege than they need. This guide covers service accounts across Active Directory, cloud platforms, SaaS and databases: the risks, how to find them, how to reduce their privilege and credentials, and how to govern them through their lifecycle.

Key takeaways

• A service account is an account used by software rather than a person. It exists in directories, cloud platforms, SaaS applications, databases and operating systems, often with different names and controls in each.
• The recurring problems are no owner, excessive privilege, passwords or keys that never rotate, interactive use by humans and accounts that outlive their purpose.
• Replace passwords and static keys with platform-managed identities wherever the platform supports them: group managed service accounts, cloud workload identities and federation.
• Govern service accounts like privileged identities: inventory, ownership, least privilege, monitoring, periodic review and decommissioning.

Where service accounts live

For cloud and Kubernetes specifics, see our Cloud Workload Identity Guide and Kubernetes NHI Security Guide.

Why service accounts are targeted

• Privilege without scrutiny: they often hold broad, standing access that no one reviews.
• Weak or static authentication: passwords that never change, cannot use MFA and are stored in scripts and configuration.
• Low visibility: activity is expected to be constant, so misuse blends in.
• Lateral movement: one service account is often trusted by many systems.

Real incidents show the pattern. In the Midnight Blizzard breach, attackers abused a legacy test OAuth application to gain elevated access in Microsoft's corporate environment. In the Okta support system breach, a service account's credentials were involved in access to the support case system. The Uber breach escalated through privileged credentials found in scripts. OWASP lists the underlying problems as NHI1 Improper Offboarding, NHI5 Overprivileged NHI, NHI7 Long-Lived Secrets and NHI10 Human Use of NHI in its Non-Human Identities Top 10.

Finding service accounts

• Directory queries: accounts with non-expiring passwords, service principal names, "svc" naming conventions, no recent interactive logon, or membership of service groups.
• Cloud inventories: IAM users with access keys, roles, service principals, managed identities and service accounts across every account, subscription and project.
• Behavioural analysis: accounts that authenticate on fixed schedules, from servers, without interactive sessions.
• Configuration and code: connection strings, scheduled tasks, service definitions, CI/CD variables and secrets managers reveal which accounts applications use.
• SaaS admin consoles: integration users, API users and connected apps.

Record each account's platform, purpose, owner, privileges, authentication method, credential age, where the credential is stored and last activity. The NHI Lifecycle Management Guide covers inventory and ownership in more depth.

Reducing credential risk

1. Use platform-managed identities. On Windows, group managed service accounts rotate their own passwords. In the cloud, managed identities, IAM roles and attached service accounts remove stored credentials altogether. For workloads outside a cloud, use workload identity federation. See the NHI Authentication Guide.
2. Vault what remains. Where a password or key is unavoidable, store it in a secrets manager or PAM vault, never in scripts or configuration files. See the Secrets Management Guide.
3. Rotate automatically. Rotate on a schedule and immediately after exposure, with dependencies mapped first so rotation does not break production. Our guide to NHI rotation challenges covers the pitfalls.
4. Use strong encryption. For Active Directory accounts with service principal names, use long random passwords and AES Kerberos encryption to resist Kerberoasting.

Reducing privilege

• Remove service accounts from Domain Admins, Global Administrator, Owner and other broad administrative groups unless strictly required.
• Grant permissions to the specific resources and actions each service uses; replace wildcard cloud policies.
• Deny interactive and remote logon for service accounts, and restrict where they can authenticate from.
• Use one service account per application or service, never one shared across many (OWASP NHI9 NHI Reuse).
• Separate accounts per environment so test accounts cannot reach production (OWASP NHI8).
• Use access analysis tools to compare granted permissions with those actually used, and remove the difference.

Stopping human use of service accounts

Administrators sometimes log in as service accounts to troubleshoot or to get around their own access limits. That destroys accountability and often requires the password to be widely known. Prevent it by denying interactive logon, vaulting credentials so no person knows them, alerting on interactive use and giving administrators proper privileged access through a PAM process instead.

Monitoring

• Baseline each account's normal sources, times, targets and volumes.
• Alert on interactive logons, new source hosts, new target systems, privilege changes, failed authentication bursts and use outside expected schedules.
• Alert on new keys or secrets created for existing service principals, a common persistence technique.
• Feed service account activity into identity threat detection. See the ITDR Guide.

Lifecycle and governance

• Request and approval: new service accounts need a documented purpose, owner and privilege justification.
• Ownership: every account has a named owner and a backup owner; ownership transfers when people move. See the NHI Ownership and Accountability Guide.
• Review: owners confirm need and privilege at least annually, more often for privileged accounts. See the Access Reviews Guide.
• Decommissioning: disable before deleting, confirm nothing breaks, then remove the account and its credentials.

Common failure patterns

• Service accounts in Domain Admins "because the installer needed it".
• Passwords set to never expire and unchanged since the account was created.
• Cloud access keys created for a proof of concept still active years later.
• The same service account password used on dozens of servers.
• Service accounts owned by people who left the organisation.

Practitioner checklist

• Inventory service accounts across directory, cloud, SaaS, database and server platforms.
• Assign a named owner and purpose to every account; disable those with neither.
• Migrate to gMSAs, managed identities, IAM roles and federation where possible.
• Vault and rotate remaining credentials; remove them from scripts and configuration.
• Remove administrative group memberships and wildcard permissions.
• Deny interactive logon and alert on any human use.
• Monitor behaviour and alert on anomalies and new credentials.
• Review and recertify regularly; decommission promptly.

Standards and references

• OWASP Non-Human Identities Top 10 (2025)
• Microsoft: Group Managed Service Accounts overview
• MITRE ATT&CK T1558.003: Kerberoasting
• MITRE ATT&CK T1078: Valid Accounts
• PCI DSS v4.0.1 (Requirement 8.6: system and application accounts)

Related NHI Mgmt Group resources: Service Account Impersonation Guide · The Ultimate Guide to Non-Human Identities · Top 10 NHI Issues · Privileged Access Management Guide