In most 10–50-person companies, admin accounts look like this: one password, six people, zero audit. When an incident hits, nobody knows who did what — or what needs to change now.
We're not talking about big PAM systems that cost tens of thousands. We're talking about a handful of simple rules you can roll out in a week, which save your skin the day a phisher lands the one bad click.
Admin accounts aren't just "stronger" logins. They're accounts with the power to erase your business in fifteen minutes. As long as you treat them like ordinary logins, one bad day is enough to prove they weren't ordinary.
The problem nobody talks about
In one audit engagement, we walked into a 24-person manufacturing company in the cardboard packaging industry. ERP: Comarch Optima. One account called Administrator on the database server. The password was known to: the owner, two in-house IT people, an external ERP consultant, the head accountant, and one salesperson "who used to write API macros" for shipping orders.
Six people with full access to everything. The password hadn't changed in three years. No MFA. When one of the IT people left, nobody changed the password — because "it would take a week just to notify everyone to update their scripts." Three months later the external consultant lost his laptop. The password still wasn't changed, because nobody knew what that laptop actually had access to.
You don't need us to spell out the problem. Any SME owner reading this is probably picturing their own company right now.
Rule 1 — An admin account is not for daily work
This is the foundation. Every person who needs admin rights should have two accounts: one regular account for daily work, email and web browsing, and one admin account, used only when something in the system actually needs changing.
Why does this matter so much? Because phishing and malicious attachments land in the regular user's inbox. If that user is logged in as admin, the malware immediately gets the keys to the kingdom. If they're on a regular account, the attacker gets one person's privileges — not the whole company's.
- Every person with admin rights gets a separate login (something like
john.smith.adm). - The admin account has no mailbox and no general internet access beyond what's strictly necessary.
- The admin account doesn't log in to a standard workstation — you use it from a separate session, typically via RDP to a management server.
- The regular account is used any time you're not doing something administrative (which is 95% of the time).
At our 24-person packaging company, this took one consultant-day plus one hour of training per person for the 4 people who kept admin rights. The six-person shared account became four separate personal accounts. Two people (the salesperson-with-macros and the head accountant) lost admin access entirely — it turned out they didn't need it; they only needed specific Optima permissions, which we could grant through normal roles.
Rule 2 — MFA on every admin account. No exceptions
MFA on a user account is good practice. MFA on an admin account is the precondition for calling your company secure at all. There's no discussion, no "it wouldn't work here."
If an admin account gives full access to the Comarch Optima server, to Active Directory, to your network gear, or to a cloud console — one password is not enough. Ever. Not even a complex one. Not even one you rotate often.
A hardware key (YubiKey, Feitian) or an app like Microsoft Authenticator costs a few hundred zloty per person. Against what it protects, that cost is a joke. At the packaging company we went with a combination: YubiKey for the domain admin account plus Microsoft Authenticator for Optima and M365 sign-ins.
Rule 3 — Break-glass: an emergency key in the safe
Break-glass is an account you use only when everything else has stopped working. Someone locked themselves out, MFA is down, the whole IT team is on holiday — and something needs fixing right now.
This account:
- Has a very long, unique password (30+ characters, generated randomly).
- Has no MFA (because that's precisely what makes it a break-glass).
- The password is printed on paper, in a sealed envelope, in the company safe.
- It's used once every few months, mostly to test whether it still works.
- Every use of it must be logged and reviewed by the owner or the board.
That sounds paranoid, but it's the one thing that separates "we had a bad day" from "we couldn't invoice sales for three days." In audits we always ask — and in 8 out of 10 companies there's no break-glass at all.
Rule 4 — External accounts with an expiration date
An ERP consultant, a freelance web developer, a Comarch integrator — every such person gets an account with an expiration date. Default 30 days. If it's still needed, you extend it. If you forgot to extend — the account locks itself and nobody notices, unless they were actually using it.
This is trivial. In AD it's one checkbox. In Microsoft cloud, it's one option when you create the user. And it eliminates 90% of the classic "who had access to this three years ago" problem. Because three years from now, that account has been dead a long time.
At the packaging company, when the external consultant lost his laptop (the incident that kicked off the whole project), there was no panic. His account had an expiration date 15 days out, so it would have died on its own. The password was reset for peace of mind, but nobody had to chase a list of "where does this person still log in."
Rule 5 — A quarterly review. Short, but real
Once a quarter — 30 minutes. Somebody sits down with the list of privileged accounts and checks:
- Is every admin account still needed?
- Does the person still work for the company?
- Is MFA active?
- Has the break-glass password been tested?
- Does the admin-usage log contain anything weird?
This doesn't have to be a 50-page document. It can be a five-column Excel table. What matters is that somebody actually does it, instead of "putting it on the backlog."
The outcome at the packaging company
Rolling out these five rules at the 24-person company described earlier took 2 consultant-days plus 4 hours of team training. Cost: less than a mid-range firewall, less than a year of company-wide antivirus licensing.
The result? Four months later, another incident happened — an accounting employee clicked a "vendor invoice" attachment that turned out to be malware. The attackers got access to her regular user account. Nothing more. Not to Optima under the admin, not to the file server under root, not to the Microsoft 365 console under a global admin. The regular account was disabled, the password reset, the case closed in 3 hours.
A year earlier, the same scenario would probably have ended with the Optima server encrypted and a week of recovery work. The difference: a handful of simple rules, two days of work, four hours of training.
Where to start in your company
Do one thing this week: sit down for 15 minutes and write down who has which admin account in your company. File server, ERP, email, cloud console, telco operator panel, ISP panel, the online banking account with transfer permissions.
If after those 15 minutes you have more than one shared account on paper — or fewer than one break-glass account — you have your starting point. You don't have to roll everything out at once. The first thing to do is always to separate admin accounts from regular ones and turn on MFA. That already closes off 80% of the risk.
The rest is a few weeks of background work. But those 80% you should have in place this month.
An admin account isn't a "stronger" account. It's an account where one bad click means the end of the company.