- Service accounts are technical accounts used by applications, services, and automated processes for authentication. They run around the clock, often have excessive privileges, and are rarely reviewed.
- In an average mid-market company, 50 to 200 service accounts exist, many of which have not been touched in years. Some run with Domain Admin rights even though they do not need them.
- The biggest risks are passwords that are never changed, excessive permissions, no assigned owner, no MFA protection, and no usage monitoring.
- Securing service accounts starts with an inventory: which service accounts exist? What permissions do they have? Who is responsible? Are they still needed? Then comes least privilege, password rotation, and monitoring.
- Managed Service Accounts (MSA) and Group Managed Service Accounts (gMSA) in Active Directory automate password rotation and eliminate the risk of static passwords. For cloud environments, Workload Identities and Managed Identities offer similar benefits.
What Are Service Accounts and Why Are They Dangerous?
Service accounts are technical user accounts used not by humans but by applications, services, and automated processes. The backup agent that nightly backs up the database authenticates via a service account. The ERP software that accesses the SQL database uses a service account. The monitoring agent that checks server status uses a service account. The ticketing system that reads emails from a mailbox operates with a service account.
These accounts are ubiquitous but invisible. No person logs in in the morning and logs out in the evening. There is no screen where a session opens. Service accounts run in the background, around the clock, seven days a week. And it is precisely this invisibility that makes them dangerous.
The risks of service accounts arise from a combination of factors that are typically better controlled for human accounts.
Static passwords: The password of a service account is set during creation and then never changed. Not after three months, not after a year, not after five years. The reason is pragmatic: if you change the password, you also have to change it in the application that uses the account. And if you make a mistake doing so, the application stops working. So the password is left untouched. In many organizations, service accounts run with passwords that have not been changed in over a decade.
Excessive permissions: During setup, the service account is often given generous privileges because nobody knows exactly which minimum permissions the application actually requires. "Give the account Domain Admin rights, then it will definitely work" is a sentence every IT administrator has heard or said themselves. What was intended as a quick fix for a specific problem becomes a permanent security risk.
Missing ownership: Who is responsible for the service account svc-backup-prod? Who created it? Which application uses it? In many organizations, nobody can answer these questions. The employee who created the account five years ago no longer works at the company. Documentation does not exist or is outdated. The account keeps running, but nobody feels responsible.
No MFA: Service accounts in most cases do not support multi-factor authentication because there is no human present to confirm a second factor. This removes one of the most effective protective measures against compromised credentials.
No monitoring: Service account usage is rarely monitored. When a service account logs in to a server at 3 AM, that is normal behavior because it does that every night. But when the same account logs in at 2 PM to a different server it does not normally contact, this goes unnoticed without monitoring.
The Scale of the Problem
In an average mid-market company with 200 to 500 employees, typically 50 to 200 service accounts exist. In larger enterprises, there can be thousands. Each one is a potential attack vector.
The attack technique Kerberoasting specifically targets service accounts in Active Directory. An attacker who already has a normal user account requests Kerberos Service Tickets for all service accounts that have a Service Principal Name (SPN) registered. These tickets are encrypted with the service account's password hash. The attacker extracts the tickets and cracks them offline using brute-force methods. If the password is weak (and for service accounts set up years ago, it often is), the attacker has a valid password within minutes or hours.
The attack is particularly insidious because it requires no privileged rights and leaves barely any traces. Any domain user can request Kerberos Service Tickets, and the request looks like normal Kerberos activity in the logs.
Step 1: Inventory All Service Accounts
Securing starts with knowing what needs to be protected. As with IT asset management in general, a complete inventory of all service accounts is the indispensable first step.
Where Are Service Accounts Found?
Active Directory: The most obvious source. Service accounts in AD can be identified through various methods: accounts with a Service Principal Name (SPN), accounts in OUs named "Service Accounts" or "Technical Users," accounts whose names begin with prefixes like "svc-," "sa-," or "srv-," and accounts where the "Password never expires" flag is set.
Local accounts on servers: Some services run under local user accounts that do not exist in Active Directory. These accounts are often overlooked during AD inventorying. A PowerShell script that queries all servers for their services and lists the accounts used will uncover these.
Cloud platforms: In Azure, these are App Registrations, Service Principals, and Managed Identities. In AWS, they are IAM Users with programmatic access (Access Keys). In Google Cloud, they are Service Accounts in IAM. Each cloud platform has its own mechanisms that must be inventoried separately.
Applications: Some applications manage their own service accounts internally. Databases have technical users for replication and monitoring. Middleware systems have integration accounts. These accounts are not visible from the outside and must be identified through application owners.
What to Document?
For each service account, you should capture the following information: name and location (AD, local, cloud), purpose (which application, which service), owner (who created the account, who is currently responsible), permissions (group memberships, roles, access rights), password age (when was the password last changed?), interactive logon (is interactive logon possible or blocked?), SPN registration (for Kerberoasting risk assessment), and criticality (how severe would a compromise be?).
Step 2: Implement Least Privilege
After the inventory comes the reduction of permissions to the necessary minimum. This step requires collaboration with application owners because only they know which permissions the application actually needs.
The process for each service account looks like this: first, you document the current permissions. Then you analyze with the application owner which of these permissions are actually needed. You create a target permission profile with minimal rights. In a test environment or maintenance window, you reduce the permissions and verify that the application continues to function. Finally, you document the final permission profile.
A common case is the service account that has Domain Admin rights because it needs write access to a specific file share. The solution is obvious: instead of Domain Admin rights, the account gets only the specific NTFS permissions on the required share.
Another common case is the service account for the monitoring tool that needs read access to all servers. Instead of Domain Admin rights, membership in the "Performance Monitor Users" or "Event Log Readers" group on the monitored servers is often sufficient.
Step 3: Password Management
Password management for service accounts is one of the biggest challenges because automated rotation must be coordinated with the configuration of the consuming application.
Managed Service Accounts (MSA) and Group Managed Service Accounts (gMSA)
The best solution for service accounts in Active Directory is Managed Service Accounts (MSA) and Group Managed Service Accounts (gMSA). These special account types fully automate password rotation. Active Directory automatically generates a 240-character random password and rotates it every 30 days. The application retrieves the current password from the Domain Controller automatically during login, without any human intervention.
MSAs are bound to a single server; gMSAs can be used by multiple servers, making them suitable for cluster scenarios and load balancing.
The limitation: not all applications support gMSAs. The application must be able to retrieve the password from the DC instead of reading it from a configuration file. Windows services natively support gMSAs, but third-party software often does not. For each application, you must verify whether gMSA support is available.
Password Rotation for Classic Service Accounts
For service accounts that cannot be converted to gMSA, you need a manual or semi-automated rotation process. This process includes generating a new, strong password, changing the password in Active Directory, updating the password in the application configuration, restarting the service, and verifying that the application functions properly.
This process should be documented for each service account so that another administrator can perform it. The documentation includes: which application is affected, where the password is configured in the application (configuration file, registry, database), whether a service restart is required, and how to verify that the application works after the password change.
PAM solutions like CyberArk or BeyondTrust can automate this process by changing the password both in AD and in the application configuration simultaneously. For organizations with many service accounts, the investment can be worthwhile.
Cloud Environments: Managed Identities
In Azure, Managed Identities provide an elegant solution for service accounts in the cloud. Instead of a username and password, the Azure resource (e.g., a VM, an App Service, or an Azure Function) receives an automatically managed identity. Authentication to other Azure services occurs via tokens that are automatically generated, rotated, and invalidated. There is no password to store, manage, or steal.
In AWS, IAM Roles for EC2 instances and Workload Identity for EKS offer a similar concept. In Google Cloud, Workload Identity Federation and Service Account Keys (though the latter should be avoided) serve this function.
Step 4: Restrict Interactive Logon
Service accounts should not be able to log on interactively. There is no legitimate reason for someone to log in with a service account on a computer and open a desktop session. If a service account is used for an interactive logon, that is a strong indicator of misuse.
In Active Directory, you can restrict interactive logon through the "Log on to" property. There you list the computers the service account is allowed to log in to. All other computers are blocked. Additionally, Group Policies can be used to prevent interactive logon for service accounts.
In Entra ID, Conditional Access Policies can restrict Service Principal access to specific applications and conditions.
Step 5: Monitoring and Alerting
Service accounts have predictable usage patterns: they always log in from the same source systems, always at similar times, always to the same target systems. Deviations from this pattern are potential indicators of a compromise.
Configure alerts for the following events: interactive logon of a service account (should never occur), logon from an unknown source system, logon to an unknown target system, logon outside of normal hours (e.g., when a batch job normally runs only at night), failed logon attempts (may indicate brute-force attempts or Kerberoasting), and changes to service account properties (group memberships, SPN, password flags).
Windows Event Forwarding can send the relevant Security Events (Event ID 4624, 4625, 4768, 4769) from all servers to a central collector. From there, they can be forwarded to a SIEM or a simple alerting system as part of a logging and monitoring strategy.
Step 6: Kerberoasting Protection
Kerberoasting is the most common attack against service accounts in Active Directory. Protection involves several measures.
Strong passwords: Service accounts with SPNs should have passwords of at least 30 characters that are randomly generated. A 30-character password consisting of upper and lowercase letters, numbers, and special characters cannot be cracked with current hardware in a reasonable time.
Prefer gMSAs: gMSAs have automatically generated 240-character passwords that are practically uncrackable for Kerberoasting.
AES encryption: Ensure that Kerberos tickets are encrypted with AES-256, not the older RC4. AES-encrypted tickets are significantly harder to crack.
Monitoring: Monitor Kerberos Service Ticket requests (Event ID 4769). If a single account requests tickets for many different service accounts in a short time, that is a strong indicator of Kerberoasting.
Honeypot accounts: Create a service account with an SPN but no actual function. Any ticket request for this account is suspicious by definition because no legitimate service uses it.
Step 7: Recertification
Service accounts must be regularly reviewed. Recertification ensures that each account is still needed, that permissions are still appropriate, and that an owner is assigned.
A semi-annual recertification cycle is appropriate for most organizations. The process includes exporting all service accounts with their properties, review by the assigned owner (is the account still needed? Are the permissions appropriate?), disabling accounts that are no longer needed (do not delete immediately — disable first, then delete after a grace period), and documenting the results.
Accounts for which no owner can be identified are marked as "orphaned" and disabled through a defined procedure. If nobody notices the deactivation within 30 days, the account is deleted.
Service Account Policy
A service account policy defines the binding rules for creating, managing, and monitoring technical accounts. It should cover the following points.
Naming convention: service accounts follow a uniform naming scheme (e.g., svc-
Regulatory Context
Service accounts fall under several requirements of common frameworks. ISO 27001 addresses them in Annex A.5.16 (Identity Management), A.5.17 (Authentication Information), A.5.18 (Access Rights), and A.8.2 (Privileged Access Rights). NIS2 requires access management measures in Article 21 that also cover technical accounts. BSI IT-Grundschutz addresses the topic in ORP.4 (Identity and Access Management).
Auditors specifically ask about service accounts: how many exist? Who is responsible? How often are passwords rotated? How is least privilege ensured? Anyone unprepared for these questions risks audit findings.
Service accounts are not a peripheral topic. They are a central component of your authorization concept and deserve the same attention as your employees' accounts. In ISMS Lite, you can systematically map the inventory, recertification, and documentation of your service accounts and provide audit evidence. The difference is: for employee accounts, you probably already have processes in place. For service accounts, there is a high likelihood that you still need to establish them. Start with the inventory and work your way through the measures described in this article step by step. Each step reduces a real risk.
Further Reading
- Creating an Authorization Concept: From Role Models to Recertification
- Securing Active Directory: Hardening, Tiering, and Monitoring
- Privileged Access Management (PAM): Keeping Admin Accounts Under Control
- Directory Services: Active Directory vs. Entra ID vs. LDAP
- Logging and Monitoring: Strategy, Tools, and Implementation for SMEs