Earlier this week, Microsoft published new guidance on AI-powered identity and network access security in 2026. The focus is on four priorities: faster AI-driven protection, governing AI agents as first-class identities, unifying identity and network access, and strengthening the identity foundation.
It is all about least privilege at the identity layer: Conditional Access, risk-based policies, and an integrated view of who can access what in the cloud. If you live in Microsoft Entra and Microsoft 365, it makes a lot of sense.
There is only one problem: most real-world attacks still land on Windows endpoints. And on the endpoint, the biggest question is often much simpler:
Is this person a standard user… or a local admin?
Identity-first is not enough if everyone is still a local admin
The Microsoft guidance talks a lot about identity-first security, Access Fabric, and AI agents helping you design smarter policies in the cloud. Those are good things. But if the person using that identity is still a local administrator on their laptop, you have a very large hole in your story.
Consider a typical chain:
- An attacker phishes a user, or tricks them into running something on their Windows device.
- That code runs in the same context the user has on the endpoint.
- If the user is local admin, malware can:
- Disable or tamper with security tools
- Install persistence and additional payloads
- Dump credentials and move laterally
Your AI-powered identity controls might notice something odd at the account or network layer, but by then the attacker may already have high privilege on at least one device.
In other words: identity-level least privilege and endpoint-level least privilege need to evolve together.
Where cloud identity controls stop
Modern identity platforms are good at answering questions like:
- “Should this user be able to access this SaaS app from this location on this device?”
- “Is this sign-in risky based on behavior and context?”
- “Should we require strong MFA or block access entirely?”
What they traditionally do not answer is:
- “Is this Windows user a local admin on their machine?”
- “Which apps are running with elevated rights on that endpoint?”
- “How are those apps being elevated, and is that process under control?”
That last set of questions is where local admin rights, UAC prompts, and elevation tools live. It is also where many of the practical problems show up:
- Legacy Windows apps that “only work as admin”.
- Developers who default to running their whole session as admin.
- IT teams typing local admin passwords into UAC prompts to “get things done”.
You can have beautiful Conditional Access policies and AI-assisted identity analytics, and still be one phishing click away from a compromised admin session on a laptop.
Bridging the gap: bring least privilege to the endpoint
So how do you align Microsoft’s identity-first priorities with what is happening on your Windows endpoints? Here are four practical steps.
1. Get a simple view of local admin
Start with the basics:
- Which users are in the local Administrators group on each device?
- Which groups (for example, IT or developer groups) automatically grant local admin via Group Policy or Intune?
- Where are local admin accounts being used for day-to-day work instead of break-glass scenarios?
This does not need to be perfect on day one. You are looking for a rough map so you can have honest conversations with security, IT, and app owners.
2. Decide where you really need standing local admin
Next, separate:
- True exceptions – for example, a small number of break-glass accounts or very specific lab environments.
- Habits – “we have always done it this way, it is just easier if everyone is admin”.
Most organisations discover that only a fraction of the people who currently have local admin actually need it all the time. For everyone else, you can aim for a model where they are:
- Standard users for everyday work.
- Given controlled elevation paths for specific tasks or apps.
We walk through this in more detail in posts like The Double-Edged Sword of Local Admin Rights and Five Myths About Removing Local Admin Rights on Windows.
3. Treat elevation like a policy, not a hack
If you currently elevate by:
- Typing in a shared local admin password at UAC prompts, or
- Giving a user two accounts and asking them to “log in as admin when needed”, or
- Letting people stay local admin because of one old application
…you are not really doing least privilege. You are building uncontrolled elevation paths that attackers can abuse just as easily as users can.
A better pattern looks like this:
- Keep users as standard users by default.
- Use built-in platform features like Intune Endpoint Privilege Management or enterprise app deployment for common tasks.
- For stubborn legacy or specialist apps that really do need admin, use a per-app elevation tool so only those executables run elevated.
In other words, elevation becomes a policy decision you can explain and audit, not a collection of shortcuts.
4. Feed endpoint elevation into your wider security picture
The Microsoft identity guidance talks a lot about signals – sign-in risk, device risk, app risk. Your endpoint elevation story can become another signal:
- Which devices are still using standing local admin?
- Which applications are frequently elevated?
- Are there users or departments that generate far more elevation than others?
Once you have that data, you can:
- Focus app remediation work where it will have the biggest impact.
- Feed elevation logs into your SIEM or XDR so unusual patterns stand out.
- Align identity risk decisions with what is really happening on endpoints.
How Elevator fits alongside AI-powered identity security
At UNYK, we built Elevator for Windows for exactly this “last mile” of least privilege on endpoints.
Elevator lets you:
- Keep users as standard users all day.
- Define a short, explicit list of applications that should run with admin rights.
- Run just those apps elevated – not the entire user session.
- Log every elevation event, so you can see what is really happening and adjust over time.
That makes it much easier to say “yes” to identity-first, AI-powered security in the cloud, and “yes” to practical least privilege on Windows devices.
If you are tightening Conditional Access, rolling out phishing-resistant authentication, and looking at AI in your identity stack, this is the perfect time to ask a simple question about your endpoints:
Who is still a local admin, and how quickly can we change that?
If the honest answer is “quite a few people”, we would love you to try Elevator on a handful of your legacy or high-value apps and see how it fits into your least privilege plan.
