Most organisations know they need to remove local administrator rights. Far fewer know how to do it without a flood of helpdesk tickets.<\/p>\n\n\n\n
Removing local administrator rights from endpoints sounds straightforward. From a security perspective, reducing unnecessary privilege is an obvious step, but simply taking those rights away can create a different problem. If users still need elevated permissions to install an application, complete a task or support a business process, the organisation can end up trading one problem for another. The question is therefore not whether users need administrator rights. It is whether they need permanent<\/strong> administrator rights. In many environments, the answer is no, but historical application requirements, inconsistent endpoint configurations and a lack of visibility into how privilege is being used can make changing that difficult. <\/p>\n\n\n\n Privilege escalation sits at the centre of the Microsoft threat landscape. Elevation of Privilege vulnerabilities made up 40% of all Microsoft vulnerabilities disclosed in 2025 (509 of 1,273), and the number rated critical doubled from 78 to 157.1<\/sup> Removing standing administrator rights limits what an attacker can do with any one of those flaws once they have a foothold on a device. It is also a named expectation in Australia\u2019s national cyber baseline. Restricting administrative privileges is one of the eight mitigation strategies in the ASD Essential Eight<\/a>2<\/sup>, and least privilege is a foundation of any Zero Trust<\/a> approach.<\/p>\n\n\n\n When administrator rights are removed without understanding why they exist, the impact is usually felt quickly by users. They may find themselves unable to complete tasks they previously handled themselves, waiting for access or approval to perform something they will ultimately be allowed to do anyway. What starts as a security improvement can therefore create a productivity hit for users, while also increasing operational overhead and support requests for IT. <\/p>\n\n\n\n There is also a behavioural consequence that is easy to overlook. When legitimate work becomes difficult, people will naturally look for another way to get the job done, whether that means requesting temporary access, using workarounds or asking for an exception. Over time, those exceptions can undermine the original security objective and create a privileged access model that is harder to manage than the one it replaced. <\/p>\n\n\n\n The answer is to separate the need for access from the need for permanent privilege. Users can operate with standard permissions for their normal activities, with elevated access provided when there is a legitimate business or technical requirement. This changes the focus from removing privilege altogether to providing the appropriate level of privilege when it is actually required. <\/p>\n\n\n\n This starts with understanding the environment rather than immediately applying a policy. Who has administrator rights, why they have them, which applications require elevation, which tasks need it and how frequently it occurs all provide useful information for deciding what needs to change. It also helps identify where administrator rights are genuinely required and where they may simply have remained in place because nobody has revisited the original requirement. <\/p>\n\n\n\n From there, the organisation can determine how those requirements can be handled without giving users unrestricted access. Applications may need to be updated or reconfigured, certain processes may need to change and some tasks may require controlled elevation. The aim is to address the underlying requirement rather than simply replacing permanent administrator rights with another process that creates unnecessary friction. <\/p>\n\n\n\n The user experience needs to be part of that design. A well-designed approach allows a user to complete a legitimate task when elevation is required, while the organisation retains control over what can be elevated, who can do it and under what conditions. The user does not need to understand the security controls behind the experience; they simply need to be able to complete their work without unnecessary friction. <\/p>\n\n\n\n In our experience, organisations that get this right build their approach around four principles: <\/p>\n\n\n\n This is where endpoint security and user experience need to be considered together. A control that is technically secure but regularly prevents users from completing legitimate work will create pressure for exceptions, and those exceptions can ultimately become a greater risk. Security controls need to work within the way people and applications actually operate rather than assuming every endpoint requirement can be treated in the same way. <\/p>\n\n\n\n The objective is not to remove every instance of elevated access. It is to make privileged access\u202fdeliberate, controlled and proportionate to the task being performed, rather than something that is permanently assigned to a user. Some users and applications will have legitimate requirements for elevation, but that does not automatically mean those users need unrestricted administrator rights every day. <\/p>\n\n\n\n For organisations looking to reduce endpoint privilege, the starting point is understanding where privilege exists today, why it exists and what the user actually needs to accomplish. From there, it becomes possible to determine where permanent administrator rights can be removed, where applications or processes need to change and where controlled elevation provides a better balance. The result is not simply a more secure endpoint, but an approach to privilege that is easier to manage and better aligned with how the organisation operates. <\/p>\n\n\n\n The conversation then changes from\u202f\u201cHow do we remove local administrator rights?\u201d\u202fto\u202f\u201cHow do we give users the access they need without giving them more privilege than they need?\u201d That shift moves the discussion beyond implementing a security control and towards designing an endpoint experience that supports both security and productivity. Ultimately, the goal is not to make users less capable; it is to make privileged access more intentional. <\/p>\n\n\n\n For organisations already invested in the Microsoft stack, much of what is needed to support this model is available through Microsoft Intune<\/a>. Intune provides the management foundation for consistent endpoint configuration and policy. Endpoint Privilege Management (EPM) builds on it, allowing users to work with standard permissions day to day while specific, approved applications and tasks are elevated according to rules the organisation defines. Elevation can be automatic for trusted applications, require the user to confirm and provide a justification, or require approval from a support team, and every elevation is logged and reported.3<\/sup>\u00a0<\/p>\n\n\n\n Licensing has also changed. From July 2026, Microsoft 365 E5 includes Endpoint Privilege Management, while Microsoft 365 E3 adds Remote Help, Advanced Analytics and Intune Plan 2 capabilities but not EPM. On other plans, EPM remains available as an add-on or as part of the Intune Suite.4<\/sup> Microsoft notifies tenants through the Message Center before the capabilities are activated, so it is worth checking whether your organisation already has an entitlement. <\/p>\n\n\n\n Policy design, application testing and rollout sequencing determine whether users notice the change. Many organisations therefore pair EPM with Managed Intune<\/a> support, so that elevation rules stay current as applications and requirements change. For a broader view of the platform, see our guide to Microsoft Intune<\/a>.\u00a0<\/p>\n\n\n\nWhy this matters now <\/h2>\n\n\n\n
<\/p>\n\n\n\nThe problem with simply removing access<\/h2>\n\n\n\n
Moving from permanent privilege to controlled elevation<\/h2>\n\n\n\n
A blueprint for success <\/h2>\n\n\n\n
\n
Security without unnecessary friction<\/h2>\n\n\n\n
Microsoft Intune Endpoint Privilege Management: How it fits <\/h2>\n\n\n\n
Frequently asked questions<\/h2>\n\n\n\n