---
{
  "title": "Least privilege",
  "summary": "Design access around necessary actions, resources, and duration, with examples of service permissions and temporary administration.",
  "topic": "foundations",
  "level": "Beginner",
  "updated": "2026-10-12",
  "units": [
    4
  ],
  "aliases": [],
  "sources": [
    {
      "title": "NIST: An Introduction to Information Security",
      "url": "https://csrc.nist.gov/pubs/sp/800/12/r1/final"
    },
    {
      "title": "OWASP: Authorization",
      "url": "https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html"
    }
  ],
  "published": "2026-10-02",
  "editorialVersion": 2
}
---

## The smallest useful permission

Least privilege means giving an identity the permissions necessary for a legitimate task, within an appropriate scope and duration. The identity might belong to a person, an application, a cloud workload, or a scheduled job. The principle reduces the damage that a mistake or compromised account can cause. It does not promise that the identity cannot be compromised.

Think in three dimensions: the action, the resource, and the time. A reporting job may need to read a sales table each morning. That requirement does not imply permission to delete the table, read employee medical records, or administer the database server. A role named “reader” is only useful if its actual permissions match the job.

## A reporting service example

Imagine an academy generates a weekly enrollment report. The first implementation uses a database administrator credential because it makes development easy. The report works, but its credential can also modify unrelated tables. If the reporting service is exploited, the attacker inherits those capabilities.

A better design uses a dedicated service identity allowed to read the required reporting view. The view contains the necessary fields, and its permissions exclude unrelated records. The team tests both sides: generating the report must succeed, while attempts to modify data or read another department's tables must fail.

![Least privilege narrows access by permitted action, resource scope, and duration.](/diagrams/least-privilege.svg)

Notice the distinction between intended access and demonstrated access. A policy document saying “read-only” is not sufficient evidence when the account still belongs to an administrative group. Check the effective permissions, including inherited memberships and alternate credentials.

## Temporary elevation for exceptional work

Some tasks genuinely require more access. A production engineer might need to change a configuration during a maintenance window. Instead of using a permanent shared administrator account, the organization can provide named, approved elevation for that task, record its use, and remove it afterward. This connects least privilege with [[privileged-access]].

Temporary access also needs a reliable expiry mechanism. An approval ticket does not remove a permission by itself. If an automated workflow grants access, test whether the workflow revokes it and what happens when a task overruns its window. Emergency access needs a documented recovery route and subsequent review.

## Why permissions grow over time

People change jobs, services acquire features, and temporary exceptions become permanent. This accumulation is often called privilege creep. A useful review starts with current responsibilities and asks whether each entitlement still has a reason to exist. Reviewing a copied list without checking the job can preserve the original problem.

[[identity-and-access-management]] provides the broader processes for onboarding, role changes, and departure. Least privilege supplies a design goal for those processes. [[zero-trust]] adds the wider idea that access decisions should not depend solely on being inside a trusted network.

## A small exercise

Write down the permissions needed by a fictional backup operator. Separate creating a backup, restoring one, deleting historical copies, and changing retention. Decide which actions belong together and which deserve additional approval. Explain the consequence of a stolen operator account under your design.

The exercise has no universal role name as its answer. The useful result is a defensible permission boundary that supports real work, limits unnecessary power, and can be tested.