Service accounts fail in the same few ways in almost every organisation: people log on with them, passwords are shared and never change, privileges grow and nobody owns them. Each mistake is easy to make under delivery pressure and hard to see afterwards, because a service account that works raises no tickets. This page ranks the ten service account mistakes we see most often, with why each matters, how to detect it and the first fix. It is for IAM, infrastructure and security operations teams cleaning up service accounts in Active Directory, cloud platforms and SaaS. The ranking is NHI Mgmt Group's editorial view. For the full control set, see the Service Account Security Guide.
The Top 10 at a glance
| # | Mistake | Why attackers like it | First fix |
|---|---|---|---|
| 1 | No accountable owner | Nobody notices misuse or removes the account | Named owner and deputy for every account |
| 2 | People logging on interactively | Password widely known, actions unattributable | Deny interactive logon; humans use their own privileged accounts |
| 3 | Shared passwords across accounts and servers | One stolen password opens many systems | Unique credential per account; managed accounts |
| 4 | Passwords that never change | Old leaks and ex-staff knowledge stay valid | Platform-managed or vaulted rotation |
| 5 | Excessive privilege | A single compromise becomes domain or tenant compromise | Remove from admin groups; scope to named resources |
| 6 | Credentials in scripts, files and tickets | Searchable by anyone with read access | Fetch from a vault at run time |
| 7 | One account for many applications or environments | Blast radius spans everything it serves | One account per application per environment |
| 8 | Static keys where managed identity exists | Long-lived keys leak and outlive their purpose | Managed identities, roles and federation |
| 9 | Weak Kerberos settings on SPN accounts | Offline password cracking (Kerberoasting) | gMSA or long random passwords; AES only |
| 10 | No monitoring of service account behaviour | Misuse looks like normal automation | Baseline and alert on deviations |
The order reflects how often NHI Mgmt Group sees each mistake in practice; the first fix column is our recommendation.
1. No accountable owner
The mistake: the account was created by an engineer who has since left, for a project that ended, and nobody can say whether it is still needed.
Why it matters: an unowned account is never reviewed, never rotated and never removed, which is how OWASP NHI1:2025 Improper Offboarding arises. Microsoft lists the owner, "The user or group accountable for the service account", first among the details to collect for every service account.
Detect it: compare the owner field in your inventory with the HR system; flag owners who are leavers and accounts with no owner at all.
The fix: make owner and deputy mandatory at creation with the Service Account Request Form Template, and run attestation campaigns. See the NHI Ownership Guide.
2. People logging on interactively
The mistake: administrators sign in as the service account to troubleshoot, or use it to get round their own access limits.
Why it matters: the password has to be known by people, so it spreads, and every action is attributed to the account rather than a person. OWASP lists this as NHI10:2025 Human Use of NHI.
Detect it: on Windows, alert on event 4624 for service accounts with interactive (2) or remote interactive (10) logon types; in cloud logs, look for console sign-ins or user agents typical of a browser for workload identities.
The fix: deny interactive logon with the Deny log on locally and Deny log on through Remote Desktop Services user rights (Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment), vault the password so nobody knows it, and give administrators their own privileged access. See the OWASP NHI Top 10 NHI10 Human Use of NHI Guide.
3. Shared passwords across accounts and servers
The mistake: the same password is set on several service accounts, or the same local account and password run a service on dozens of servers.
Why it matters: one credential dump from one server gives the attacker every system that shares the password, and rotation becomes so disruptive that it never happens.
Detect it: audit password hashes for duplicates with an approved tool under change control, and look for the same account authenticating from many unrelated hosts.
The fix: one credential per account. Move Windows services to group managed service accounts, where the operating system manages the password and member hosts obtain it from a domain controller. See the Group Managed Service Accounts (gMSA) Guide.
4. Passwords that never change
The mistake: "password never expires" is ticked, and the password is the one set when the account was created years ago.
Why it matters: anyone who has ever known or captured the password still holds valid access. OWASP NHI7:2025 Long-Lived Secrets covers the same risk for keys and tokens.
Detect it: Microsoft gives a PowerShell filter for accounts with PasswordNeverExpires set to true; compare pwdLastSet with today. In AWS, use IAM access last used information to find old access keys.
The fix: platform-managed credentials first, vault-driven rotation second, manual rotation with a runbook only as a dated exception. See Rotating a Windows or Linux Service Account Password.
5. Excessive privilege
The mistake: the installer "needed" Domain Admins, the cloud identity got Owner or Editor, and nobody removed it after go-live.
Why it matters: a compromised service account inherits all of it. In the Dropbox Sign breach, a back-end service account with broad rights in production gave the attacker a path to the customer database. Microsoft's mitigations for user-based service accounts include removing them from privileged groups and granting only the rights needed to run the service.
Detect it: list service accounts in privileged groups and cloud identities with broad basic roles. Google Cloud warns that default service accounts may receive the Editor role automatically.
The fix: remove admin group membership, use narrow roles per resource, and use IAM Access Analyzer or equivalent usage data to cut unused permissions. See the How to find service accounts with Domain Admin rights guide.
6. Credentials in scripts, files and tickets
The mistake: the password sits in a batch file, a config file on a share, a scheduled task, a wiki page or a support ticket.
Why it matters: attackers search file shares and repositories for credentials (MITRE ATT&CK T1552.001 Credentials In Files). In the TiDB Cloud breach, customer keys shared in support tickets were among the exposed data, a reminder that tickets are not a safe store.
Detect it: run secret scanning across repositories, file shares and collaboration tools; search ticketing systems for credential patterns.
The fix: retrieve secrets from a vault at run time and rotate anything found. See the Secrets Management Guide.
7. One account for many applications or environments
The mistake: "svc_app" runs five applications, or the same identity serves test and production.
Why it matters: compromise of the weakest application or the test environment reaches everything the account serves, and nobody can rotate it without breaking all of them. These are OWASP NHI9:2025 NHI Reuse and NHI8:2025 Environment Isolation. Google Cloud recommends dedicated service accounts for each application.
Detect it: count distinct source hosts and applications per account; flag any account authenticating from both test and production networks.
The fix: split by application and environment, starting with production accounts that also serve test.
8. Static keys where managed identity exists
The mistake: a workload running in the cloud uses a downloaded key or access key when the platform can give it short-lived credentials.
Why it matters: keys get copied into images, pipelines and laptops. AWS recommends that workloads use temporary credentials with IAM roles, and Google Cloud recommends avoiding service account keys whenever possible and blocking key creation by organisation policy.
Detect it: list IAM users with access keys used from AWS compute, Google Cloud service accounts with user-managed keys, and Entra service principals with client secrets.
The fix: use managed identities, roles and workload identity federation. See the Workload Identity Federation Guide and How to inventory Google Cloud service account keys and replace them with federation.
9. Weak Kerberos settings on SPN accounts
The mistake: a user account with a service principal name (SPN) has a short, human-chosen password and still allows RC4 encryption.
Why it matters: any domain user can request a service ticket for an SPN and attempt to crack it offline (MITRE ATT&CK T1558.003 Kerberoasting). Weak passwords fall quickly.
Detect it: list user accounts with SPNs; alert on bursts of event 4769 service ticket requests from one account, especially with RC4 encryption type 0x17.
The fix: move SPN accounts to gMSA, or set long random vaulted passwords and AES-only encryption. See the Kerberoasting and AS-REP Roasting Defence Guide.
10. No monitoring of service account behaviour
The mistake: service account logons are excluded from alerting because they are "noisy".
Why it matters: an attacker using a valid service account (MITRE ATT&CK T1078.002 Domain Accounts, T1078.004 Cloud Accounts) looks like automation. Microsoft's principles include monitoring sign-in data to make sure it matches the intended usage.
Detect it: check which service accounts appear in your SIEM at all, and whether any rule covers new source hosts, new targets, out-of-hours use or unusual data volumes.
The fix: record expected behaviour at creation and alert on deviations. See the Service Account Behavioural Baselining Guide.
Mapping to OWASP
| Mistake | OWASP Non-Human Identities Top 10 2025 |
|---|---|
| 1 No owner | NHI1 Improper Offboarding |
| 2 Interactive logons | NHI10 Human Use of NHI |
| 3 Shared passwords | NHI9 NHI Reuse |
| 4 Passwords never change | NHI7 Long-Lived Secrets |
| 5 Excessive privilege | NHI5 Overprivileged NHI |
| 6 Credentials in files | NHI2 Secret Leakage |
| 7 Shared across apps or environments | NHI9 NHI Reuse, NHI8 Environment Isolation |
| 8 Static keys | NHI7 Long-Lived Secrets, NHI6 Insecure Cloud Deployment Configurations |
| 9 Weak Kerberos settings | NHI4 Insecure Authentication |
| 10 No monitoring | Supports detection across all ten |
Where to start
- Find the privileged ones: list service accounts in admin groups and cloud identities with broad roles; fix mistake 5 there first.
- Stop human use: deny interactive logon for those accounts and vault their passwords (mistakes 2 and 3).
- Assign owners: give every account an owner and deputy, and disable those nobody claims after notice (mistake 1).
- Close the front door: require the request form for every new account so the same mistakes are not recreated.
- Rotate and replace: work through never-changed passwords and static keys, moving to managed identities as you go (mistakes 4 and 8).
Track progress with four numbers: service accounts with a named active owner, service accounts in privileged groups, credentials older than [12 months] (our suggested threshold), and interactive logons by service accounts in the last 30 days.
Related NHI Mgmt Group resources: Service Account Security Guide · Service Account Inventory Template · Identity Incident Response Playbook · Orphaned and Dormant Accounts