The Service Accounts Guide Part 1: Origin, Types, Pitfalls and Fixes
When you hear “Service Account” what comes to mind?
Unrotated passwords? MSSQL Server 2008?
Terminator-style robots? 🤖
These “OGs of non-human identities” are the interconnection point between automated processes for accessing sensitive data, driving business intelligence, and running scripts. But with so many different ways to use these identities come abuse and vulnerabilities.
In this three-part guide, we will explore the nuances of the elusive term “Service Account,” how these identities look in different environments, common pitfalls, best practices for handling and securing them, and finish with a live workshop about common vulnerabilities and how attackers might exploit them. Let’s begin.
Part 1: Origin, types, pitfalls and fixes
The inception of the service account began back in the days of Windows NT.
Designed as a powerful, non-interactive service account to facilitate essential system functions, LocalSystem was created with elevated privileges to manage core Windows services, including access to nearly all system resources and full control over files, processes, and registry entries.
In recent years, service accounts have rapidly evolved from legacy on-prem systems into essential components of modern SaaS and cloud environments. Originally designed for local, isolated tasks within single servers or specific applications, they’ve now become critical for supporting complex automation across distributed systems.
With the rise of cloud infrastructure, the role of service accounts has expanded to facilitate inter-service communication, data processing, and API integrations at scale. However, this shift also brings new challenges: service accounts are often provisioned with extensive permissions, remain unmonitored, and are difficult to manage.
Not all service accounts are created equal
Service accounts come in different forms, each with unique management needs and risks:
User service accounts
The need for quick automation solutions often led people to take a “quick and dirty” approach by repurposing regular user accounts for automated processes. Instead of purpose-built non-human identities, they turned to human user accounts, seeing them as the easy way to grant programmatic access.
However, this workaround creates significant security gaps.
User accounts weren’t designed for automation: They lack fine-grained permissions, rely on human-oriented security protocols (like MFA) that are overridden by this abuse, and are usually out of the scope of tools that monitor automated actions.
This mismatch has left many organizations vulnerable, as these “quick fixes” became widespread without the proper guardrails.
“Cyborg” accounts
In many cases, users can generate a special key, called “Access keys”, “Personal Access tokens”, or “API keys”, that allows them to sign in programmatically and access APIs and resources. These keys commonly end up as part of some automatic processes, which convert the user account into a “Cyborg”—both a human identity and an NHI using the same authorization and permissions.
Cyborgs are difficult to handle since their behavior is “dirtied” by the multiple access abuse, which makes monitoring them hard.
Furthermore, due to the necessities of programmatic access, the Cyborg’s permission bloat beyond what the human user actually needs access to, and are usually non-expiring. Making matters worse, Cybrogs make offboarding users a problem – since their tied keys might be disabled and potentially break a critical service.
Built-in service accounts
The other side of the scale presents a safer approach to service accounts. Several platforms offer a built-in object named “Service Account”, destined to be used by an automatic process.
Common platforms that use built-in service accounts are: Google Workspace, Active Directory, and Kubernetes. They were born from a careful consideration of the issues arising from using normal users for automatic processes.
These accounts are usually controlled with automatically-expiring long cryptographic keys instead of short passwords, they have special tools for monitoring and their permissions can usually be managed on a more granular level.
From cyborgs to cyber-safe 🤓
Shifting from ad hoc user-based and “Cyborg” accounts to secure, built-in service accounts is crucial and requires a proactive approach to detection, education, and process change.
- Detect cyborgs and misused user accounts Start by identifying accounts used in unintended ways, such as user accounts performing automated tasks. Monitor for patterns that suggest misuse, like login activities outside normal hours or the presence of API keys linked to human users. Security teams can use audit logs, IAM tools, or anomaly detection solutions to flag these instances for review.
- Provide simple alternatives for automation Facilitate easy creation and management of dedicated service accounts across teams. By making secure, built-in service accounts accessible and straightforward to set up, employees can avoid the temptation of quick-fix “Cyborgs” and misused user accounts. Automated workflows, templates, or predefined configurations can streamline the transition and reduce dependency on human accounts for automation.
- Educate teams on the risks Raising awareness about the risks of misusing human identities for automation is crucial. Highlighting issues like permission bloat, lack of monitoring, and offboarding risks can encourage teams to embrace purpose-built service accounts. Ongoing training and clear guidelines can help teams understand why and how to transition safely.
- Regular audits and policy enforcement Once built-in service accounts are implemented, establish a cadence for reviewing permissions, access, and usage patterns. Enforcing policies that mandate the use of built-in service accounts for automated processes reinforces secure practices and keeps legacy user accounts from slipping back into use.
In the next parts of this guide, we will explore the common pitfalls and vulnerabilities of service accounts, and how to ensure these identities remain compliant to different standards and frameworks.
We will finish the guide with a live workshop about common vulnerabilities and how attackers might exploit them. Stay tuned!
