Requirement
AC.L2-3.1.5 – Employ the principle of least privilege, including for specific security functions and privileged accounts.
This control comes from NIST SP 800-171 REV.2 / CMMC 2.0 Level 2.
Understanding the Requirement
This control requires you to limit user and system access to only what is necessary for assigned job duties and to tightly control who can perform administrative or security-sensitive actions. It means identifying privileged accounts and security functions, assigning the minimum permissions needed, and authorizing access in a way that prevents unnecessary changes to systems or data. The principle of least privilege applies to all users, devices, apps, and background processes across your environment.
Policies and Procedures Needed
Document how access is granted, changed, and removed for each role (onboarding, transfers, and offboarding), including who approves privileged access and for how long. Define your security functions (e.g., email security settings, endpoint policies, identity configurations) and the roles allowed to manage them. Include standards for service accounts and app registrations, periodic access reviews for groups and roles, emergency access (break-glass) procedures, and requirements for multi-factor authentication and device compliance for any administrative activity.
Technical Implementation in Microsoft 365
- Define roles and groups in Entra ID (Azure AD): Create role-based security groups that map to job functions (e.g., Finance-Users, HR-Users, Helpdesk-Tier1). Use built-in Entra ID roles (e.g., Exchange Administrator, Security Administrator, SharePoint Administrator) instead of Global Administrator wherever possible. Scope admin roles with Administrative Units to limit the blast radius to specific departments or regions.
- Enforce just-in-time admin with Privileged Identity Management (PIM): Require eligible (not permanent) assignment to privileged roles, activation with MFA, time-bound sessions, approval workflows, and documented justification. Enable access reviews for these roles to automatically prompt resource owners to re-certify or remove access.
- Conditional Access for privileged activities: Create policies that require MFA for all users, and add stricter controls for privileged roles—such as requiring compliant devices, limiting sign-ins to trusted locations, and blocking legacy authentication. Use Identity Protection to enforce “user risk” and “sign-in risk” policies that challenge or block risky privileged sign-ins.
- Control local admin rights with Intune: Use Intune endpoint security policies to remove standard users from local Administrators on Windows devices. Where needed, enable Intune Endpoint Privilege Management to allow approved applications or tasks to elevate with justification and audit, rather than granting users broad admin rights.
- Secure security functions across Microsoft 365: Assign the least-privileged role groups in Exchange, Microsoft Defender, and Microsoft Purview for tasks like anti-phishing policies, email transport rules, device compliance policies, DLP rules, and audit settings. Separate duties (e.g., Security Reader vs. Security Administrator) and avoid combining roles unless absolutely necessary.
- Govern service accounts and apps in Entra ID: For app registrations and enterprise applications, grant the minimal Graph/API permissions required, prefer certificate credentials over passwords, restrict user consent, and review consented permissions regularly. Use Access Reviews for group and application assignments, and monitor sign-in and audit logs for admin consent and privileged operations.
Example in a Small or Medium Business
Rivertown Analytics, a 120-person firm, maps its job functions to Entra ID groups and assigns team members to those groups during onboarding. Most staff are standard users; local admin rights are removed via Intune, and Intune Endpoint Privilege Management permits the accounting app to elevate only when needed with justification. The IT lead is a permanent Privileged Role Administrator, while Exchange Administrator and Security Administrator are configured as eligible roles in PIM, requiring MFA, manager approval, and one-hour activations. Conditional Access enforces MFA for everyone and adds a stricter policy for privileged roles: compliant device required and sign-ins limited to the corporate network and approved countries. The company lists its security functions—Defender policies, Exchange transport rules, Intune compliance policies, and Purview DLP—and maps each to the lowest necessary built-in role. Quarterly Access Reviews prompt owners to re-certify membership in privileged groups and app assignments, and the owner exports Audit Logs showing role activations, policy changes, and justifications for their compliance record.
Summary
By defining least-privilege roles, scoping administrative rights, and governing access with just-in-time elevation, MFA, compliant devices, and periodic reviews, SMBs can meet AC.L2-3.1.5 in a practical, auditable way. Entra ID provides role-based access, PIM, Conditional Access, Identity Protection, Access Reviews, and detailed Audit Logs, while Intune removes broad local admin rights and enables controlled elevation for specific tasks. Together, these policy and technical controls identify privileged accounts and security functions, authorize only the minimum access required, and continuously verify and log administrative actions.
