The Service Accounts Nobody Is Responsible For
Somewhere in your Active Directory there are service accounts with names like "svc_legacy_backup" and "app_connector_prod" and "wf_integration_v2" that were created between two and seven years ago. The person who created them left the company. Their manager has no idea these accounts exist. IT has a guess at what they do. Nobody knows what they can access.
Those accounts have passwords that have never rotated. Some of them have Domain Admin. Some of them are Kerberoastable. All of them are invisible in your access review process because access reviews focus on humans.
This is not an unusual situation. It is close to the default state of any environment that has been running Active Directory for more than a few years.
How Service Accounts Accumulate Privilege
Service accounts get privileges through a process that runs in the opposite direction from least privilege. An application needs to read from a database, so the service account gets read access. The application needs to write to a file share, so it gets write access to several shares, because the developer was not sure which ones. The application needs to restart a dependent service, so it gets local admin on three servers. Each addition makes sense in the moment. Nobody reviews the cumulative result.
After a few years and a few application updates and a few "just give it admin for now and we'll clean it up later" decisions, a service account that was supposed to read from one database table has become a privileged identity capable of substantial lateral movement.
This pattern repeats across every service account in the environment. The result is an attack surface made of dozens or hundreds of non-human identities with broad access, no MFA requirement, and passwords that have not rotated since the account was created.
They Don't Have Owners in Any Meaningful Sense
Human identities have an obvious owner: the person whose account it is. When that person leaves, the account gets deprovisioned - sometimes promptly, sometimes eventually, but at least there is a process with a trigger.
Service accounts don't have a person attached. They have a creator who may or may not still be at the company, associated with a system or application that may or may not still exist. The team that manages the related application is the theoretical owner, but that team has probably turned over since the account was created, and the new members may not know the account exists.
When you run an access review and ask people to certify that accounts they own still need their current access, service accounts fall through. The person listed as responsible for svc_legacy_backup doesn't know what it does. They click approve because it seems like something that probably should exist. The account's privileges get recertified without review.
The application it served may have been decommissioned two years ago. The account persists.
Kerberoasting Is a Service Account Problem
The Kerberoasting attack targets Active Directory service accounts that have Service Principal Names (SPNs) registered. Any authenticated domain user can request a Kerberos service ticket for such an account and take it offline to crack. The cracking runs against the account's password hash, not the live directory, so there are no lockouts and often no alerts.
If the service account has a complex, regularly rotated password, the attack is computationally impractical. If the service account has a password set in 2019 under a policy that required one uppercase letter and a number, the crack completes in under an hour on modest hardware.
Internal penetration testers find Kerberoastable accounts with elevated privileges in nearly every Active Directory engagement. It is not a sophisticated attack. It is not novel. It is available in every major offensive toolkit and it keeps working because service accounts keep sitting in directories with old passwords and broad access.
Cloud Environments Introduce the Same Problem at Scale
Active Directory service accounts are a known problem with known management tools. Cloud IAM introduces the same dynamics in environments where the tooling is less mature and the inventory less visible.
An AWS IAM role created for a Lambda function three years ago may have broad S3 access that made sense at deployment and has never been reviewed. An Azure service principal used during a migration may still hold Contributor rights on a subscription that nobody thought to revoke when the migration completed. A GCP service account with Editor permissions may have keys older than some of your junior employees.
Cloud-native environments also introduce machine identity at scale: containers, pods, and serverless functions all need credentials to access other services, and the lifecycle of the credential is often measured in months or years even when the compute is ephemeral.
The attack pattern is consistent across environments. Compromise a workload. Find the attached identity. Discover that the identity has far more access than the workload ever needed. Move laterally.
What Good Looks Like
Inventory first. For Active Directory, tools like BloodHound and native PowerShell can enumerate service accounts, their privileges, their SPNs, and when their passwords last rotated. For cloud environments, IAM Access Analyzer and equivalent tools surface permissions that are overly broad or have gone unused. You cannot manage what you have not counted.
Assign ownership to teams, not individuals. Every service account needs a team - not a person, who will eventually leave - with accountability for what the account does and what access it actually needs. Build that ownership into your access review process so service accounts don't fall through the certification gap they currently fall through.
Enforce rotation. Managed service accounts in Active Directory rotate passwords automatically. For cloud credentials, secrets management platforms handle rotation with less manual overhead. The accounts exempted from rotation enforcement are exactly the ones that should get the most scrutiny, not the least.
Scope access to what the account actually needs. The service account that reads from one database table should have read access to one database table. Getting there from where most environments are requires a cleanup pass that is not painless. It requires deliberately breaking things to find out what actually depends on the excessive access. That is uncomfortable work. It is also the kind of work that closes the attack paths that penetration testers document in every report and organizations promise to fix before the next engagement.
Service accounts are not a complicated security problem. They are a maintenance problem that compounds over time until it becomes an attack path. Most environments have already let that compounding run longer than they should have.