Ask an organisation how many administrator accounts it has and you will usually get a number. Ask it to list them and the number changes.
The list that comes back covers the obvious ones: the domain administrator, the Microsoft 365 Global Administrator, perhaps the local administrator on the laptops. What it rarely covers is the firewall’s admin login shared by three people, the backup console that was set up once and never revisited, the website hosting panel, the domain registrar account tied to somebody’s personal email, or the router the internet provider configured with credentials still printed on a sticker.
Every one of those is an administrative account. Every one is a route to your data, your availability, or your ability to recover. And administrative access is the thing attackers are actually looking for, because ordinary user access is a starting position while administrative access is the finish line.
The requirement, plainly
Cyber Essentials asks for administrative accounts to be used only for administrative activity. They must be separate from the accounts people use for their normal work, and they must not be used for email or web browsing.
The reasoning is not bureaucratic. Email and the web are how an attacker reaches your organisation; administrative rights are what they need once they have. Keeping the two apart means a successful phishing email compromises an account that can read one mailbox rather than an account that can rebuild your infrastructure.
Notice what the requirement does not say. It does not say “in your main identity platform”. It says administrative accounts, and that means everywhere you hold them.
And if you do not hold Cyber Essentials and have no intention of pursuing it, none of what follows becomes less useful. The scheme did not invent account separation; it codified something that was already sound practice, because it is one of the few controls that costs nothing, needs no product, and materially changes what an attacker can do with a stolen password. Read the rest as security advice that happens to also satisfy an assessment, rather than the other way round.
Where administrative accounts actually live
Most organisations underestimate this list. Work through it honestly:
| Where | Typical account | Common failure |
|---|---|---|
| Windows and macOS devices | Local administrator | Users are permanent local administrators of their own machines |
| Identity platform | Global Administrator, or domain administrator | Also used as a daily mailbox |
| Servers, on premises or hosted | Domain or local administrator | Shared password, unchanged for years |
| Firewall and network equipment | admin, or a vendor default | One shared login for the whole team |
| Wireless controllers and switches | admin | Never revisited after installation |
| Backup platform | Backup administrator | Same credentials as the systems it protects |
| Website and content management system | Administrator | Former developer still has access |
| Web hosting and domain registrar | Account owner | Tied to one person’s personal email address |
| Line of business applications | Application administrator | Supplier holds an account nobody tracks |
| Cloud platforms and any other service in scope | Owner or administrator | Created during a trial and forgotten |
That last column is the point. The failure is rarely the absence of a control. It is that nobody has a list.
Five principles that apply everywhere
Separate accounts for separate purposes. A named administrative account, distinct from the user’s normal account, used to perform administrative tasks and then signed out of. On devices this means people work as standard users and elevate when required. On cloud services it means a second account rather than extra rights bolted onto the first.
Named accounts, not shared ones. A shared admin login means every action is attributable to “somebody”, which is useless during an investigation and worse during a dispute. It also means the password survives departures. Where a platform genuinely only supports one login, the compensating controls are a password manager with individual access, a record of who has it, and a rotation when anyone with access leaves.
Least privilege, deliberately chosen. Most platforms have roles between “read only” and “everything”. Use them. Somebody who needs to restore a file does not need to reconfigure the backup job, and somebody who needs to publish a blog post does not need to install plugins.
Strong, phishing-resistant authentication. Multi-factor authentication on every administrative account is the baseline, and for the accounts that own your infrastructure a hardware security key is better than a code. Codes can be intercepted, relayed by an attacker-in-the-middle proxy, or approved by a tired person at eight in the morning; a FIDO2 key cannot be used by someone who does not physically have it.
A way back in. Tightening administrative access without planning recovery is how organisations lock themselves out of their own systems. Emergency access accounts, credentials stored securely offline, and a tested route back are part of the control rather than an afterthought.
Write down every system your organisation depends on, then name the person who administers each one and the account they use. If any line says "we all use the same one", "the previous provider set it up", or "I'm not sure", you have found the work. This exercise takes an afternoon and finds more real risk than most tooling.
Devices: the local administrator problem
The most common finding in small organisations is that everybody is a local administrator of their own machine, usually because it was easier during setup and nobody revisited it.
The consequence is that any malware executing in that user’s session inherits administrative rights on the device. It can install services, disable protection, and persist. Removing standing local administrator rights is one of the highest value changes available, and the objection is always the same: people occasionally need to install things.
The practical answers, in order of preference: package the software people legitimately need so they do not have to install it; use a privilege management approach that grants elevation for a specific task; or issue a separate local administrative account for the small number of people who genuinely need one, used only when required. What does not work is leaving everyone permanently elevated and writing a policy asking them to be careful.
Cloud services: more of them than you think
Every cloud service in scope has an administrative tier, and the accounts sitting in it accumulate quietly: the person who set up the trial, the consultant who did the migration, the supplier’s support team, the employee who has since moved to a different department.
Three checks, run against every service rather than only the big one:
- Who holds administrative access, and does each still need it? Include suppliers and former staff. A leaver disabled in your identity platform may still have a direct login to a service that was never joined to it.
- Is administrative access protected by multi-factor authentication? On every service, not just the ones that made it easy.
- What can integrated applications do? An application granted broad permissions to your mail or files holds administrative-grade access without appearing on any list of administrators, which is exactly why it gets missed.
For the Microsoft 365 specifics, including emergency access accounts, role selection and Conditional Access aimed at administrative roles, we covered that ground in detail in administrator account security in Microsoft 365.
Infrastructure: the accounts nobody owns
Firewalls, switches, wireless controllers, network attached storage, the backup appliance, the printer with a web interface and a default password. This equipment is installed once, works, and is then invisible until it stops.
Worth checking on each: has the default account been renamed or disabled, is there a named account per administrator, is remote management exposed to the internet, is multi-factor authentication available and enabled, and does anyone outside the organisation still hold credentials from the installation.
The backup platform deserves particular attention. Ransomware operators target backups deliberately, and a backup system administered with the same credentials as the environment it protects is not a recovery plan; it is a second copy of the same problem.
Keeping it true
Administrative access grows by accretion. Someone needs a role for a project, the project ends, the role stays. A supplier is granted access for a migration and nobody withdraws it. Somebody changes job and keeps everything they had before.
None of that is negligence, it is entropy. The answer is a scheduled review rather than heroics: quarterly, list every administrative account across every system, confirm each is still required and still owned by a named person, remove the rest, and record that you did it. That record doubles as evidence when a customer questionnaire or a certification assessment asks how you manage privileged access, and it makes staying compliant with Cyber Essentials a routine rather than an annual scramble.
Where to start
If you have never listed your administrative accounts, start there. It costs an afternoon and it reliably finds something.
If you would rather someone independent did it, an independent security audit covers privileged access across your whole estate rather than one platform, and our Microsoft 365 Security review goes deeper on that tenant specifically. Get in touch or call 01722 445972.