---
title: "Least-Privilege Access"
description: "Why scoping access down to what's actually needed matters, and how to enforce it with Pangolin's roles, policies, and approvals."
---

Every organization eventually asks the same question: does this person, device, or integration really need to reach everything it currently can? Least-privilege access is the practice of answering "no" by default - granting each identity only the specific resources required for its job, and nothing kept around "just in case." It's sometimes called minimal access or need-to-know access, and it's one of the few security practices that pays off whether or not you're ever attacked, because it also limits how much damage a mistake can do.

## The balance admins actually have to strike

Scope access too loosely and a single compromised account, leaked token, or careless click can reach far more than it should. Scope it too tightly and people spend their day filing access requests instead of working, while whoever approves those requests turns into a bottleneck for routine tasks. Neither extreme is sustainable.

The practical goal isn't "as little access as physically possible" - it's a narrow default combined with a fast, auditable path to widen access temporarily when a real need comes up. A contractor who needs staging access for two weeks should get staging access for two weeks, not permanent access "since we'll probably need them again."

## What tight scoping actually buys you

If an account is compromised, tight scoping means the attacker inherits only what that account could reach - not the whole organization. It also means fewer people hold standing access to any given system, so there are fewer unexpected changes and a more predictable environment overall. When an incident does happen, scoping by role lets you immediately narrow "who could have done this" to the handful of people who actually had the ability to, instead of auditing everyone.

There's an ownership benefit too: access mapped to job function makes it obvious who's responsible for what, instead of everyone having a bit of everything. Onboarding and offboarding get simpler, since assigning or removing a role beats auditing an individual's sprawling permission history one entry at a time. And a lot of compliance frameworks specifically expect access to be scoped to job function - this is one of the easier boxes to check when it's built in from the start rather than bolted on afterward.

## How narrow scope limits real attacks

Most breaches don't start with an attacker breaking into everything at once - they start with one foothold, then depend on that foothold being able to reach more than it should. Tight scoping blunts this at every step. An attacker trying to climb from a low-privileged account into an administrative one, or hijack a peer's similarly-scoped credentials, simply has less to climb into if roles are narrow to begin with. A single stolen credential goes less far, too: passwords get phished, reused, or leaked in unrelated breaches constantly, and if that credential only unlocks one role's resources, the damage is contained. Malware that hijacks a session or a device inherits whatever that session could reach and nothing more. And insider risk shrinks - a disgruntled or careless employee, whether acting deliberately or by mistake, can only affect the systems their role actually touches.

## Applying least privilege with Pangolin

Pangolin gives you the building blocks to enforce this without hand-managing individual permissions:

<Steps>
<Step title="Scope by role, not by person">
  Group users into [roles](/manage/access-control/create-user#roles) - Operations, Contractor, Support, or any custom role you define - instead of granting access to individuals one at a time. Each [resource](/manage/resources/understanding-resources) specifies which roles can reach it, and a user's effective access is just the union of what their roles allow. Revoke a role and every resource it granted access to disappears with it.
</Step>

<Step title="Keep policies consistent across resources">
  Rather than re-configuring authentication and access settings on every resource individually, define a [resource policy](/manage/resources/public/resource-policies) once and attach it wherever the same baseline should apply. This keeps a large number of resources from silently drifting out of sync with each other.
</Step>

<Step title="Narrow further with rules">
  Layer in [access rules](/manage/access-control/rules) that allow, deny, or require authentication based on URL path, IP, CIDR range, country, or region - useful for exposing only the specific paths a role needs, or keeping traffic from regions you don't operate in out entirely. [Geo-blocking](/manage/geoblocking) and [ASN blocking](/manage/asnblocking) extend this to entire countries or networks, including known VPN, proxy, and datacenter ranges.
</Step>

<Step title="Gate new or unrecognized devices">
  [Device approvals](/manage/access-control/approvals) require an administrator to review and approve any new device before it can connect, per role - useful for roles where you don't want valid credentials alone to be sufficient.
</Step>

<Step title="Force re-verification instead of trusting it forever">
  [Session length](/manage/access-control/session-length) and [password rotation](/manage/access-control/password-rotation) policies make sure a credential earned once doesn't stay valid indefinitely. Pair this with [MFA](/manage/access-control/mfa) or hardware [security keys](/manage/access-control/security-keys) so a leaked password alone isn't enough to authenticate.
</Step>

<Step title="Review what actually happened">
  [Admin action logs](/manage/analytics/action) give you an audit trail of configuration changes and administrative actions, so scoping decisions can be revisited based on evidence rather than guesswork.
</Step>
</Steps>

## A checklist worth revisiting periodically

- List what each role can currently reach, and confirm it still matches what that role's job requires.
- Strip standing administrative access from roles that only need it occasionally - grant it temporarily instead.
- Give administrators individual accounts rather than sharing one set of credentials.
- Require MFA or security keys, at minimum for any role with elevated access.
- Enforce session length and password rotation so old credentials don't quietly outlive their usefulness.
- Enable device approvals for roles where an unrecognized device connecting should never happen silently.
- Re-audit roles and their resource access on a recurring schedule, not just when something breaks.
- Use rules, geo-blocking, and ASN blocking to shrink who can even attempt to authenticate in the first place.

<CardGroup cols={2}>
<Card title="Users and Roles" icon="users" href="/manage/access-control/create-user">
  Group users into roles and control who belongs to each one.
</Card>

<Card title="Resource Policies" icon="shield" href="/manage/resources/public/resource-policies">
  Define authentication and access rules once, reuse them everywhere.
</Card>

<Card title="Rules" icon="filter" href="/manage/access-control/rules">
  Allow, deny, or require auth based on path, IP, country, or region.
</Card>

<Card title="Device Approvals" icon="check" href="/manage/access-control/approvals">
  Require admin sign-off before a new device can connect.
</Card>
</CardGroup>