How service accounts work
A service account exists so software can authenticate without a person at the keyboard. A backup job logging into a database, a web application connecting to a file share, a Windows service running under a domain identity, a CI pipeline calling a cloud API — each of these uses a service account. The account holds whatever permissions the workload needs, and its credential is stored somewhere the software can read it: a configuration file, a registry entry, an environment variable or, ideally, a vault.
Unlike human accounts, service accounts rarely support interactive MFA, seldom change owners cleanly when staff leave, and frequently outlive the projects that created them. A mid-sized enterprise commonly has several times more service accounts than employees.
Why they are a security risk
Service accounts combine the worst properties from an attacker-defense perspective: broad privileges, passwords that never rotate because "something might break", no MFA, and no human who notices when they misbehave. Attackers actively hunt them — techniques like Kerberoasting exist specifically to crack service account passwords in Active Directory, and hardcoded credentials in scripts or repositories are a recurring root cause in breach reports.
Because activity from a service account looks like normal automation, misuse can persist undetected for months. Orphaned accounts, whose owning application was decommissioned years ago, are especially dangerous: nobody misses them, so nobody notices when someone else starts using them.
Governing service accounts in practice
Effective programs start with discovery: enumerating service accounts across Active Directory, servers, databases and cloud platforms, then assigning each one an owner, a purpose and a least-privilege permission set. Credentials move out of config files into a vault, and rotation is automated so passwords change regularly without breaking the dependent application — the hard part being updating every place the credential is consumed.
Monitoring closes the loop: alerting when a service account logs in interactively, from a new host, or outside its normal pattern. Monopam supports this lifecycle with AD, Azure and AWS resource discovery, an encrypted vault with credential history, and automated password rotation for accounts brought under management.