What is the principle of least privilege?
Least privilege is a straightforward concept: give people only the access they need to do their work, and nothing more. If a marketing manager does not need access to the finance system, they should not have it. If a developer does not need Global Admin rights in Entra ID, they should not have them. If a contractor only needs access to one project folder, they should not have access to the entire SharePoint site.
The idea has been around since the 1970s, when computer scientist Jerome Saltzer formulated it as a design principle for operating systems. But it applies just as well to modern cloud environments, SaaS applications, and identity management.
Despite being simple to understand, least privilege is surprisingly difficult to maintain in practice. Access tends to expand over time, and the effort required to keep it minimal is ongoing.
Why is least privilege important?
Least privilege reduces your attack surface. The less access each user has, the less damage can result from any single account being compromised.
Consider a practical scenario: an employee falls for a phishing email and their Microsoft 365 credentials are stolen. If that employee has access only to their own mailbox, their team's SharePoint site, and a few standard business applications, the blast radius is limited. The attacker can access that user's data, which is bad but contained.
Now imagine the same employee also has admin access to the company's CRM, can view all financial records, and has contributor access to the production Azure subscription — all granted over years through role changes and one-off requests that were never cleaned up. The blast radius just expanded dramatically.
Least privilege limits that exposure. It does not prevent the initial compromise, but it significantly reduces what an attacker (or a malicious insider) can do once they are in.
Beyond security, least privilege also matters for compliance. SOC 2, ISO 27001, and NIS2 all expect organizations to grant access based on business need and regularly verify that access remains appropriate. It also matters for data protection — GDPR and other privacy regulations require organizations to limit access to personal data to those who need it. And it reduces human error: people with access they do not need can accidentally modify or delete data they should not be touching.
What does least privilege look like in Entra ID?
In a Microsoft Entra ID environment, applying least privilege means being intentional about a few things.
Directory roles. Entra ID has dozens of built-in admin roles. Instead of making someone a Global Administrator (which grants access to everything), assign the specific role they need. If someone only manages users, give them the User Administrator role. If they only manage groups, give them the Groups Administrator role. Microsoft's own recommendation is to have no more than five Global Administrators in any Entra ID tenant. Many organizations have far more, simply because it was the easiest option at the time.
Group memberships. Be deliberate about which security groups users belong to. Each group typically grants access to specific resources. If a user does not need access to those resources, they should not be in the group. Dynamic groups based on department or role attributes help enforce this automatically.
Application assignments. Not every user needs access to every enterprise application registered in Entra ID. Use user assignment to restrict application access to only the people who need it, rather than leaving applications open to all users by default.
License assignments. A Microsoft 365 E5 license includes capabilities that many users do not need. Rather than giving everyone the most expensive license, match license tiers to actual requirements.
Conditional Access policies. Use Conditional Access to limit how, when, and where users can access resources. An employee accessing email from a managed device on the corporate network is a different risk profile than someone accessing it from an unmanaged device in another country.
Why is least privilege hard to maintain?
If least privilege is such a good idea, why do most organizations struggle with it?
Access is easy to grant, hard to revoke. When someone needs access to a system, the request is urgent — they have work to do. Granting access takes minutes. But no one sends an urgent request to remove access that is no longer needed. There is no immediate pain from excess access, so it lingers.
Role changes do not trigger access cleanup. When someone moves from sales to product management, they get access to their new tools. But their CRM access, sales pipeline visibility, and customer data permissions often remain. This is privilege creep, and it is the biggest enemy of least privilege.
It is hard to know what "minimum necessary" means. For many roles, the exact set of required access is not well-defined. Without clear role-based access profiles, IT defaults to giving people the same access as their peers — which may include years of accumulated permissions.
One-off requests accumulate. "I need temporary access to X for this project" is a reasonable request. But temporary access that is never revoked becomes permanent access. Multiply this by dozens of requests per year across hundreds of employees, and least privilege erodes quickly.
How to implement and maintain least privilege
Define role-based access profiles. For each job function, document the specific systems, groups, and permissions that role requires. Anything beyond the baseline requires justification.
Use automation for provisioning. When access is granted based on role definitions rather than ad-hoc requests, it is naturally more aligned with least privilege. Adcyma automates provisioning in Entra ID based on role profiles, so new hires and role changes get exactly the access they need — no more.
Run regular access reviews. Periodic certification campaigns force managers to look at their team's access and confirm it is still appropriate. Access that cannot be justified gets revoked. This is the ongoing maintenance that keeps least privilege from degrading over time.
Set expiration on temporary access. When granting access for a project or temporary need, set an expiration date. Entra ID supports time-limited group memberships through Privileged Identity Management (PIM). If you are not using PIM, track temporary access in your IGA tool and set reminders for removal.
Audit privileged accounts regularly. Admin accounts and service accounts carry the highest risk. Review them quarterly. Ensure that privileged roles are justified, that the number of Global Admins is minimal, and that privileged access is protected with MFA and Conditional Access policies.
Make it easy to request access. This might sound counterintuitive, but if the process for requesting access is painful and slow, people work around it — sharing credentials, getting admin access "just in case." A quick, transparent request process with proper approvals actually supports least privilege better than a bureaucratic one that people avoid.
Least privilege is not a one-time project. It is a practice — something you build into your processes and maintain through consistent governance.