What is a service account?
A service account is an identity used by software instead of a person. A database engine runs under one, a backup agent uses one to read file shares, a web application uses one to log in to its database, and a CI/CD pipeline uses one to deploy code to the cloud. Nobody sits behind the keyboard, and that is both the point and the problem: the account has to work around the clock without a human typing a password, so its credentials tend to be set once and forgotten.
Cloud platforms have their own versions. Google Cloud calls them service accounts, Microsoft Entra ID uses service principals and managed identities, and AWS workloads typically assume IAM roles. All of them are non-human identities that need the same discipline.
Why service accounts are high-risk
Audits find the same weaknesses again and again:
- Passwords that never expire, set when the software was installed years ago because changing them means updating every server that uses them.
- Too many rights, such as membership in Domain Admins added to make an installer work and never removed.
- Shared knowledge: former admins know the password, or it sits in a script or configuration file.
- Interactive logon allowed, so anyone with the password can sign in at a console or over RDP as if they were a person.
- No owner, so nobody notices when the service is retired and the account lives on.
Attackers target these accounts on purpose. In Active Directory, any authenticated user can request a Kerberos service ticket for an account that has a service principal name (SPN), and part of that ticket is encrypted with a key derived from the account's password. Cracking the ticket offline, a technique called Kerberoasting, often succeeds against a weak, human-chosen password and is impractical against a long random one.
How to secure service accounts
- Give each service its own account with only the rights that service needs.
- Deny interactive use with the Deny log on locally and Deny log on through Remote Desktop Services user rights.
- Let the platform manage the secret. Windows group managed service accounts (gMSAs) have long random passwords that Active Directory rotates automatically, every 30 days by default, and that no administrator ever sees. Cloud managed identities and roles issue short-lived tokens instead of stored keys.
- Where a conventional account can't be avoided, use a long random password kept in a vault or PAM system and rotate it on a schedule.
- Record a named human owner for every service account and include its rights in access reviews.
- Keep secrets out of source code and scripts, and scan repositories for them.
Example: detecting misuse
A service normally signs in as a service (logon type 5) or over the network (logon type 3) from the servers that run it. This Windows Security log entry is a red flag:
Event 4624 Logon Type: 10 Account Name: svc-sqlreport Workstation Name: SALES-LT-118
Logon type 10 is a Remote Desktop session, and a reporting service has no reason to open one from a sales laptop. An alert on interactive logons by any account in the service accounts group catches this misuse even when the attacker has the correct password.
Service accounts vs. user and privileged accounts
A user account belongs to one named person and is protected with MFA. A privileged account belongs to an administrator and is kept separate from everyday work. A service account belongs to software, so an MFA prompt usually isn't possible, which is why the controls shift to managed secrets, restricted logon rights, narrow permissions and monitoring. A service account can also be privileged, and those are among the most dangerous accounts in many environments.
Service account on the CompTIA Security+ exam
Service accounts appear in objective 4.5 on SY0-801, among the account types you manage, and in objective 3.2, where gMSAs and least-privilege account design are part of securing the infrastructure. Watch for scenarios such as a service account signing in through Remote Desktop, a password that hasn't changed in years, a service account in Domain Admins, or a requirement for a password that rotates automatically and that no person knows. The answers follow: deny interactive logon, apply least privilege, and use a gMSA or managed identity. Distractors include account lockout, which doesn't stop an attacker who already has the right password, and more frequent manual password changes, which shorten exposure but still leave people knowing the secret.