Access Control is the largest family in NIST 800-171  and one of the most operationally important. Its 22 requirements govern who can access the environment, what they are allowed to do, how remote and mobile access is controlled, how sessions are managed, and how Controlled Unclassified Information is restricted as it moves through the system.

It is also the family where many first-time CMMC implementations begin to show strain. That is not because the requirements are obscure. It is because they cut across nearly every layer of the environment at once. Identity, device management, external sharing, remote access, administrative role assignment, session handling, portable storage, and wireless controls all converge in this family.

A team can have strong multifactor authentication, solid endpoint management, and a well-maintained tenant overall and still collect multiple findings in the Access Control family if those controls are not connected into a coherent access model across identity, device, and data layers.

In Microsoft 365 GCC High, Access Control is implemented through a combination of Microsoft Entra Conditional Access, Entra role-based access control, Microsoft Intune device management, Microsoft Purview protections, and collaboration platform restrictions across SharePoint, OneDrive, and Exchange Online.

Microsoft provides the infrastructure foundation, but this family is not platform-provided. It is configuration-heavy, and C3PAO assessors tend to examine these controls closely to determine whether the access model described in the SSP actually exists in the live tenant.

This article is Part 1 of the NIST 800-171 GCC High Configuration Guide. It walks through all 22 Access Control controls, explaining what the requirement means, how it maps to GCC High configuration, and what evidence assessors typically expect to see.

AC Family Overview

Most of the implementation work in this family happens across a familiar set of Microsoft technologies.

Microsoft Entra Conditional Access determines who can access cloud resources and under what conditions. Entra role-based access control and Privileged Identity Management determine who can perform administrative functions. Microsoft Intune enforces device posture and endpoint security controls, while Microsoft Purview helps manage how CUI is classified and protected as it moves through the environment.

SharePoint and OneDrive sharing settings govern collaboration boundaries, and Exchange mail flow rules can enforce restrictions on sensitive information leaving the environment.

Because these controls are distributed across multiple Microsoft services, the Access Control family often reveals inconsistencies in how organizations manage access. Identity protections may be strong, but device requirements might be incomplete. Remote access policies may exist, but external sharing might remain overly permissive. Assessors frequently identify findings where these pieces do not align.

How Access Control applies to your CMMC scope

Access Control requirements apply to every identity, device, and system that can interact with Controlled Unclassified Information within your assessment boundary. In practice, this means the scope of the AC family is broader than many organizations initially expect.

User identities, administrative accounts, managed endpoints, mobile devices, remote access paths, and external collaboration relationships can all fall within scope depending on how they interact with CUI.

For example, even if only a subset of employees handle CUI, administrative identities with tenant-level privileges are still considered in scope because they can affect the security posture of systems that store or process CUI. Likewise, mobile devices that access Microsoft 365 resources containing CUI must comply with mobile device controls, encryption requirements, and access restrictions.

The following table summarizes common assets and access paths and how they typically relate to Access Control scope in a GCC High environment.

Controls that shape the access model

Although the Access Control family includes twenty-two controls, a small subset establishes the foundation for the rest of the family.

3.1.1 Limit system access to authorized users

This control establishes the baseline for the entire environment. Access to systems handling CUI must be restricted to authorized users, authorized devices, and authorized processes.

In GCC High environments, organizations typically enforce this requirement through a combination of Entra user governance, Conditional Access device requirements, and review of enterprise application permissions.

Administrative teams should periodically review all enabled accounts, identify inactive accounts, and disable or remove accounts that no longer have a business purpose. Conditional Access policies should require compliant devices for access to Microsoft 365 resources, ensuring unmanaged endpoints cannot access sensitive data.

Organizations should also regularly review enterprise applications and consented integrations to ensure that unauthorized third-party applications do not introduce unintended access paths.

Assessors typically look for clear evidence that all enabled accounts are actively managed and that device compliance requirements are enforced.

3.1.2 Limit access to authorized functions

This control requires organizations to restrict users to the specific system functions necessary for their roles.

In Microsoft 365, this is primarily implemented through Entra role-based access control and group-based access assignments. Administrative roles such as Global Administrator, Exchange Administrator, and Security Administrator should be assigned only where required, and permissions should be granted through security groups wherever possible.

Organizations with Entra ID P2 licensing should use Privileged Identity Management to enforce just-in-time access to privileged roles. Instead of permanently assigning administrative privileges, users activate roles only when required and for a limited duration.

Assessors typically examine administrative role assignments, PIM configuration, and group membership to determine whether the tenant follows least-function access principles.

3.1.3 Control the flow of CUI

This control focuses on restricting how CUI moves within and outside the system.

In Microsoft 365 GCC High, CUI flow control is typically implemented through Microsoft Purview Data Loss Prevention policies, sensitivity labels, and Exchange transport rules.

Organizations commonly create sensitivity labels for different categories of CUI and apply encryption and access restrictions through those labels. DLP policies monitor communication channels such as Exchange email, SharePoint sites, OneDrive, and Teams to detect or block sensitive information leaving authorized locations.

Exchange transport rules can also prevent emails containing labeled CUI from being sent to unauthorized external domains.

The most effective implementations pair these technical controls with a documented diagram showing approved CUI data flows, allowing assessors to see that tenant configuration matches the organization’s policy.

3.1.5 Employ least privilege

Least privilege is one of the most visible maturity signals in the Access Control family.

In practice, this means minimizing the number of Global Administrators, restricting administrative roles to only the users who require them, and using Privileged Identity Management to enforce just-in-time elevation.

Eligible role assignments should replace permanent role assignments wherever possible. Administrative access should require justification, limited activation durations, and approval workflows for highly privileged roles.

Assessors frequently evaluate the number of Global Administrators and the use of PIM when determining whether least privilege is truly enforced.

3.1.6 Use non-privileged accounts for nonsecurity functions

Administrators should not use privileged accounts for routine activities such as reading email or editing documents.

Organizations typically implement a dual-account model in which administrators maintain a standard user account for daily work and a separate administrative account for privileged operations.

Administrative accounts should not have standard productivity licenses such as Exchange mailboxes or Teams access. Conditional Access policies should also restrict administrative accounts to secure devices and require phishing-resistant MFA.

Assessors commonly validate this control by reviewing account naming conventions, licensing assignments, and Conditional Access restrictions applied to administrative identities.

Control-by-control implementation

The following sections walk through the remaining Access Control controls and their implementation in GCC High.

3.1.8 Limit unsuccessful login attempts

Organizations must restrict the number of failed authentication attempts before accounts are locked.

In Microsoft Entra ID, this is implemented using Smart Lockout.

Navigate to:

https://entra.microsoft.us
Identity → Protection → Authentication methods → Password protection

Smart Lockout automatically detects malicious login attempts and blocks repeated password guessing attacks.

Azure Government tenants use a lower default lockout threshold than commercial tenants. Organizations should define their specific lockout threshold and duration in their System Security Plan and ensure the tenant configuration matches the documented policy.

Assessors typically verify the Smart Lockout configuration and confirm that the values align with the organization’s documented authentication policy.

3.1.9 Provide privacy and security notices

Organizations must display system use notifications informing users that activity may be monitored and that the system processes sensitive information.

In GCC High environments, this is typically implemented through Entra sign-in branding and Windows logon banners.

The Entra sign-in experience can display a notification message before authentication occurs, while Intune configuration profiles can enforce login banners on Windows endpoints.

Assessors typically validate this control by observing login prompts directly and verifying that the notification text appears consistently across authentication points.

3.1.10 Session lock

Systems must automatically lock after a defined period of inactivity to prevent unauthorized viewing of sensitive information.

In Microsoft environments, this control is primarily enforced through endpoint configuration using Microsoft Intune.

Device configuration profiles can define screen lock timing, inactivity thresholds, and password requirements for unlocking devices. Mobile devices should also enforce inactivity timeouts before requiring re-authentication.

Assessors typically verify these policies through Intune configuration reports and endpoint testing.

3.1.11 Session termination

User sessions must terminate automatically when defined conditions occur.

In Microsoft 365 environments, session expiration is typically enforced through Conditional Access session controls and sign-in frequency policies.

Organizations commonly configure sign-in frequency limits to force periodic re-authentication. Persistent browser sessions are typically disabled to ensure authentication tokens are not reused indefinitely.

Microsoft Entra also supports Continuous Access Evaluation, which can revoke active sessions when security events occur, such as account disablement or credential changes. However, CAE does not replace standard session timeout policies. Assessors still expect organizations to define session expiration thresholds and enforce them through Conditional Access and endpoint policies.

3.1.12 Monitor and control remote access

Remote access must be authorized, monitored, and restricted to approved access methods.

Most organizations enforce this requirement through Conditional Access policies requiring MFA, compliant devices, and approved applications for users accessing Microsoft 365 from outside trusted network locations.

Remote access logs are available through Entra sign-in logs and can be integrated into Microsoft Sentinel or other monitoring platforms to detect anomalous login patterns.

Assessors typically review Conditional Access configuration, remote sign-in logs, and documentation describing authorized remote access methods.

3.1.18 Control connection of mobile devices

Mobile devices must be authorized and managed before accessing organizational resources.

In Microsoft environments, this is implemented using Intune enrollment restrictions, compliance policies, and Conditional Access policies for mobile platforms.

Conditional Access policies for mobile devices typically require both device compliance and application protection policies to ensure corporate data is accessed only through managed applications.

Organizations designing new mobile Conditional Access policies should use 'Require app protection policy' rather than relying solely on older “approved client app” controls. App protection policies integrate with Intune mobile application management to prevent organizational data from being copied into unmanaged applications.

Assessors generally verify this control by reviewing Intune compliance policies, Conditional Access configuration, and reports of enrolled mobile devices.

3.1.19 Encrypt CUI on mobile devices

Mobile devices accessing CUI must enforce device encryption.

Modern mobile operating systems enforce encryption by default when a device passcode is configured, and Intune compliance policies can require encryption to remain enabled.

Organizations typically combine device encryption with Intune app protection policies to ensure corporate data remains encrypted even when stored within mobile applications.

Assessors commonly verify encryption status through Intune compliance reports.

3.1.20 Control external system connections

Connections to external systems must be verified and restricted.

In Microsoft 365 environments, this often involves restricting SharePoint and OneDrive external sharing, limiting guest invitations, and defining approved partner domains.

Organizations frequently restrict guest invitations to administrators and configure domain allowlists for approved collaboration partners.

Assessors typically review external collaboration settings and verify that partner relationships are formally documented.

3.1.21 Limit use of portable storage devices

Organizations must restrict or control the use of removable media such as USB drives.

This control is commonly implemented through Microsoft Intune device configuration policies and Microsoft Defender for Endpoint device control features.

Many organizations block removable storage entirely for systems handling CUI. Others permit limited use with monitoring and encryption requirements.

Assessors typically review Intune policies and endpoint security configurations to confirm enforcement.

Evidence collection for Access Control

During a CMMC Level 2 assessment, assessors do not only evaluate policies or configuration screenshots. They look for evidence demonstrating that access controls are actively enforced across the environment.

Evidence typically includes configuration exports, policy definitions, identity governance reports, and monitoring records that show how access is controlled over time.

Because Access Control spans identity, device, collaboration, and endpoint security systems, evidence often comes from multiple Microsoft services including Entra ID, Intune, Microsoft Purview, SharePoint, Exchange Online, and endpoint security platforms.

The table below summarizes the types of artifacts assessors typically request when evaluating Access Control requirements.

Common Access Control assessment findings

Access Control findings usually result from inconsistent implementation across the environment rather than a single missing control.

Assessors frequently observe excessive numbers of Global Administrators, incomplete separation between administrative and daily accounts, and dormant accounts that were never disabled after personnel changes.

External sharing settings are another common source of findings. SharePoint and OneDrive environments sometimes retain permissive defaults even when policies require stricter controls for CUI handling.

Session management also produces findings when organizations rely on user training instead of enforced policies. Screen lock timing, session expiration, and persistent browser sessions must be technically enforced rather than simply documented.

Portable storage and mobile device controls can create similar issues when devices are allowed to connect without clear compliance requirements or encryption enforcement.

In most cases, Access Control findings occur because identity controls, device policies, and collaboration restrictions were implemented independently instead of as part of a unified access architecture.

Getting started

The Access Control family is where organizations begin demonstrating whether access decisions are truly intentional.

Turning on MFA and creating a few Conditional Access policies is only the starting point. A mature implementation requires coordinated control across identity governance, device management, session handling, collaboration restrictions, and external system connections.

Secureframe Defense connects directly to your GCC High environment and continuously monitors the configurations that support Access Control requirements, including role assignments, Conditional Access posture, device compliance, external sharing restrictions, and session management settings.

When a C3PAO asks for evidence of controls like AC.L2-3.1.1 authorized access, AC.L2-3.1.6 non-privileged account use, or AC.L2-3.1.20 external system connections, the goal is not to begin exporting reports from multiple admin portals. The goal is to already have that evidence collected and ready for review.

See how Secureframe Defense automates CMMC evidence collection by scheduling a demo today.