Section 1: Where we find ourselves
One of the earliest lessons drilled into us in IT school, and reinforced through nearly every certification path, is the importance of secure defaults and industry best practices. These form the foundation of how we evaluate, implement, and trust the tools we use in the field.
In my current role, I’m fortunate to be in a position where I get to evaluate a wide range of security tools, something I deeply enjoy and take pride in. Recently, I had the opportunity to assess multiple Endpoint Privilege Management (EPM) platforms. What I found was both enlightening and a little concerning. Not because these tools are failing outright, but because many are so close to solving the right problems, yet miss the mark in key ways.
Respect for builders, but room to grow
Before I go any further, I want to acknowledge the immense engineering effort that goes into building these platforms. As someone who leans heavily on scripting and automation in my day-to-day work, I know firsthand how hard it is to create something that’s not just functional, but sustainable. As the saying goes: it’s simple to make something complicated, but complicated to make something simple.
I also want to challenge a common sentiment I’ve heard over the years: “We don’t need better tools, we need better analysts.” While there’s truth to that, I’d argue it’s incomplete. We need better tools and better analysts. Analysts can only be as effective as the systems they operate within, and tools must support, not hinder, the principle of least privilege.
What I observed in the current EPM landscape
After reviewing several leading EPM platforms, I walked away with a mix of appreciation and concern. Each product attempted to tackle the complex challenge of privilege management, and each offered different experiences in terms of interface, granularity, and enforcement logic.
A few common trends emerged:
Limited policy granularity. Many platforms enforced policy at the machine level rather than per user or group. This creates immediate issues in environments where multiple user types share the same endpoints.
Superficial Just-in-Time implementation. The JIT feature often felt more like a trust-based elevation window than a true privilege-on-demand control. To borrow an analogy: it’s like being handed the keys to the Vette for an hour, with no tracking, no oversight, and the hope that you return it safely. This isn’t least privilege. It’s deferred full privilege.
Fragmented logging. Logging was consistently underwhelming. In some platforms, logs were disorganized and difficult to correlate. One product generated hundreds of disjointed log entries for a single endpoint with no coherent structure or searchability.
Where one product got it right
Among the platforms I tested, one stood out. Rather than relying on JIT as a workaround, it enabled granular user- and group-based policy enforcement at the SID level, decoupled from the machine itself. This allowed us to assign specific access based on role and function, bringing us closer to true least privilege without needing broad elevation features.
Of course, even in this model, privileged access must be logged, monitored, and well-defined. But this approach aligned much more closely with the principles we teach and aspire to enforce in our environments.
The path forward for EPM
I don’t think any of these vendors are on the wrong path. In fact, I believe the field of EPM is evolving in the right direction. But the gap between what is marketed as “least privilege” and what is actually implemented can be significant.
My hope is that as the space matures, vendors continue to push toward granular control, context-aware policy enforcement, and truly meaningful logging. These tools are critical to our workflows, and with the right evolution, they can become force multipliers for security teams, not just compliance checkboxes.
Section reflection The best tools don’t just enforce rules. They enable us to make smarter decisions, respond faster, and reduce risk at scale. As someone who uses these tools daily, I’ll continue to challenge them, not out of criticism, but out of the belief that we can, and must, do better.
Section 2: Path forward
Above, I explored why many modern EPM tools struggle to balance administrative simplicity with policy granularity, often falling short of true least privilege.
From my experience, this isn’t an oversight. It’s a design choice. Many products are built with MSPs and MSSPs in mind, optimizing for centralized control and “set-it-and-forget-it” simplicity over fine-tuned local enforcement. And while ease of use is valuable, it can come at the cost of security nuance.
Why shallow policy models aren’t enough
Most “best practices” I’ve seen rely on broad asset or group-based policy models:
- Devices. Certain PCs are permitted elevated actions.
- User groups. All members of a team get elevation rights.
These models are helpful, but incomplete. They address part of the least privilege challenge, not the whole picture. Too often, vendors stop here, not because it’s ideal, but because it fits their product architecture or operational philosophy.
The result? Organizations are left 100 meters short of the finish line, with tools that can’t enforce true contextual elevation control.
My view: what true least privilege looks like
The logic is simple. Most users, most of the time, shouldn’t need elevation. When elevation is required, it should be:
- Transparent, and well logged
- Targeted, scoped to task, app, or process
- Time-bound or event-based, not open-ended
To enforce this effectively, policies should cascade from most specific to least:
- Individual user + device (most specific)
- Functional group or role
- All users (no elevation)
- Implicit deny
Each elevation request is evaluated top-down. If no policy match is found, it isn’t simply denied. It’s logged, reported, and reviewed. This creates a feedback loop to tune future policies, understand user behavior, and identify potential misuse or shadow IT.
A note on administrative overhead
Yes, this model introduces more administrative steps than “allow all members of finance to elevate Excel.” But in practice, elevation events are rarer than most teams assume.
When you strip away assumptions and measure actual elevation requests, you’ll often find that a small percentage of workflows require elevated rights, and most can be handled through predefined policies or temporary, auditable exceptions.
Closing
Least privilege isn’t about reducing trust to zero. It’s about building controls that align with actual user intent and operational need.
The right EPM strategy doesn’t just restrict, it empowers. It provides the structure, clarity, and visibility to ensure elevation is a precision tool, not a default state.