Ask most employees whether they can install software on their work laptop, and the answer is usually yes. They might not know why. It’s just always worked that way. Nobody ever questioned it. IT set the machine up, things needed installing, and so admin rights got handed out.
It’s one of the most common security mistakes in small and medium businesses. And it’s one of the easiest to fix, if you understand why it matters.
What Local Admin Rights Actually Mean
When a user account has local administrator rights on a machine, that account can do almost anything to that device. Install software. Remove security tools. Change system settings. Add new user accounts. Access files belonging to other users. Modify the Windows registry. Disable Windows Defender. Uninstall your endpoint protection agent. Grant themselves access to folders they shouldn’t be able to reach.
In the hands of a competent, security-aware person making deliberate decisions, that kind of access has its place. In the hands of an average employee going about their working day, it’s a loaded weapon sitting on the desk.
The problem isn’t that your people are careless or untrustworthy. The problem is that malware, ransomware, and attackers are specifically designed to exploit whatever permissions the logged-in user already has. If your staff are running as local admins, so is anything that runs in their name. That includes the phishing link they shouldn’t have clicked, the dodgy attachment someone forwarded on, or the fake software update that looked convincing enough.
That’s the crux of it. Your users don’t need to do anything wrong. The attacker just needs to run something in the context of that user’s session, and if that session has admin rights, the attacker has admin rights too.
What Goes Wrong When Everyone Has Admin Rights
Local admin rights on a day-to-day user account creates a category of risk that’s genuinely hard to overstate. Let’s go through it properly.
Malware Runs With Full System Access
Most malware is designed to do as much damage as possible, as quickly as possible. To do that effectively, it needs to be able to modify the system: adding itself to startup processes, disabling security software, creating backdoors, and spreading to other machines on the network.
All of those actions require elevated permissions. If the compromised user account already has them, the malware gets them for free. No privilege escalation needed. No bypassing of UAC prompts. It just runs.
Take something as straightforward as a malicious email attachment. The user opens what looks like an invoice. The attachment executes a script. On a standard user account, that script is limited to what that user can do: write files to their profile, access their documents, connect to the internet. Damaging, but containable. On a local admin account, that same script can disable Windows Defender, write itself to the system directory, create a scheduled task to survive a reboot, and start moving through the network. The difference in outcome isn’t small. It’s the difference between a bad afternoon and a full incident response.
Ransomware Spreads Further and Hits Harder
Ransomware is a specific and particularly destructive example of the above. Its goal is to encrypt as many files as possible before it’s detected and stopped, because the more files it can encrypt, the more leverage the attacker has.
When ransomware runs under a local admin account, it can do things a standard user account simply can’t. It can access Volume Shadow Copies, the Windows backup mechanism, and delete them, removing your ability to restore files without paying. It can move to mapped network drives and encrypt everything there too. It can attempt to spread to other machines on the network using the credentials it has inherited. It can modify file permissions to lock administrators out of their own systems.
The WannaCry ransomware attack in 2017, which hit the NHS and hundreds of other organisations globally, spread so effectively in part because machines were running with excessive privileges and unpatched vulnerabilities that gave the malware everything it needed to move laterally. NotPetya, arguably the most destructive piece of malware ever deployed, used stolen admin credentials to spread across entire corporate networks within hours, because once it had one set of elevated credentials it could reach almost everything.
Remove local admin rights from standard users and you don’t stop ransomware entirely. But you significantly reduce the blast radius. The encryption still happens on the compromised machine. But the lateral movement, the jump to file servers, to other workstations, to systems across the network, becomes much harder without elevated credentials to work with.
Users Install What They Want, and You Have No Idea
This is a risk that doesn’t get nearly enough attention because it doesn’t feel dramatic. No ransomware, no breach, just a user installing software their IT team doesn’t know about.
Except the implications stack up quickly. A user installs a free PDF converter they found via a Google ad. That tool has a browser extension bundled with it. The extension quietly logs what they type in web forms. Another user installs a screen recording tool to help with a presentation. That tool’s licence agreement permits the vendor to collect usage data, including what’s on screen. A third user installs a personal file sync application and starts backing up their work files to a personal cloud account because it’s convenient and nothing’s stopping them.
None of these people are trying to cause a problem. But your data is now in places you didn’t authorise, on platforms outside your control, subject to third-party terms you’ve never reviewed. And because nobody installed it through IT, it’s not in your asset inventory, it’s not being patched, and nobody will notice when a critical vulnerability is disclosed for it.
This is what’s sometimes called shadow IT: software and services running in your business that your IT function doesn’t know about. It’s a compliance problem, a data protection problem, and a security problem all at once. And local admin rights are what makes it possible.
Accidental Damage Is Far Easier Than You Think
Not every admin-rights incident involves malware or a bad actor. Sometimes it’s just a user who deleted the wrong thing, changed the wrong setting, or ran the wrong command and had the access to do real damage when they did it.
Consider a user who finds instructions online for fixing a performance problem on their laptop. The instructions involve editing the registry. On a standard user account, they can’t. On an admin account, they can, and if the instructions are wrong or they make a typo, they can render the machine unbootable. Now IT has to spend time on a rebuild that should never have been necessary.
Or consider a user who goes into folder properties, changes the security permissions without understanding what they’re doing, and inadvertently removes access for service accounts that need to read those files to function. The problem might not surface for days, and tracking it back to the cause takes time that would have been entirely avoided with proper access controls in place.
But What If It’s Time Critical?
This is the argument that comes up every time someone proposes removing local admin rights. Someone will always say it. “But what if a user urgently needs to install something? What if something breaks and IT aren’t immediately available? What if we’re in the middle of a client presentation and something stops working?”
Here’s the honest answer: there should never be a genuinely time-critical situation that requires a standard user to have permanent admin rights on their machine.
Let’s take each scenario.
A user needs software installing urgently? That software should be available through your software deployment tooling, pushed to the machine by IT within minutes without the user needing local admin rights at all. If it’s not, the question to ask is why your deployment process doesn’t cover it, not why the user doesn’t have admin access.
Something breaks before a client presentation? Any IT support function worth its retainer should be reachable quickly enough to handle a genuine emergency. If your IT support isn’t responsive enough to handle urgent requests without giving everyone permanent admin rights as a workaround, the problem is your IT support arrangement, not your security policy.
IT aren’t available? Most modern environments support Just-in-Time privileged access: admin rights that can be granted temporarily, for a specific purpose, with a clear audit trail, and revoked automatically afterwards. This is the right solution to temporary admin needs, not making the access permanent by default.
More importantly, consider what urgency actually does to decision-making. Urgency makes people skip steps. It makes them click through UAC prompts without reading them. It makes them install the first search result rather than the verified vendor download. It makes them approve requests they’d normally scrutinise. Attackers know this. Fake IT alerts that create artificial urgency, such as “your machine needs an update immediately, click here”, are a standard social engineering technique precisely because time pressure bypasses the caution people would otherwise apply.
If your security model depends on people making good decisions under pressure, it’s not a security model. It’s an optimistic assumption. Decisions made with admin credentials should be deliberate, documented, and made with time to think. Never rushed. The moment urgency becomes a standing justification for admin access, you’ve created a habit that will eventually be exploited, either by an attacker or by a mistake that wouldn’t have been possible otherwise.
What About People Who Genuinely Need Admin Access?
There are legitimate cases. Developers who need to install build tools, configure local environments, and test software they’re writing. IT staff who need to manage machines, deploy software, and make configuration changes. Security professionals running vulnerability scanners or forensic tools. Some specialist technical roles where the nature of the work genuinely requires system-level access.
None of this is a reason to give them admin rights on their daily working account.
The right answer is a separate account: a distinct user account, either local to the machine or in the domain, that exists specifically for administrative tasks. The person has two accounts. Their standard working account for everything they do day to day. Their admin account for the specific tasks that require elevated access.
Think about what a developer actually does in a typical day. They read emails. They attend Teams calls. They browse Stack Overflow and vendor documentation. They write code in an IDE. They raise tickets, review pull requests, respond to messages. Exactly none of that requires local admin rights. It’s only when they need to install a new development dependency, update a driver, or configure something at the system level that admin access is actually needed, and that might happen a handful of times a week, if that.
So the working account, the account that handles email, browsing, and all the activities where exposure to phishing and malicious links is highest, has no admin rights. When the developer needs to do something that requires elevated access, they use the admin account to do it, then return to their standard account.
The admin account should not be a Microsoft 365 account. It should not be the account that receives email. It should not be the account used to browse the web. It’s a locked-down, purpose-specific account used only for the tasks it exists to perform. Its credentials should be separate from everything else: not a variation of the normal password, not auto-filled by a browser, and ideally managed through a privileged access management solution or at minimum a dedicated password manager entry with a strong, unique password.
The Account Rules That Need to Be in Place
Creating a separate admin account and then using it casually as a second working account defeats the point entirely. The account needs to be governed properly.
It is not a working account. No email. No web browsing. No Teams. No file access beyond what’s needed for the specific task being performed. The admin account exists for one thing. When that thing is done, the session ends.
Sessions should be as short as possible. Log in to perform the task. Log out when it’s done. The admin account should never be sitting in an active but idle session in the background while the user gets on with other work. Every minute an admin session is open is a minute it can be exploited if something else goes wrong.
Strong, unique credentials, managed properly. The admin account password should have no relation to the user’s normal password. It should be long, complex, and stored securely: not written on a post-it, not saved in the browser, not the same as anything else. A password manager is the minimum. A privileged access management (PAM) tool is better.
Multi-factor authentication applies here especially. If anything, the admin account needs stronger authentication controls than the standard account. Every admin login should require a second factor. There are no exceptions to this. The whole point of a separate admin account is that it’s treated as more sensitive than an ordinary account, and that needs to be reflected in how it’s protected.
Everything gets logged. What was done, on which machine, at what time, by which account. Admin activity without an audit trail isn’t just a security gap, it’s a compliance problem and an incident response nightmare. When something goes wrong, you need to be able to reconstruct exactly what happened. Admin accounts with no logging make that nearly impossible.
Disable when not in use where possible. In some environments, you can configure admin accounts to be disabled by default and enabled only for the duration they’re needed, then automatically re-disabled. This is worth implementing wherever it’s practical. An account that doesn’t exist can’t be compromised.
Regular access reviews. Who has an admin account? Do they still need one? Has their role changed? Has someone left the business and their admin account not been removed? Access creep, where people accumulate permissions they no longer need, is one of the most common and avoidable security problems in any organisation. Admin accounts should be reviewed at least every six months.
What You Actually Achieve
Remove local admin rights from standard user accounts, implement proper controls around the accounts that do have them, and here’s what concretely changes.
Malware that successfully compromises a user session is immediately constrained. It can cause damage within the scope of that user’s access, but it can’t disable your security tooling, can’t install itself persistently as a system service, and can’t spread using admin credentials. Containment becomes faster and easier because the blast radius is smaller from the outset.
Ransomware that gets a foothold on one machine still causes damage, but it’s damage on that machine affecting files that user can access. The lateral movement phase, the part where it spreads to your file servers and other workstations and makes the incident catastrophic, becomes significantly harder. Not impossible, but harder. That difference can be the difference between recovering one machine and recovering your entire estate.
Your software estate becomes something you actually know about. The tools on your machines are the tools you’ve deployed. They’re in your asset management, they’re being patched through your patching process, and they’re not creating invisible compliance or data protection exposures you’ll only discover when something goes wrong.
Your security tooling, including endpoint detection and response, antivirus, and monitoring agents, stays in place. A user who’s frustrated with something being flagged can’t just uninstall it. An attacker who gains user-level access can’t remove it as a first step. The tools do their job because they can’t be tampered with.
You’re also well on the way to meeting Cyber Essentials requirements. Least-privilege access, ensuring users operate with only the permissions they need, is a core control in the Cyber Essentials framework. Businesses that want to achieve Cyber Essentials certification need to be able to demonstrate that standard users don’t have admin rights. Getting this right now makes that process considerably more straightforward.
How to Actually Implement This
In a Microsoft environment, removing local admin rights across the estate is straightforward in principle. Group Policy or Microsoft Intune can enforce that user accounts are standard users on all managed devices. Software deployment through Intune, SCCM, or a similar tool means users don’t need admin rights to install approved applications. IT pushes them centrally.
For those who genuinely need admin access, a second account is created in Active Directory or Entra ID with appropriate permissions, governed by the rules above. Privileged Identity Management in Entra ID can handle the just-in-time access model: time-limited elevation, approval workflows, and full audit logging, for organisations using Microsoft 365.
The transition does require some planning. There will almost certainly be applications that break when admin rights are removed, software that was written to require admin access for reasons that were never legitimate or that uses directories it shouldn’t be writing to. Identifying these in advance through a pilot deployment, and either fixing the configuration or replacing the software, is standard practice. It takes some work. It’s work that’s worth doing.
User communication matters too. People who have always had admin rights and suddenly find they can’t install something will push back if they don’t understand why. A short explanation, covering why this is a security improvement, what IT can do instead, and how to request software, goes a long way towards making the transition smooth rather than antagonistic.
This Isn’t About Distrust
It’s worth being direct about what removing local admin rights is not. It’s not a statement that your employees can’t be trusted. It’s not about making people’s working lives harder. Most users will barely notice the change, because most users, most of the time, don’t need admin rights to do their jobs. They just have them because nobody ever took them away.
What it is about is removing unnecessary risk from a threat landscape where the consequences of getting it wrong are serious. The principle of least privilege, give people only the access they need to do their job and no more, exists because access that isn’t needed is access that can be exploited. That’s true whether the threat is an external attacker, a piece of malware, or an honest mistake by a well-intentioned member of staff.
This is one of the highest-value, lowest-cost security improvements available to any business. It won’t stop every attack. Nothing will. But it fundamentally changes what an attacker can do with a compromised user account, and that matters enormously when you’re trying to limit the damage from something that’s already gone wrong.
If you’re not sure where your business currently stands, or you need help implementing least-privilege access across your environment, get in touch. It’s one of the first things we look at when we start working with a new client, because the impact of getting it right is immediate and measurable.
