Least privilege is the security principle that every user, device, application and service account should have only the access it needs to do its job, and only for as long as it needs it. It applies to file shares, cloud consoles, business applications, network segments and admin rights on laptops alike. The idea is simple; the work is in deciding what “needs” means for each role and keeping access trimmed as people, systems and vendors change.
At a glance
- A principle, not a product: you apply it through identity, access and governance tools plus regular review.
- Covers human users and non-human accounts such as service accounts, API keys and integrations.
- Limits the damage a stolen account, malicious insider or mistake can cause.
- Commonly expected by cyber insurers, auditors and frameworks, which may ask how admin access is restricted and reviewed.
- Often extended with just-in-time access: elevated rights granted for a task and removed afterwards.
What problem it solves
Access tends to grow and rarely shrinks. New hires get copied from a colleague’s profile, people keep old permissions when they change roles, contractors keep accounts after projects end, and admin rights get handed out to unblock a ticket and never taken back. Over time, many accounts can reach far more than their owners use.
That matters because attackers often start with one ordinary account, often through phishing or stolen passwords, and then use whatever that account can reach. If a regular user has local admin rights, broad file-share access and a role in the finance system they no longer need, a single compromise becomes much more serious. The same applies to an insider threat, whether malicious or accidental. Least privilege shrinks the blast radius: when something goes wrong, less is exposed.
How it works
Define what each role needs. Start from job functions rather than individuals. Group the permissions a role genuinely uses, often through role-based access control (RBAC), so new staff get a consistent, minimal set.
Separate everyday and elevated access. Administrators use a normal account for email and browsing and a separate privileged account, or a time-limited elevation, for admin tasks. Privileged access management (PAM) tools typically vault admin credentials, broker sessions and grant elevation on approval.
Remove standing admin rights where possible. Many organizations remove local admin rights from user laptops and allow specific approved actions instead. Cloud and SaaS admin roles are scoped to what each person manages rather than granted globally.
Cover non-human accounts. Non-human identities such as service accounts, API tokens and automation are given narrowly scoped permissions, assigned an owner and rotated.
Review and remove. Access reviews, usually run through identity governance and administration (IGA) or your identity and access management (IAM) platform, ask managers to confirm what their teams still need. Leavers and role changes should trigger removal, ideally automatically from the HR system.
When it matters for buyers
- When cyber insurance renews. Applications commonly ask about admin rights, privileged account controls and MFA on admin access.
- When preparing for an audit or framework. SOC 2, ISO 27001, PCI DSS, HIPAA and similar requirements generally expect access to be limited by need and reviewed; the exact wording varies by framework.
- When moving to cloud or SaaS. Default admin roles are often broad, and cloud permissions multiply quickly without design.
- When evaluating PAM, IGA or zero trust tools. These products help enforce and evidence least privilege; none of them decides your roles for you.
- After an incident or near miss. Reviewing what a compromised account could reach is often the clearest argument for tightening access.
Questions to ask vendors
- How does your product discover who has access to what today, including dormant and over-privileged accounts?
- Can it grant elevated access just in time, with approval and automatic expiry?
- How does it handle service accounts, API keys and other non-human identities?
- Which of our systems (directory, cloud platforms, SaaS apps, servers, databases) can it manage or report on, and which require custom work?
- What evidence does it produce for auditors, such as access review records and privileged session logs?
- How does it connect to our HR system so joiners, movers and leavers are handled automatically?
How it differs from zero trust
Zero trust security is a broader model: it treats no user, device or network location as trusted by default and checks each access request using identity, device health and context. Least privilege is one principle within that model, concerned with how much access is granted once a request is allowed. You can apply least privilege without a full zero trust program, and a zero trust program that grants broad access after verification falls short on least privilege. For tooling that enforces it on admin accounts, see our privileged access management overview.