What is the Principle of Least Access?

In this blog post, we will explain the principle of least privilege (POLP), provide the definition and use cases, and explain the importance of the principle. Like many other security principles and concepts, this principle is one part of a larger security strategy that aims at mitigating the risk of security breach.


The principle of least privilege, or “principle of least authority,” is a security best practice that requires limiting privileges to the minimum necessary to perform the job or task. IT administrators often think about this principle in terms of the access rights for user accounts, admin rights and computer security settings. However, the security principle of least privilege has broader applicability, including organization-wide access controls and physical security, and even scenarios outside of the workplace.


Examples of how least privilege helps improve security

To illustrate the value of enforcing the principle of least privilege, let’s walk through a few scenarios:

  • IT administrator. Suppose an organization has a primary administrator who is responsible for deploying and managing most of its Windows servers. However, some teams, such as the email team, manage their own servers. If the organization does not enforce least privileges, both the primary administrator and the email administrators might be granted administrative access to all the company’s servers, which introduces unnecessary risk. For instance, the primary admin might inadvertently made an improper change to an email server, or an email admin’s account might be hacked, which would give the attacker access to all servers in the company. With least privilege, on the other hand, each admin is granted access to only the specific servers they need to manage, limiting the risk of accidental or deliberate damage.
  • Retail bank. Most banks have employees working in various capacities, such as tellers, managers and financial advisors. Without least privilege in place, the bank might allow tellers to access the vault whenever their cash drawer runs low, which increases risk of theft and errors. Limiting access to secure areas like the vault in accordance with principle of least privilege reduces that risk — in that case, tellers must request that designated managers get them additional cash from the vault when needed.
  • Application. Some software applications need to modify particular files and folders. Without the principle of least privilege, the application might run under a service account that has administrative rights to the application servers — enabling an attacker who compromises the application to do serious damage. For stronger information security, the service account should be granted only read, write or update access to the specific files and folders the application needs to modify.

These are just a few examples of how enforcing the principle of least privilege can reduce the risk of malicious behavior and errors, and minimize the ability of malware and attackers who compromise your accounts to access the systems, data and resources in your network.

Least Privilege best practices

As you implement the principle of least privilege, keep the following best practices in mind:

  • Minimize account privileges based on the requirements of the tasks or job. All users should have a least-privileged user account, which can only do what the user is required to do as part of their job.
  • Minimize privileges for non-human accounts such as service accounts. Review vendor documentation to understand the minimum privileged required by each application — and if it says administrative access to the application server is needed, proceed with caution. It is a good practice to implement the application in a test environment where you can try various configurations. I’ve seen some vendors say administrative access is required when lesser permissions will work.
  • Perform periodic access reviews to ensure that the principle of least privilege is being adhered to. It is common for both standard users and administrators to change roles or change departments. What’s less common is for their user access rights to be adjusted during such a change. Employees often build up a large set of privileges, especially if they are with a company for a long time, and it’s important to remove unneeded privileges to reduce risk to your systems and data.

Related best practices

As we have seen, the principle of least privilege is one important way to reduce your overall attack surface area and enhance security. However, it’s essential to remember that a policy of least privilege by itself is not sufficient for strong access management. Here are some other key best practices that will help round out your security strategy:

  • Have administrators use separate accounts based on the task they are performing. For example, admins should use a user account with standard privileges to read email and browse the internet, and log on with credentials that grant elevated privilege only when they need to perform IT administrative tasks.
  • Log and monitor the activities of all account, especially privileged accounts. You need to be able to pinpoint when and how users authenticate, which tasks they perform, and the specific changes they make in the environment.
  • Implement multi-factor authentication for IT administrative accounts. Require administrators to authenticate normally (such as with their ID and password) and then complete a second step using a different authentication mechanism (such as a hardware token or fingerprint) each time they want to perform administrative tasks.


By implementing — and strictly enforcing — the principle of least privilege, you can dramatically improve your organization’s security posture. IT administrators, HR teams and data owners must work together to determine exactly what permissions each account should have and then regularly review and right-size them as necessary to minimize risk.



Expert in Microsoft infrastructure and cloud-based solutions built around Windows, Active Directory, Azure, Microsoft Exchange, System Center, virtualization, and MDOP. In addition to authoring books, Brian writes training content, white papers, and is a technical reviewer on a large number of books and publications.