The hidden cost of over-permissioned service accounts

Your most powerful user isn't a person

When teams clean up access, they usually start with people, like the contractor whose project ended, the employee who changed roles, or the admin with more rights than they need. That's a good place to start, but it leaves out a large part of the picture. Service accounts and app integrations often have broader access to sensitive data than any single person, and they're usually the last thing anyone reviews. In an unhygienic environment, one all-powerful service account can become the easiest way in.

Why access reviews start and stop with people

People have always been the most familiar actors in a breach. They're often how attackers get in: through phishing, stolen passwords, and social engineering. They're also a common route for data to leave, whether an insider copies files on the way out or an attacker uses a compromised account to pull data. Verizon's 2026 Data Breach Investigations Report found that the human element was involved in 62% of breaches. So it makes sense that access reviews, offboarding checklists, and least-privilege projects were built around user accounts.

Service accounts rarely fit that process. They're created to make something work, often with broad rights so nothing breaks, and then nobody owns them. When the person who set one up leaves, the account stays, and teams hesitate to change it because they don't know what might fail. So when they review access, service accounts are a secondary target at best.

Why service accounts make an attractive target

Machine identities outnumber human identities 82 to 1, according to CyberArk's 2025 Identity Security Landscape, and nearly half of them have sensitive or privileged access. They run around the clock, usually can't use MFA, and often keep the same password for years.

In Active Directory, attackers have a technique aimed squarely at them. Any domain user can request a Kerberos service ticket for an account with a service principal name (SPN), and part of that ticket is encrypted with a key derived from the service account's password. An attacker can take the ticket offline and crack it without touching the account again. The technique is called Kerberoasting (MITRE ATT&CK T1558.003). It works best against the kind of service account most environments have: an old password that never rotates, with older encryption like RC4 still enabled.

Service accounts aren't always non-human in practice, either. Admins sign in with them to do manual work, share one set of credentials across a team, or reuse a single account for several applications. The OWASP Non-Human Identities Top 10 names both problems: overprivileged non-human identities (NHI5) and human use of non-human identities (NHI10). When a person works through a service account, you lose track of who did what.

What this looks like in real breaches

Uber, 2022. An attacker tricked a contractor into approving an MFA request and got onto the internal network. On a network share, they found PowerShell scripts with hardcoded admin credentials for Uber's privileged access management tool. That opened the door to AWS, Google Cloud, Google Drive, Slack, and more.

Cloudflare, 2023. After the Okta breach, Cloudflare rotated thousands of credentials but missed one service token and three service account credentials that the team believed were unused. One was a Smartsheet service account with administrative access to Jira. Attackers used them to get into Cloudflare's Confluence, Jira, and Bitbucket systems.

Salesloft Drift, 2025. Attackers stole OAuth tokens from the Drift chatbot integration and used them to export data from Salesforce environments at more than 700 organizations.

In each case, the most damaging access came through a non-human identity with more reach than anyone was watching.

Four access problems hiding in your service accounts

Service accounts have the same access problems as people. They're just harder to spot, because nobody’s looking.

• Open access. The folders and shares a service account depends on are often opened broadly so the application never hits a permission error, and they stay that way. Data that's open to everyone in the company is open to every compromised account too.
• Stale and dormant access. The application was retired, but the account is still enabled and still holds its rights. An account nobody has used in a year still works for anyone holding its credentials.
• Orphaned access. The person who created the account left, or the system it served is gone. Nobody can say what the account is for, so it never gets removed.
• Privileged and excessive access. Service accounts are often added to admin groups or given Full Control "to make it work." Even without admin rights, most have far more access than their job requires.

Each of these widens the account's blast radius. Together, they turn a single password into access to much of your sensitive data.

Agentic AI raises the stakes

AI agents and copilots are non-human identities too. They act with whatever permissions they're given, often through a service account or an OAuth grant. If an agent runs under an account that can read every file share, it can read and potentially expose all of them. As organizations connect more AI tools to their data, the number of non-human identities will keep growing, and so will the cost of getting their permissions wrong.

How to bring service accounts into your access hygiene

• Build an inventory. In Active Directory, accounts with an SPN are a good starting point. Then add Entra ID app registrations, SaaS integrations, and API tokens.
• Give every account an owner who can explain what it does and approve changes to it.
• Map effective access. Check what each account can reach through group memberships and broken inheritance, with a focus on sensitive data. Work from both directions: which accounts can reach a sensitive share, and what a given account can reach.
• Right-size based on real usage. Compare what the account can access with what it has used. Removing the unused access carries the least risk of breaking something.
• Review SaaS integrations where they live. OAuth grants are usually managed in each platform's admin console or your identity provider.
• Strengthen credentials. Rotate old passwords, remove hardcoded credentials from scripts and file shares, and disable RC4 where you can.
• Watch for human use, such as interactive sign-ins or logons from workstations.
• Add service accounts to your regular entitlement reviews, on the same schedule as people.

Don't think only about people anymore

Every identity that can reach sensitive data, human or not, is part of your attack surface, and service accounts are often the widest part of it. The next time you run an access review, go through the same steps for your service accounts.

For service accounts in Active Directory and on your file servers, Netwrix Access Analyzer covers the inventory, mapping, and review steps. It identifies service accounts, shows when each was last active, and flags the ones vulnerable to Kerberoasting. It calculates effective access across file servers, SharePoint, and Active Directory. You can view that access from either direction: start with a folder to see which accounts can reach it, or with any account, human or service, to see everything it can access. From there, the Access Information Center lets resource owners run regular entitlement reviews and decide what to keep, remove, or change.