Microsoft setup guide: AC.L1-3.1.1

3.1.1: Decide which users, processes and devices can connect

Write down who and what may use the system. Check Microsoft 365 and AVD permissions against that list, then test whether access works as approved.

Sources reviewed October 22, 2026. These instructions have not been tested in a Microsoft tenant.

Choose the instructions for your cloud. If you use AVD, also read the notes for AD DS-only, hybrid joined or Entra joined hosts, according to how your hosts are joined.

NIST SP 800-171 Revision 2

The requirement and official objectives

Limit system access to authorized users, processes acting on behalf of authorized users, and devices (including other systems).
Official assessment objectives from NIST SP 800-171A, June 2018. Determine if:
ObjectiveOfficial text
3.1.1[a]authorized users are identified.
3.1.1[b]processes acting on behalf of authorized users are identified.
3.1.1[c]devices (and other systems) authorized to connect to the system are identified.
3.1.1[d]system access is limited to authorized users.
3.1.1[e]system access is limited to processes acting on behalf of authorized users.
3.1.1[f]system access is limited to authorized devices (including other systems).

The steps below explain how to configure and check settings related to this requirement. The table above contains the official objective text. Following these steps does not establish a MET finding. Read the official assessment procedures.

Before you start

  • Name the system owner who approves access. List the tenants, applications, devices, servers, host pools and providers covered by the review. Include guests, administrators, service accounts and identities used by applications.
  • Make an access list and restrict who can read it. For each person, process or device, record its ID, why it needs access, what it may use, its permissions, who approved it, who is responsible for it and when access should end. An existing Office tool is enough to keep this list.
  • Use an account with permission to read the inventory. Make changes through an administrator with the required delegated rights. To review application permissions, use an Application Administrator or Cloud Application Administrator. To assign Azure roles, use an account allowed to assign roles at the resource level you intend to change.
  • Choose a resource to test and two test users: one with approved access and one without it. Save the current permissions and name a recovery contact before removing access.

If you need to identify CUI first, start with the identification guide. Before putting CUI in a cloud service, check that the service, your contract and the handling rules permit it.

Put the requirement into practice

Start with people, then check the processes and devices that use the system too. Decide which may connect and configure the settings that enforce that decision. Microsoft runs the cloud service, but your team or provider still approves access, assigns permissions, configures hosts and keeps the review records.

A device can appear in the directory without being approved to use this system. The same is true of a person with a license or a successful sign-in. Compare each one with the approved access list.

  1. Compare users and permissions with the access list

    In the Entra tenant you are reviewing, compare Users and Groups with the approved access list. Check guests, permissions assigned directly to users, group owners and administrator roles. Then open each site, application or other resource and check its permissions. Before changing a synchronized account, find out which directory supplies it.

  2. Find the processes that act for users

    Open Entra ID > Enterprise apps > All applications > the application > Permissions. Check Admin consent and User consent separately. Record the application ID, who is responsible for it, why it runs, its delegated or application permissions, the resources it can reach and who approved them. Also review scheduled tasks and Windows services that run outside Entra. They will not all appear in the tenant application list.

  3. Require an application assignment where supported

    If the application supports access through user or group assignments, open its Properties and Users and groups. If that restriction fits your design, test Assignment required with the approved users or group and the required admin consent. Check support for each Microsoft service you use. This setting does not replace a review of permissions an application uses without a signed-in user.

  4. Decide which devices may connect

    Compare each device ID, responsible person, join state and management record with the approved device list. If you use Conditional Access to require compliant devices, configure the compliance policy first and prepare a test device that meets it. Apply the access policy to the intended users and resources. Evaluate its effect, then turn it on and test it. A policy aimed at users does not cover calls made by service principals.

  5. Check who is assigned to the AVD resource

    In the correct Azure portal, open Azure Virtual Desktop > Application groups > the test application group > Assignments. Compare every assignment with the approved access list. Then use the instructions below for your host join type to check Windows access. Check both whether the desktop is published to the user and whether Windows lets that user sign in.

Commercial: Microsoft 365 and Azure

Use your Microsoft 365 Commercial tenant and portal.azure.com for Azure Commercial resources. Record the tenant and subscription IDs before making changes. Before placing CUI in a commercial service, check whether that service and your contract permit it. These access settings do not answer that question.

  1. Check access on the resource itself

    Open the test SharePoint site or enterprise application. Compare the approved group with who can actually use it, including guests, direct shares and application permissions. For AVD, check the application-group assignment in the commercial subscription, then follow the instructions for your host join type.

  2. Test the device restriction where users connect

    Test the resource with a permitted client, using an approved device and a test device that is deliberately left unapproved. Check the access result and sign-in records. In AVD, the local client device and the session host are different devices. Apply the requirement to the intended sign-in phase and verify it there. Applying it to the wrong phase can block approved users or leave the intended restriction untested.

Government: GCC High and Azure Government

These instructions use GCC High and Azure Government. Confirm that you are in the government tenant, and use portal.azure.us for the Azure resource. Keep the access list and evidence in approved locations. An account with the same name in another cloud is a different identity.

GCC and GCC High use different arrangements. GCC identity pairs with Azure Commercial, while GCC High identity pairs with Azure Government. If you use GCC, check its service description and support for each feature. Neither set of instructions here applies to every GCC setup.

  1. Check the government service you use

    Before assigning access, read the service description and check which sign-in and collaboration options it supports. Compare users, application permissions and service permissions in the government tenant with the approved access list. Add a commercial guest or a connection between clouds only after confirming that it is approved and supported for this deployment.

  2. Check the government AVD assignment

    In the government subscription, review the test application group and the users assigned to it. Follow the instructions below for your host join type, using features supported in that deployment. If a needed control is unavailable, record which access restriction you cannot enforce and propose another option for the system owner to review. A screenshot from a commercial tenant cannot show that the government restriction works.

Check how your session hosts are joined

Check which account the user signs in with, how the host is joined and which local device and client they use. Then choose the matching instructions below. Confirm that your cloud supports the features you plan to use.

AD DS-only session hosts

For AD DS-only session hosts, record the domain, the organizational unit (OU) containing the hosts and the approved domain users and groups. Identify the synchronized Entra users who connect to the AVD service. Check that the hosts can reach the domain and DNS, and that the user identities match as AVD requires.

  1. Check who Windows allows to sign in

    On the test host, check local group membership and the policies that allow or deny remote logon. Apply changes to the session-host OU, then check which policies took effect on that host. Before adding a broad deny rule, review the affected groups and the recovery plan. Preserve access needed by required services.

  2. Check Windows sign-in separately

    AD DS-only hosts do not support this Entra SSO path. Test the Windows domain logon separately from the Entra sign-in to the AVD service. Use the hybrid section only if the host itself is also Entra hybrid joined.

Microsoft Entra hybrid joined session hosts

A hybrid joined host still depends on AD DS and also has an Entra device identity. Check the host itself. Synchronizing a user account does not make the host hybrid joined.

  1. Check the host in AD DS and Entra

    Find the same test host in AD DS and Entra. Review its application-group assignments, domain permissions and the policies that took effect on it. Test with the account that should use the desktop, with only the permissions it is approved to have.

  2. Check SSO and its prerequisites

    If you use Entra SSO, check the documented requirements for the operating system, client, domain trust and tenant. Test signing in to the host, then opening a resource inside the session. SSO can sign the user in successfully while an application or file share still requires its own access permission.

Microsoft Entra joined session hosts

For Entra joined hosts, confirm which tenant the host and users belong to, who is assigned to the application group and how the host pool is managed. Check the user account, how the host is joined and how users authenticate to profile storage separately.

  1. Check which VM login roles are needed

    First check whether your host pool uses session host configuration. For pools that do not, Microsoft documents the additional Virtual Machine User Login role for users and Virtual Machine Administrator Login role for administrators who need that privilege. Check where each role is assigned and which permissions are inherited. Pools using session host configuration do not need that additional role assignment.

  2. Check how users sign in

    Check the Entra SSO prerequisites and the settings on the session host. Assign policies through the management method you actually use for those hosts. Joining a VM to Entra does not automatically enroll it in other management products or grant access to applications, storage or CUI.

Fictional example. No tenant test performed.

Four approved users, one unreviewed export application

A fictional supplier approves four engineers to use one AVD workspace. During a review, the team finds that a former guest is still assigned to the application group. An export application also has broad permissions, and nobody is listed as responsible for it.

The team records both problems, checks what relies on the current permissions and plans separate changes to test. The four approved engineers should keep access, and the unapproved test user should be denied. After the application permissions change, the team must check both an approved operation and an operation that should be denied. These are the results the team expects to see. No test results are reported here.

Check the settings with sample data

Create a file or record with made-up contents and label it Sample data. Not CUI. Before testing, agree with the system owner on what should be allowed and what should be denied. The table describes the results to look for. These tests have not been run in a Microsoft tenant.

Repeat the checks that apply to each cloud, host join type and client you use.
What to tryWhat should happen
Have the approved test user open the assigned resource with sample data.The user can open the intended resource and has only the approved permissions.
Have the unapproved test user try to open the same resource.Access is denied. Try the direct resource URL as well as checking whether a tile is visible.
Use the approved application to perform one approved test operation.The operation succeeds with the recorded application identity and permissions.
Use the application to try an operation on a resource or with a permission it is not approved to use.The control denies the operation. Check the operation itself; hiding an application tile does not test permissions used without a signed-in user.
Try the protected connection from both approved and unapproved test devices.The results match the approved device rule. Repeat with each permitted client and check the intended AVD sign-in phase.
Remove a test assignment. Follow the required steps for tokens and sessions, then try to connect again.The removed permission no longer grants access. Record how long the change takes and whether existing sessions remain usable. Do not assume that removing the assignment immediately ends a session.

Write down what happened, when you tested, the type of account, client, host, policy version and where the evidence is kept. A passed test shows the result only for the connection and settings you tested. Keep failed checks and connections you have not tested on the action list.

Records to keep and work to assign

  • Keep the approved lists of users, processes and devices, the access requests and the decisions about who is responsible and when access ends.
  • Save the group, application, service, device-policy and AVD assignments. Include inherited permissions and any exceptions.
  • Keep records showing what the provider is responsible for and which controls it supplies. Identify the service and customer settings each claim depends on.
  • Record what each test showed, the account, application or device IDs, client, host, settings version and date. Reference logs kept in a location with restricted access.

Fictional workbook entry

For 3.1.1[e], choose Evidence to check and enter ACCESS-PILOT-01 as the reference. Assign the work to the IT owner: find who is responsible for the export application, confirm which resources it may use and check its actual permissions. This entry records work still to do. It does not assign a MET finding.

Use the free Level 2 readiness worksheet to record what is missing for each objective, who will address it and what happens next. Keep the evidence itself in an approved location with restricted access. Put a reference to that location in the workbook.

Download the Excel worksheet ↓

When a check fails or access breaks

  1. If an approved user loses access

    Check the tenant, account, group membership, resource assignment, inherited deny rules and host logon rights. Compare them with the saved settings to find what changed. Follow the agreed recovery process to restore only the approved access. Test both the user who should get in and the user who should be denied.

  2. If an application stops working

    Before restoring consent, find which identity and permission the failed operation uses. Have the person responsible review the request, then grant only the approved permissions. If an exception is temporary, record why it is needed, when it ends and how you will test it again.

  3. If an inventory entry looks out of date

    Find who is responsible for the entry and what depends on it before disabling or deleting it. Keep the recovery information and follow the removal process for the directory or management system that supplies it. An old activity timestamp alone does not authorize removing a device.

Costs, licenses and existing tools

  • You can start with an access list, a review by the responsible people and the permissions built into your existing services. You do not need a new assessment tool for that work. Allow for staff time and any provider charges.
  • Assigning groups to enterprise applications needs Entra ID P1 or P2. Conditional Access requires P1, and the features or products used with it may need other licenses. Office 365 E3 and Microsoft 365 E3 are different subscriptions; check the plan you have.
  • To enforce Intune compliance requirements, you need the applicable management license and a deployed compliance policy. If you cannot enforce the device rule, record the gap and review a supported alternative. Keeping a manual device list does not enforce the rule.
  • Check AVD user access rights separately from Azure compute, storage and management costs. Confirm what your government plan includes rather than relying on a commercial plan description.

Check your subscription against the documentation for Conditional Access licensing and AVD access licensing and costs. Confirm what your government plan includes separately; a product name or commercial bundle does not establish those rights.

What else you need to review

This guide covers who and what is authorized under 3.1.1. You still need to implement and review least privilege, account creation and removal, remote access, MFA, restrictions on data transfers and audit requirements.

The official designation is AC.L1-3.1.1 because the requirement starts at Level 1 and also applies at Level 2. Completing these steps does not establish compliance with either level.

Sources and review date

Sources reviewed October 22, 2026. These guides use the Level 2 baseline of NIST SP 800-171 Revision 2 and the June 2018 assessment procedures. Reviewing documentation does not verify the settings in your system.

This series follows the structure of Microsoft's 2024 preview reference guide. It suggests which Microsoft products can help with each requirement. Use those suggestions as a starting point; they do not prove current compliance. The steps here refer to the linked product documentation.

For a correction or general question, email cmmc@purposefulsecurity.com and describe it in general terms. Do not send CUI, contracts, credentials, network diagrams, security evidence or completed worksheets.