Identity & Access Management
Least Privilege
Is Not a Setting
Understanding and Operationalizing One of Security’s Most Misunderstood Principles
Introduction
Ask any security professional about least privilege and they will tell you it means giving users only the access they need to do their job. The concept is simple. The implementation is not.
Least privilege is one of the oldest and most universally accepted principles in information security. It appears in frameworks like NIST, ISO 27001, SOC 2, and CIS Controls. It is referenced in virtually every security policy document. And yet, it is one of the most consistently violated principles in practice.
This article moves beyond the definition. It explores why least privilege fails, what it actually takes to implement it, and how organizations can build a sustained practice around it rather than treating it as a configuration to be set and forgotten.
01 / The Foundation
What Least Privilege Actually Means
At its core, least privilege means that any user, system, service, or process should have access only to the resources required to perform its designated function — and nothing more.
01
Human Users
Applications, data, and systems
02
Service Accounts
Automated processes and services
03
Privileged Accounts
Administrative and elevated access
04
APIs & Integrations
Connections between systems
05
Cloud Identities
Workload and cloud permissions
The Time Dimension
Access should be granted for as long as it is needed — and no longer.
A contractor who needs elevated access for a project should not retain that access after the project ends.
02 / The Problem
Why Permissions Sprawl Happens
Permissions sprawl — the accumulation of excessive, unnecessary, or outdated access across an environment — is not the result of negligence alone. It is a structural problem that emerges from the way access is typically managed.
01
Access Accumulates
Access is added incrementally over time, with each request appearing reasonable in isolation.
02
Removal Creates Friction
Removing access requires effort and generates friction, so it is often deferred.
03
Roles Age
Role definitions are not always updated as job responsibilities change.
04
Visibility Is Fragmented
Approvers may lack a clear picture of cumulative entitlements.
05
Cloud Moves Fast
Cloud permissions can be created rapidly, outpacing governance processes.
The Consequence
More access.
Larger blast radius.
The average user or service account can accumulate far more access than necessary — and a compromise of that identity can create a disproportionate blast radius.
03 / The Access Model
Two Models. One Practical Approach.
RBAC
Role-Based Access Control
Strength
Scalable and easier to manage in stable environments.
Trade-Off
Roles can accumulate permissions over time, and role proliferation can undermine simplicity.
ABAC
Attribute-Based Access Control
Strength
More granular and dynamic access decisions.
Trade-Off
Greater implementation complexity and the need for robust attribute management.
The Practical Approach
FOUNDATION
CONTEXT
MODEL
Most mature organizations use a hybrid approach: RBAC as the foundational layer, with ABAC policies layered on top for sensitive resources or high-risk access scenarios.
04 / Operationalizing Least Privilege
Just-in-Time Access
Rather than granting standing administrative access — where a privileged user has elevated permissions at all times — JIT access grants elevated permissions only when they are needed and for a defined period.
01
Request
A user or system requests elevated access for a specific task.
02
Approve
The request is approved through an automated or manual workflow.
03
Provision
Elevated access is provisioned for a defined time window.
04
Use
Privileged access is available for the approved task.
05
Revoke
Access is automatically revoked when the window expires.
06
Audit
Activity during the session is logged and auditable.
Defined Time Window
JIT access significantly reduces the attack surface associated with privileged accounts. An adversary who compromises a JIT-enabled identity outside of an active session gains no privileged access, limiting the potential for lateral movement or privilege escalation.
05 / Measuring Maturity
How Close Are You to Least Privilege?
Least privilege is not a binary state — you either have it or you do not. It exists on a spectrum, and measuring your position on that spectrum requires specific metrics.
01
Role-Based vs. Direct Access
02
Permissions per User Relative to Role Baseline
03
Standing vs. JIT-Managed Privilege
04
Time-to-Revoke After Role Change or Termination
05
Access Reviews Resulting in Actual Revocations
06
Orphaned Accounts
The Measurement Principle
Measure the access state — not the policy document.
Tracking these metrics over time tells a clearer story about least privilege maturity than any policy document can.
The Whole Idea, In One Frame
Least Privilege: A Practice, Not a Setting
Least Privilege: A Practice, Not a Setting — infographic summarizing permissions sprawl, operationalizing access, metrics, ownership, process, and accountability.06 / Making It Last
Building a Sustained Practice
Moving least privilege from a policy statement to an operational practice requires three things: ownership, process, and accountability.
01
Ownership
Someone must own the access model — not just the technology, but the policies, the role definitions, and the review cadence.
02
Process
Provisioning, modification, and deprovisioning workflows must be designed with least privilege as a default — not an afterthought.
03
Accountability
Access reviewers, application owners, and managers must be held accountable for the access that exists under their ownership.
Key Takeaways
01
Permissions sprawl is structural — it requires proactive process design to prevent.
02
RBAC provides a scalable foundation; ABAC adds granularity for complex environments.
03
Just-in-Time access is the most effective control for reducing privileged access exposure.
04
Measuring least privilege requires access-state metrics, not policy documentation.
05
Sustained least privilege requires ownership, process, and accountability — not just tooling.
The Bigger Idea
isn't a setting.
It's a practice.
Security / Strategy / Trust
Security isn't just technology.
It's trust.
Exploring identity, security strategy, AI security, and the human side of cybersecurity.
Let's Connect →