How to Meet AC.L2-3.1.4

Requirement

Show: AC.L2-3.1.4 – Separate the duties of individuals to reduce the risk of malevolent activity without collusion. This control comes from NIST SP 800-171 REV.2 / CMMC 2.0 Level 2.

Understanding the Requirement

This control requires you to prevent any single person from being able to perform all steps of a critical task. Define which duties need separation, assign those responsibilities to different individuals, and grant the necessary access privileges so those individuals can perform only their part. Without separation of duties, a person could create, approve, and conceal changes, bypassing controls; splitting duties reduces the risk of malevolent activity and makes errors easier to detect.

Policies and Procedures Needed

Create a separation-of-duties (SoD) policy with a RACI-style matrix that identifies critical tasks (e.g., account provisioning, privilege assignment, mailbox/SharePoint administration, MFA resets, billing, security configuration) and mandates distinct individuals for initiation, approval, and review. Embed SoD checkpoints in onboarding/offboarding (who creates accounts vs. who assigns roles), device authorization (who enrolls vs. who approves compliance policies), service account governance (who requests vs. who approves credentials/permissions), change management (two-person approval for high-impact changes), and periodic access reviews (independent verification of privileged roles, group memberships, and app access). Document break-glass procedures and emergency elevation with after-the-fact review by a different person.

Technical Implementation in Microsoft 365

• Establish role-based administration in Entra ID (Azure AD). Map duties to built-in roles (e.g., User Administrator for account creation, Privileged Role Administrator for role assignments, Exchange Administrator and SharePoint Administrator for workload-specific tasks, Security Reader for oversight). Minimize Global Administrator usage to two break-glass accounts. Use Administrative Units to scope helpdesk permissions to specific departments or locations so one person cannot act tenant-wide.
• Use Privileged Identity Management (PIM) for just-in-time access and independent approvals. Make admins “Eligible” for roles rather than “Active.” Require approval by a different individual for role activation, enforce MFA on activation, set short activation durations, and require a ticket/justification. Configure PIM alerts for permanent assignments, too many privileged roles, and unused eligible roles.
• Separate provisioning from reviewing with Access Reviews. Have one person provision users and assign security groups; schedule Access Reviews run by a different reviewer (manager, data owner, or security lead) for privileged roles, security groups used for app access, and Teams/SharePoint membership. Configure recurring monthly reviews for privileged roles and quarterly for business groups; require attestations and auto-remove access not recertified.
• Enforce safeguards around privileged operations using Conditional Access and Identity Protection. Create policies that require MFA and compliant, Intune-managed devices for admin role activations. Restrict privileged role activations to trusted locations and block from high-risk sign-in conditions. Use Identity Protection policies to require password reset on medium/high user risk and to block risky sign-ins for privileged users until investigated.
• Implement Intune RBAC and device compliance separation. Assign Intune roles such as Policy and Profile Manager (creates compliance policies) and Help Desk Operator (performs device actions) to different people. Use separate admin device profiles and compliance policies for administrators, and require compliant admin devices for access to admin portals via Conditional Access.
• Monitor with Audit Logs and build review routines. Regularly review Entra ID Audit Logs and Sign-in Logs for role assignments, PIM activations, MFA resets, Conditional Access changes, and group membership changes. Configure saved log queries and weekly reports for independent oversight; ensure at least one read-only role (e.g., Security Reader) outside the admin team reviews these logs.

Example in a Small or Medium Business

A 150-employee manufacturing firm documents that account creation, privilege assignment, and access review must be performed by different people. Alex is assigned the User Administrator role to create and disable accounts; he cannot assign privileged roles. Priya holds the Privileged Role Administrator role but is only “Eligible” in PIM and must obtain approval from Maria (Security Lead) for any activation, which lasts four hours. Dan is the Exchange Administrator and Sarah is the SharePoint Administrator; Conditional Access requires both to use compliant, Intune-managed admin laptops with MFA, and Identity Protection blocks their activations during risky sign-ins. Monthly Access Reviews are scheduled: Maria reviews all privileged role assignments, while department managers review Teams and SharePoint memberships. The Security Reader role is assigned to the COO, who receives a weekly report of Entra ID Audit Logs showing PIM activations, role changes, and MFA resets. A service account’s permissions for an integration app can only be increased by Priya through PIM, with Maria’s approval, and Alex cannot approve his own requests. This setup ensures no single individual can create an account, grant it elevated access, and conceal the change.

Summary

By defining an SoD policy and embedding it into onboarding, change management, and access reviews—and by operationalizing it with Entra ID roles, PIM approvals, Access Reviews, Conditional Access, Identity Protection, Intune RBAC, and Audit Logs—SMBs can ensure that critical tasks are split across different individuals with only the privileges they need. Just-in-time access, MFA and device-based controls, and independent, scheduled reviews reduce the risk of malevolent activity without collusion and provide clear evidence that AC.L2-3.1.4 is met.