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 hold far more privilege than they need. This guide covers service accounts across Active Directory, Microsoft Entra ID, AWS, Google Cloud, Kubernetes, SaaS and databases: why attackers target them, how to find them, how to replace their credentials and cut their privilege, how to detect misuse, and how to govern them from request to decommissioning. It is written for identity, platform and security operations teams, and covers AI agents, which increasingly run on service accounts.

Key takeaways

• A service account is software's identity. It exists in directories, cloud platforms, SaaS applications, databases and operating systems, often under different names and with different controls in each, so one inventory has to span them all.
• The same five problems recur. No owner, excessive privilege, passwords or keys that never rotate, interactive use by humans and accounts that outlive their purpose map directly to OWASP NHI1, NHI5, NHI7 and NHI10.
• Remove the password before you rotate it. Group and delegated managed service accounts, cloud managed identities, IAM roles and workload identity federation take stored credentials out of the picture altogether.
• Treat service accounts as privileged identities. Inventory, ownership, least privilege, behavioural monitoring, periodic review and prompt decommissioning apply to them as much as to administrators.
• AI agents inherit the problem. An agent running on a shared service account cannot be held to least privilege or audited; give each agent its own governed identity with short-lived, task-scoped credentials.

Where service accounts live

Most estates have every one of these forms at once.

Defaults make this worse. Google Cloud notes that App Engine and Compute Engine create a default service account with the Editor role on the project, which resources use automatically unless another is named. In Kubernetes, a Pod that names no ServiceAccount gets its namespace's default one. For platform specifics, see the Cloud Workload Identity Guide, the Kubernetes NHI Security Guide and the Azure RBAC and Service Principals Guide.

Why service accounts are targeted

• Privilege without scrutiny: they often hold broad, standing access that no one reviews. CIS Control 5 notes that service accounts "are often shared among teams, internal and external to the enterprise, and sometimes not known about, only to be revealed in standard account management audits."
• Weak or static authentication: passwords that never change, cannot use MFA and are stored in scripts and configuration files.
• Offline cracking: MITRE ATT&CK T1558.003 describes how any user with a valid Kerberos ticket can request service tickets for accounts with service principal names; where tickets use RC4, the service account's password hash can be brute-forced offline.
• Lateral movement and persistence: one account is often trusted by many systems, and MITRE T1098.001 records attackers adding their own credentials to Entra ID service principals to keep access.

Real incidents show the pattern. In the Microsoft Midnight Blizzard Breach 2024, Microsoft says the actor compromised "a legacy test OAuth application that had elevated access to the Microsoft corporate environment" and used it to grant the Exchange Online full_access_as_app role. In the Okta Support System Breach 2023, Okta's root cause analysis found the attacker used a service account whose username and password an employee had saved to a personal Google profile. In the Uber Breach 2022, the attacker claimed, as reported by Help Net Security, that a PowerShell script on a network share held an admin password for Uber's PAM tool. OWASP lists the underlying issues as NHI1 Improper Offboarding, NHI5 Overprivileged NHI, NHI7 Long-Lived Secrets and NHI10 Human Use of NHI.

Finding service accounts

Microsoft's guidance says finding non-MSA service accounts "can be difficult" and recommends reviewing every account with access to important resources to decide which ones are really acting as service accounts. Combine several methods:

• Directory queries: accounts with non-expiring passwords, service principal names, "svc-" naming, no interactive logon history, or membership of service groups. Microsoft recommends a prefix such as "svc-" and an owner in the description attribute for new accounts.
• Cloud inventories: IAM users with access keys, roles, service principals, managed identities and service accounts across every account, subscription and project. In Entra ID, Get-MgServicePrincipal -All:$true lists service principals.
• Behaviour, configuration and SaaS consoles: accounts that authenticate on fixed schedules from servers; connection strings, scheduled tasks and CI/CD variables; integration users and connected apps.

Record each account's platform, purpose, owner, privileges, authentication method, credential age, where the credential is stored, risk profile, expected lifetime and last activity. Microsoft's documentation list for on-premises accounts asks for the same fields, including anticipated lifetime and periodic attestation. The Service Account Inventory Template provides a ready-made structure, and the NHI Ownership Guide covers assigning owners.

Reducing credential risk

The order of preference is the same everywhere: no stored credential, then a platform-rotated one, then a vaulted and rotated one.

1. Use platform-managed identities. gMSAs let Windows handle password management. dMSAs, new in Windows Server 2025, bind authentication to specific machine identities and, according to Microsoft, help prevent Kerberoasting. Plan dMSA migrations carefully: Microsoft says you cannot migrate from a gMSA to a dMSA, recommends waiting at least two ticket lifetimes (14 days) before completing a migration, and warns that machines without dMSA support will fail authentication once the old account is disabled. See the gMSA and dMSA Guide.
2. Remove keys from the cloud. Google says "We recommend that you avoid using service account keys whenever possible", and AWS asks workloads to use temporary credentials through IAM roles. For workloads outside a cloud, use federation. See the Workload Identity Federation Guide and the NHI Authentication Guide.
3. Prefer certificates to secrets. Microsoft recommends certificates for service principals because, unlike client secrets, they cannot be embedded in code by accident.
4. 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. PCI DSS v4.0.1 Requirement 8.6.2, as quoted by assessor Schellman, says passwords for accounts that can log in interactively are "not hard coded in scripts, configuration/property files, or bespoke and custom source code". See the Secrets Management Guide.
5. Rotate automatically. Rotate on a schedule and immediately after exposure, with dependencies mapped first so rotation does not break production. Requirement 8.6.3 asks for periodic change at a frequency set by targeted risk analysis and on suspicion of compromise. The Secrets Rotation Runbook Template sets out the steps.
6. Harden Kerberos. For accounts with service principal names that must keep a password, MITRE recommends AES rather than RC4 and passwords of "ideally 25+ characters". Microsoft adds that managed service accounts should always be configured for AES. See the Kerberos Security Guide.

Reducing privilege

Microsoft states plainly that "Service accounts shouldn't be members of any privileged groups" and that each service should have its own account. In practice:

• Strip administrative groups: remove service accounts from Domain Admins, Global Administrator, Owner and similar roles unless strictly required, and document any exception.
• Scope to resources and actions: grant each service the specific resources and actions it uses, and replace wildcard cloud policies. PCI DSS Requirement 7.2.5 asks that system and application account access be based on "the least privileges necessary".
• One account per service: never share one account across applications (OWASP NHI9 NHI Reuse), and separate accounts per environment so test cannot reach production (NHI8 Environment Isolation).
• Remove default grants: Google recommends dedicated service accounts per application and the iam.automaticIamGrantsForDefaultServiceAccounts organisation policy constraint so default accounts are not given Editor. In Kubernetes, set automountServiceAccountToken: false where a Pod does not call the API.
• Watch impersonation paths: a Google Cloud service account is both a principal and a resource that others can impersonate, and domain-wide delegation lets it impersonate any Workspace user, including super-admins. Restrict who can impersonate and avoid domain-wide delegation.
• Right-size from usage: AWS IAM Access Analyzer and Google role recommendations compare granted and used permissions; remove the difference. See the AWS IAM Policies and Roles Guide and the Google Cloud IAM and Service Accounts Guide.

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: OWASP NHI10 warns of activity that becomes "indistinguishable" between humans and automation, and the password usually ends up widely known. The Okta incident shows the end state: a service account password saved in a browser profile outside corporate control.

PCI DSS Requirement 8.6.1, as quoted by Schellman, sets a useful standard for any organisation: where a system or application account can be used interactively, interactive use is prevented except in exceptional circumstances, limited in time, justified, approved by management, tied to a confirmed individual and attributable to that person. To get there, deny interactive and remote logon rights, vault the credential so no person knows it, alert on every interactive session, and give administrators their own privileged access through a PAM process. See the Privileged Access Management Guide. Where people need elevated access, use just-in-time elevation of their named accounts. See the JIT Access Guide.

Detection and monitoring

Service accounts behave predictably, so deviations stand out once each account's normal hosts, targets, times and volumes are baselined. Alert on these signals:

Okta's analysis is a warning about log coverage: for 14 days its team missed the attacker's file downloads, because opening files from the Files tab, as the attacker did, generated a different log event from viewing them in a support case. Test detections against every path to the data. Feed service account activity into identity threat detection; see the ITDR Guide.

Lifecycle and governance

• Request and approval: a new service account needs a documented purpose, owner, platform, privilege justification and expected lifetime before it is created. NIST SP 800-53 AC-2 asks organisations to require approvals for account creation and to assign account managers.
• Ownership: every account has a named owner and a backup owner, and ownership transfers when people move or leave. Link service account ownership to the Joiner-Mover-Leaver Guide process so leavers cannot take ownership with them.
• Review: owners confirm need and privilege on a fixed cycle, more often for privileged accounts. PCI DSS Requirement 7.2.5.1 asks for periodic review of application and system account access with management acknowledgement. See the Access Reviews Guide.
• Dormancy: disable accounts with no activity for a defined period (CIS Safeguard 5.3 Disable Dormant Accounts).
• Decommissioning: disable before deleting. Google explains why: deleting a service account and recreating one with the same name produces a new identity without the old bindings, while disabling keeps bindings intact if something breaks. Remove credentials, keys and secrets along with the account.

Service accounts and AI agents

AI agents are often deployed on whatever identity is to hand: a developer's token, an existing integration user or a shared service account. OWASP's Top 10 for Agentic Applications (2026) lists this as ASI03 Identity and Privilege Abuse and observes that "Without a distinct, governed identity of its own, an agent operates in an attribution gap that makes enforcing true least privilege impossible." Its mitigations include per-agent identities, short-lived task-scoped tokens and human approval for privilege escalation.

Identity platforms are adding agent-specific constructs. Microsoft Entra Agent ID, for example, provides agent identities and blueprints and extends Conditional Access, identity protection, governance and sign-in logs to agents (Microsoft notes some of these features need additional licensing). Whatever platform you use, apply the service account rules: one identity per agent, an owner, least privilege, no shared credentials and decommissioning when the agent is retired. See the Identity Governance for AI Agents Guide.

Common failure patterns

• Privileged by installer: service accounts in Domain Admins "because the installer needed it", never revisited after go-live.
• Never-expiring passwords: passwords set to never expire and unchanged since the account was created, often on SPN-bearing accounts open to Kerberoasting.
• Proof-of-concept credentials that stay: cloud keys or test applications created for a pilot still active years later. The legacy test OAuth application in the Midnight Blizzard attack had elevated access to production.
• Credentials outside the vault: passwords in scripts, shares and browsers. Uber's attacker claimed to find a PAM admin password in a script; Okta's service account password sat in a personal Google profile.
• Owner left the building: accounts owned by people who left, with nobody able to say whether the account is still needed.
• Defaults left on: Google default service accounts with Editor and Kubernetes default ServiceAccounts auto-mounted into every Pod.

Framework mapping

This is an indicative NHI Mgmt Group alignment. Control IDs were checked against the NIST CSF 2.0 text, the NIST SP 800-53 Rev. 5 catalogue, the ISO/IEC 27001:2022 Annex A control list and the CIS Controls assessment specification (safeguard numbers unchanged in v8.1).

For the payment card requirements, see the PCI DSS 4.0 Guide.

Metrics that show progress

Implementation roadmap

Practitioner checklist

• Inventory service accounts across directory, cloud, Kubernetes, SaaS, database and server platforms.
• Assign a named owner, backup owner and purpose to every account; disable those with neither.
• Migrate to gMSAs or dMSAs, managed identities, IAM roles and federation wherever the platform supports it.
• Vault and rotate remaining credentials; remove them from scripts, shares, browsers and configuration.
• Enforce AES and long random passwords on SPN-bearing accounts that keep a password.
• Remove administrative group memberships, default grants and wildcard permissions.
• Deny interactive logon and alert on any human use.
• Monitor behaviour and alert on anomalies, Kerberoasting patterns and new credentials on service principals.
• Review and recertify on a fixed cycle; disable before deleting at decommissioning.
• Give each AI agent its own identity with short-lived, task-scoped credentials.

Standards and references

• OWASP: Non-Human Identities Top 10 2025
• NIST: SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations
• Microsoft: Group Managed Service Accounts overview
• Microsoft: Delegated Managed Service Accounts overview
• Microsoft: Securing on-premises service accounts
• Microsoft: Securing service principals in Microsoft Entra ID
• Google Cloud: Best practices for using service accounts securely
• Kubernetes: Service Accounts
• MITRE ATT&CK: T1558.003 Kerberoasting
• MITRE ATT&CK: T1078 Valid Accounts
• OWASP GenAI Security Project: Top 10 for Agentic Applications for 2026
• Schellman: PCI DSS Service Account Requirements: A Breakdown

Related NHI Mgmt Group resources: gMSA and dMSA Guide · Service Account Inventory Template · Secrets Management Guide · Privileged Access Management Guide · Identity Governance for AI Agents Guide