In every company from twenty people up there's a second group of users running in parallel that the board knows nothing about. It doesn't collect a salary, doesn't attend meetings and doesn't retire. It does, however, log in to the most critical systems, often with administrator rights. These are service accounts — and in most SMEs, nobody can tell you how many of them exist.
This isn't theory. On one of our audit projects, the integration between Comarch Optima and the warehouse system was running under an account called "integracja". An external consultant had created it four years earlier, added it to the Domain Admins group "just in case", and nobody had touched it since. The password sat in a plain configuration file on a network drive that the entire accounting department could read. If an attacker landed inside that network — and landing inside is not the hard part these days — they would have had a trusted key to everything.
This piece is about why these accounts are the biggest and simultaneously the most ignored security gap in an SME, and what you can do about it on a normal budget.
What service accounts are
A service account is an account that doesn't belong to a specific person. A process logs in with it: a script, an integration, a network printer, a backup job, an accounting app talking to a bank. Typical examples in a 20–50 person company:
- The account behind the ERP-to-WMS or ERP-to-courier integration.
- The account that runs the nightly database backup.
- The technical account of a webshop connecting to Comarch Optima or Subiekt.
- The account on a multifunction printer, so it can scan to a shared folder.
- The account behind a monitoring agent (Zabbix, PRTG, Nagios) walking your servers.
- The account behind the PowerShell script that emails a weekly report to the owner.
These accounts share one property: nobody deliberately logs in with them. They're meant to be invisible. That's exactly why they make such a good target.
Why they're a problem
Employee accounts have a lifecycle. You hire, you create an account. You offboard, you disable it. You rotate passwords. You roll out MFA. A service account has no lifecycle. It's created once, "to make the thing work", and it stays there forever. The pattern in a typical SME looks like this:
- The password never changes — because "everything will break if we touch it".
- Permissions grow, never shrink — because it's easier to add a role than to figure out which one is actually needed.
- The password lives in a file — a config file, a script, an email to a consultant three years ago.
- No MFA — because a printer can't confirm a code on a phone.
- No logs — because nobody bothered to monitor something that "just runs all the time".
The result is predictable. An attacker who gets onto one machine in the company (via phishing, a browser flaw, whatever) starts looking around. They don't go straight for the Domain Admin — someone might be watching that one. They go for the backup account, the integracja account, the sql-service account. They find the password in a script, saved back when nobody could be bothered to do things properly. From that moment on they move around your network as a trusted process.
At one client — an 18-person electrical wholesaler — we found 4 service accounts, each of them with Domain Admin rights. Two of them had their passwords sitting in .ini files on a network drive readable by every employee. Replacing all four with separate accounts, each with the minimum permissions actually needed, took us 3 weeks of work. The cost of that work was a fraction of what the same company had spent the year before on a commercial antivirus — and the real hole you could drive a tank through was sitting right there.
How to run the inventory
Before you change anything, you need to know what you have. Service accounts are scattered, so there's no single "show me the list" button. But there is a short, practical list of places where they live:
- Active Directory / Entra ID — filter for accounts that never sign in interactively but still have active sessions or belong to privileged groups.
- Application servers — check which account runs the Windows services (Services → LogOn). Anything in the form
.\Administratoris almost always worth a look. - Databases — which accounts connect to SQL Server, MySQL, Postgres. Accounts named
sa,root,appnearly always mean something. - Scripts and scheduled tasks — Task Scheduler, cron, PowerShell scripts on servers. The account behind a task is a service account.
- SaaS apps — accounts used for integrations with Comarch Optima, banks, couriers, webshops. They usually have "api" or "integration" in the name, or are inboxes like
it@company.pl. - Devices — printers, scanners, cameras. They typically log in with a single account to a shared folder.
The output is a spreadsheet: account name / where it signs in / what it does / when its password was last touched / who knows where that password lives. In most SMEs this spreadsheet does not exist. Just producing it is half the win.
How to manage them
Service-account hygiene isn't one big project. It's a handful of habits you introduce once and maintain.
- One account = one job. The backup account doesn't sign in to the courier system. If one account covers three jobs, one compromise costs you three jobs at once.
- Least privilege. An ERP-to-WMS integration account does not need to be Domain Admin. Almost never. Start with the smallest set of permissions and add more only when something actually stops working.
- Passwords in a password manager, not in a file. Bitwarden, 1Password, KeePass — anything except plaintext on disk. Enterprise-class tools (Azure Key Vault, AWS Secrets Manager) can rotate passwords automatically, but even a plain vault is an order of magnitude better than
config.ini. - Managed Service Accounts on Windows. If you run Active Directory, gMSA (group Managed Service Accounts) rotate their own passwords and eliminate the "password in a file" problem entirely. This is one of the few things worth deploying even in a small environment.
- Rotate every 12 months. Put it in the calendar once. If the password can't be changed without restarting everything, that's a sign the account is badly designed — not an excuse to leave it alone.
- Alert on unusual sign-ins. The
backupaccount that suddenly signs in at 3 a.m. from the accountant's laptop is an attack. A simple email alert is enough — you don't need to buy a SIEM.
What next
In most companies we walk into with a security audit, service accounts are the piece nobody thought about before. Not because people are irresponsible, but because these accounts are, by definition, invisible. You only see them once you deliberately count them.
If you don't know how many of these accounts are running in your company right now, don't guess. Start with a 30-minute conversation. We'll tell you where to look, in what order to reduce the risk, and what you can do yourself before you engage anyone from outside.
An account you can't see isn't an account that doesn't exist. It's an account nobody is protecting.