Least privilege

NIST defines least privilege as giving each entity the minimum access needed to do its job. In practice it comes down to three choices: how narrow the role is, how wide the scope is, and how long the access lasts.

What it looks like per platform

• Microsoft 365 and Entra: Microsoft publishes a list of the least privileged role for each admin task. A helpdesk user who resets passwords does not need Global Administrator. Global Administrator should be kept to a small number of accounts.
• Azure: Azure RBAC assigns a role at a scope: management group, subscription, resource group or single resource. Assigning Reader or a custom role at resource-group level is narrower than Owner on the subscription.
• Google Cloud: IAM supports predefined and custom roles, and the role recommender suggests removing permissions that an identity has not used.
• AWS: IAM policies can start broad and be tightened using access analysis, and the root user should not be used for daily work.

Time as a dimension

Access that is only active when needed, often called just-in-time access, reduces standing privilege further. Microsoft Entra Privileged Identity Management is one example for Entra and Azure roles. A person is made eligible for a role, activates it for a limited period when a task requires it, and the activation can be logged and reviewed.

A worked example

Imagine a team member who only has to reset passwords and manage licences for one department. The broad way to do this is to make them Global Administrator, because it works for everything. The least-privilege way is to give them a narrower directory role, limited to an administrative unit that contains that department, for the duration of the project. The task gets done either way, but if their account is phished, the second choice limits the damage to one department.

Attackers rarely begin as administrators. They steal an ordinary account or abuse an app, then look for a way up. The more permission an identity holds, the fewer extra steps they need.

Two situations show the pattern. A service account with owner rights can do anything in its project, so one leaked key becomes a full compromise. An administrator who uses the same account for email and for tenant changes exposes tenant control to every phishing message.

The NSA and CISA advisory AA23-278a includes improper separation of user and administrator privilege among the misconfigurations found most often. Permissions also tend to build up over time as people change role, so without regular review the problem grows quietly.

There is also a cost of getting it wrong in the other direction. If you remove access without checking what depends on it, you can break a nightly job or lock a team out of a system. That is why least privilege is a continuing review, not a one-off clean-up, and why you should look at what an identity actually does before you cut its rights.

1. List your privileged roles on each platform: Global Administrator and other Entra roles, Azure Owner and Contributor, Google Cloud Owner and Editor, AWS administrator policies.
2. Count the people and service accounts that hold them. Remove what nobody can justify.
3. Give administrators a separate account for admin work, protected by MFA.
4. Replace broad roles with the narrowest built-in role that covers the task. Use the vendor guidance for this.
5. Prefer time-limited elevation over permanent assignment where your licensing and tools allow it.
6. Review role assignments on a fixed rhythm, and check the effect of a removal before applying it.