Least-privilege access is a security principle in which a user, process, application, service, device or other subject is granted only the permissions required to perform its legitimate tasks, and no more. The principle applies both to the types of operations permitted and to the resources on which those operations may be performed. For example, an application that only needs to read records from one database table should not ordinarily receive permission to modify the entire database.
A support employee who needs to view customer information may not need permission to delete accounts. Least privilege is intended to reduce the consequences of compromised credentials, malicious behaviour, programming errors and accidental actions by limiting what an identity can do after access has been obtained.
Least privilege is closely related to the principle of minimising the attack surface. Every permission provides some capability, and excessive permissions create opportunities for misuse or exploitation. If an attacker compromises a low-privilege account, the attacker should encounter technical restrictions that prevent unrestricted movement through the environment. Similarly, if a vulnerable application is compromised, the operating-system account under which it runs should ideally lack permissions that would allow the attacker to modify sensitive files or access unrelated systems. Least privilege therefore applies to humans and machines. Service accounts, containers, background processes, APIs, cloud workloads and database connections should all receive only the capabilities necessary for their intended functions.
Least privilege can be implemented through role-based access control, attribute-based policies, operating-system permissions, application authorisation, cloud identity policies, privileged-access-management systems and temporary elevation mechanisms. A user might normally operate as a standard account and obtain administrative privileges only for a specific approved task. Just-in-time access provides privileges for a limited period and removes them afterwards. Just-enough-administration is a related approach in which administrative users receive only the particular commands or capabilities needed for a task rather than unrestricted administrator access. These mechanisms are especially useful for high-impact environments because permanent administrator privileges increase the potential consequences of credential compromise and human error.
Least privilege has a strong relationship with separation of duties and defence in depth. Separation of duties prevents one identity from independently completing certain combinations of sensitive actions, while least privilege limits each identity's individual capabilities. For example, one employee might prepare a payment and another approve it, with neither role having unrestricted authority over the entire process. Defence in depth means that if one security control fails, other controls remain.
Least privilege contributes to this by constraining what a compromised account or process can access. It does not eliminate vulnerabilities, but it can limit their blast radius. This makes it particularly important in systems where applications process sensitive information or have access to many other resources.
Implementing least privilege can be difficult because organisations must determine what permissions are actually necessary. Overly broad permissions are easy to grant because they reduce the chance that a user will encounter an access-denied error, but they increase risk. Excessively restrictive permissions can interfere with legitimate work and encourage users or administrators to create insecure workarounds. Effective least-privilege programmes therefore use discovery, monitoring, access reviews and incremental refinement. Permissions should be based on actual job functions and application requirements rather than assumptions. Automated analysis can identify unused permissions, while temporary elevation can address unusual tasks without making exceptional privileges permanent.
Least privilege is important in cloud computing because cloud identities often have access to many independently managed services. A poorly scoped identity policy can allow a compromised workload to access storage, databases, secrets or administrative APIs that it does not need. Cloud platforms therefore provide mechanisms for narrowly scoped roles, resource-level permissions, conditions and temporary credentials.
The same principle applies to containerised and microservice architectures: each service should have access only to the APIs, secrets and data required for its function. Network segmentation can reinforce this by limiting connectivity, although network reachability and application authorisation are separate controls. Least privilege is thus both an identity-management principle and a broader architectural design principle.
A common misconception is that least privilege means giving users the absolute minimum permissions forever. In practice, the goal is appropriate privilege for the required task, with permissions that can change as legitimate needs change. Another misconception is that least privilege applies only to administrators. Ordinary users, applications and automated processes can all be overprivileged. A further misconception is that read-only access is always harmless: sensitive information can itself be valuable, and an attacker who can read secrets may use them to obtain further access. Least privilege therefore concerns the sensitivity and consequences of every capability, not simply whether a permission permits modification.
Least privilege provides risk reduction rather than an absolute security guarantee. It can limit an attacker's ability to access unrelated resources, but attackers may still exploit the privileges legitimately assigned to the compromised identity. Poorly designed applications can also contain privilege-escalation vulnerabilities that allow a user to obtain permissions beyond those intended. Effective least-privilege architecture therefore combines narrowly scoped permissions with secure authentication, strong authorisation checks, privileged-access management, monitoring, vulnerability management and regular access reviews. The principle is most effective when treated as a continuous lifecycle process rather than a one-time configuration exercise: determine required capabilities, grant them narrowly, monitor their use, remove unnecessary privileges and provide controlled temporary elevation when exceptional work requires it.
