They outnumber human accounts, rarely rotate, almost nobody owns them, and they are everywhere. Service accounts are one of the most overlooked attack surfaces in enterprise environments.
Ask a security team how many user accounts are in their environment and they can usually tell you. Ask them how many service accounts they have and the room gets quiet.
Service accounts are the identities nobody talks about until something breaks or something gets breached. They run your backup jobs, execute your scheduled tasks, connect your applications to your databases, authenticate your monitoring tools, and keep dozens of automated processes running around the clock. They are everywhere. They are privileged. And in most organizations they are almost completely unmanaged.
Why It Matters
Service accounts sit at the intersection of everything attackers want. They are typically over-privileged — given broad access at deployment because it was easier than scoping permissions carefully. They rarely rotate passwords — because rotating a service account password means tracking down every place that credential is used and updating it without breaking something. They have no human owner — because the person who created the account left two years ago or the system it was built for changed hands three times. And they are often excluded from the same governance processes that apply to human accounts — because they don't need to be in the identity review because they're "just" service accounts.
That logic has appeared in the post-breach documentation of more incidents than anyone wants to count.
A compromised service account is a particularly effective tool for an attacker. It doesn't trigger the same alerts as an unusual user login. It operates on a schedule that looks normal because it is normal. It often has access to multiple systems simultaneously. And because nobody actively monitors it, the attacker can use it quietly for days, weeks, or longer before anyone notices.
The PAM Lesson
Getting service accounts under control requires solving four problems, and most organizations have not finished solving any of them.
The Decommissioning Gap
There is a specific service account failure mode that deserves its own mention: the account that outlives the system it was built for.
A service account is created for an application. The application is replaced. The migration team focuses on making the new system work and does not loop in the identity team. The old service account is never disabled. It sits in Active Directory with valid credentials and whatever access it was granted for the old system — which may include access to production databases, file shares, or other sensitive resources that the new system also needs and therefore were never removed.
Nobody is using this account intentionally. Nobody is watching it. The credentials may be documented somewhere, or they may not be.
This is not a theoretical attack surface. It is a documented pattern in real breaches. The attacker finds the orphaned service account, identifies that it has useful access, and uses it as a persistence mechanism or a lateral movement path.
Access reviews that explicitly include service accounts — asking not just "does this account still exist" but "is the system this account serves still running, and does this account still need this access" — catch this before attackers do.
What to Check This Week
Service accounts are not a niche PAM problem. They are often the largest unmanaged privileged identity population in an enterprise environment. The organizations that have gotten this right did not do it all at once. They started with discovery, established ownership, and built from there. That is the only way it works.