CMMC 3.1 Access Control

Write down who and what may connect

For each user, process and device, record its identifier, why it needs access, what it may access and who approved it. State when that access must be removed. Compare the list with Entra users and guests, application consent records, Windows services and your device inventory. Store it in an approved location that only authorized people can open.

Check where access is granted

Check permissions in each service or application, including access inherited through groups. For AVD, compare application-group assignments with the right to sign in to the host. To confirm authorization, look for an approved assignment and the permissions it grants. Registering a device, assigning a license or displaying a desktop tile does not establish that approval.

Apply the restrictions and test them

On a small test group, apply the supported application assignments, host permissions and device restrictions from your approved list. Review application permissions separately from policies for users. Remove a test assignment, handle existing sessions and tokens as the service requires, then try a new connection.

Describe the allowed work

For each application, make a table showing what each role may do, such as read, create, change, approve, export or administer. Have the person responsible for that application approve it. Include application identities and any exceptions.

Set permissions where the work happens

In SharePoint, check site and library permissions, direct shares and access inherited through groups. In Azure, open the resource's Access control (IAM) view. Check the assigned role and its scope, meaning the resources it covers. Set permissions within business applications too; a directory role does not define what a user may do inside them.

Try the functions themselves

Sign in as the test user and use harmless records to try both allowed and prohibited actions. Test direct links and APIs if people use them. Check that the application rejects the prohibited action even when someone reaches it without using the usual menu or RemoteApp.

Write down the approved transfer routes

For each route, record where the information starts and ends, what kind it is, how it moves, who owns the route and who approved it. Include email, sharing through Teams and SharePoint, browser uploads and synchronization. Also check printing, clipboard copying, drives, USB, backups and transfers made by administrators.

Restrict each transfer route

Check SharePoint sharing settings for the organization and each site, including links that already exist. In AVD, check host-pool RDP properties and the policies applied to the host for clipboard, drive, printer and other redirection. Separately review applications running in the session and connections leaving the network.

Try allowed and blocked transfers

Label harmless files Sample data. Try an approved transfer and an attempt to send a file to a prohibited destination. Test clipboard copying in both directions. Record the client, host policy and service or application used. Check routes such as personal webmail even when drive redirection is blocked.

Name the duties that must stay separate

Review who grants access, makes privileged changes, approves releases and reviews evidence. Decide which duties would give one person too much control if combined. Assign each duty to a named person or a role with a named person responsible for it.

Separate the permissions

Check Entra role assignments, the resources covered by Azure IAM roles, application approver groups and who can change those groups. Remove permissions that let a requester bypass the independent approver or change how approval works.

Check who can approve the request

Use a harmless access request and a reversible test change. Ask the requester to try approving their own action. Include attempts through another account or through ownership of an approver group. Record the independent approval and any conflict you could not resolve.

List the work that needs extra permissions

Include administration of directories, subscriptions, hosts and applications, along with backup and security management. Record the people and service principals that do this work, and who can grant them these permissions.

Replace broad permissions carefully

Open Entra ID > Roles & admins to review assignments and find a role whose documented permissions fit the task. In Azure IAM, check assignments on individual resources, resource groups and the subscription. Separately review the Windows Administrators group and any delegated permissions.

Check all the permissions the account receives

Include permissions inherited through groups, group ownership and application permissions. Try a narrower role with a test account. Confirm that the required task works and an unrelated action is blocked. If you use PIM, test role activation and expiry, and check for permissions that remain available without activation.

Separate everyday work from administration

List the work administrators do that does not need security privileges and where they do it. Provide an ordinary account or a role without privileged permissions for that work. Document how they switch to approved administrative access.

Find permissions the daily account should not have

Check local administrator membership, cloud roles, group permissions and application permissions. Look for shared credentials, saved browser sessions or remote tools that could reopen an administrator session while someone is using the daily account.

Check which account does the work

Perform routine work with the ordinary account, then switch to the approved administrator account or role for a harmless maintenance task. Check the account and role identifiers in the activity records. Use the ordinary account for general browsing.

Connect each privileged action to its permission and log

List actions such as changing permissions, configuring security and managing accounts. For each action, identify the permission that restricts it and the event or audit log that records it.

Configure the logs you need

Check the Windows advanced audit policy applied where the action occurs, including sensitive privilege use when relevant. For cloud actions, review Entra, Azure Activity and the service's audit records. Confirm that records are collected, only authorized people can access them and they are kept for the required period. Check each action against its own log source.

Generate safe test actions

Make an approved, reversible change to a test system or record. Confirm that an ordinary account is blocked and that an authorized change is logged with who acted, what they did, what they changed and when. Check other audit sources for functions outside the defined set covered by sensitive privilege-use auditing.

Define the approved limit

For each way of signing in, record how many failures the organization allows, how the system counts and resets them, and whether it locks the account or delays another attempt. Document how access is restored. Check which services depend on those accounts and how a lockout could affect legitimate users.

Configure the system that checks the password

For domain or local accounts, review Account Policies > Account Lockout Policy and any fine-grained domain policy that applies. For Entra authentication, review smart lockout. Microsoft documents different defaults for its clouds. Customizing Entra smart lockout requires P1 or higher.

Test with a dedicated account

Use a dedicated test account and agree how many failed attempts to try before starting. Do not test against administrator, emergency or service accounts. Check which system processed the failures, whether it enforced the limit and whether the documented recovery process works.

Get the notice approved

Ask the person responsible for contract, privacy or legal requirements to identify the CUI rules that apply and approve the notice wording. Record where it must appear and which systems or information it covers. A sample legal warning still needs that review before you use it.

Set up the Windows and application notices

For Windows interactive sign-in, set the approved title and text under Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options. Check whether portals, applications and remote sign-in routes need separate notices.

Check what users actually see

Start a new test sign-in at the console and through each remote route. Check that SSO or launching an application does not skip a required notice. Confirm the wording and where it appears, including any notice shown through tenant branding.

Decide when to lock and what the locked screen shows

Approve how long each device or session may be inactive before it locks. Choose a display that hides the previous content. Check lock-screen notifications, previews and other settings that could reveal sensitive information while locked.

Set the lock policies

Review Windows Interactive logon: Machine inactivity limit. If you use screen saver policies, enable a valid screen saver that conceals the previous content, set its timeout and require a password to resume. These settings are under User Configuration > Administrative Templates > Control Panel > Personalization.

Test both sides of a remote desktop

Open a test document and leave the test session inactive. Watch for the lock, check that the previous content is hidden and confirm that resuming requires authentication. Test both the physical device and the AVD session with the clients and connection routes people use.

Decide when each session should end

List console sessions, sessions through RDS or AVD, and application sessions. Approve the conditions that must end each one. Review the effects on unsaved work, tasks still running and profile cleanup before approving those conditions.

Configure automatic sign-out

For RDS or AVD hosts where these policies apply, open Session Time Limits under Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host. Set the approved active or idle limit. Where the session must end, also configure End session when time limits are reached. Check limits for disconnected sessions separately.

Check that the session ended

Use a test session with only disposable, unsaved test work. Trigger the approved condition and check the host's session records. Try reconnecting: the old session and its processes must have ended. For console and application sessions outside RDS policy, choose and test a separate supported way to end them.

List and approve each remote connection method

For each method, record who maintains it, which users and devices may connect, why they need it, where they connect and what restrictions apply. Record the approval. Look for direct RDP, management agents and vendor support tools that could bypass the intended route.

Set access rules and collect the right logs

For AVD, check assignments, authentication, host sign-in permissions and host-pool diagnostic settings. Collect the diagnostic categories your monitoring plan needs, adding host and application activity where required. For each other remote tool, check the settings that restrict access and produce its logs.

Check that someone can monitor and end a session

Connect with an approved test identity. Ask the reviewer to find the session and its records, then try the approved process for disconnecting or ending it. Add other logs where needed for attempts that never reach AVD or actions inside the Windows session.

Map the remote connection

Record the client, service or gateway, session host and any separate management connection. Include fallback ways of connecting. For each part, identify the component that protects it, the supported protocol and the certificates and trust settings it needs.

Review the settings in use

Use Microsoft's AVD transport documentation to review the service connection. Separately check VPN, RDP and administration settings your organization manages. Check supported client versions and investigate certificate or trust errors. Keep certificate validation enabled while resolving them.

Check how the test connection travels

Use approved connection diagnostics to identify the transport actually used. Investigate unexpected fallback connections or certificate warnings. Where the separate CUI cryptography requirement applies, also keep records of the cryptographic module and its validated operating mode. This page does not validate a product configuration.

Approve where remote connections enter

Document each remote access service, who maintains it, where authentication is checked and which network route is allowed. Include administration and support connections. State which parts the provider manages and which your organization manages.

Check routing and other ways in

Review network rules, services listening for connections on the host, VPN and support tools, and AVD transport. Standard AVD reverse connect and RDP Shortpath use different routes. Check which direct or relayed UDP options are enabled and whether they fit your approved design for managed entry points.

Verify the real connection

Observe a test connection and check the network rules it uses. If you find an unapproved bypass, close it through an approved change while preserving documented AVD service connections. Retest the approved connection and the bypass.

Decide which remote admin work is allowed

Record which administrators may run each command or function, which systems they may act on and which security records they may read. List where they may connect from, who approves access and when it ends. Include scripts, Azure administration, security consoles and remote support.

Restrict the approved route

Assign Azure roles, application roles and host permissions that fit the approved task. For suitable Windows PowerShell work, consider a Just Enough Administration (JEA) endpoint that allows only the required capabilities and commands. Review its configuration carefully and control other remote tools separately.

Check the limits and identify the operator

Use the approved route to run a harmless command and read a test security record. With a test account, try an unapproved command, system or record. Check that the audit records identify the person who performed the work.

Write down the wireless access you approve

List the wireless networks and device radio connections included in your review. For each network, record who maintains it, which people and devices may connect, why they need access and which network segments they may reach. State any prohibited uses. For a local AVD client, decide whether it belongs in scope based on what it handles and the role it plays.

Enforce approval at the network

Configure the access point or controller and network authentication to allow only approved connections. If you use Network Policy Server (NPS), check network-policy conditions, group membership and the order in which policies apply. Use your management tools to deploy only approved Windows Wi-Fi profiles.

Remove access that is no longer approved

Review retired devices, former users, unused profiles and guest networks. Check that a guest or unmanaged device cannot reach the CUI network just by knowing a shared password. Record any wireless use you still cannot control.

Choose how the wireless connection is protected

Record the approved authentication method and encryption settings for the network in scope. Check that the access point, client and authentication server all support them. A hidden network name or a list of allowed MAC addresses does not provide cryptographic protection.

Set certificate trust and Wi-Fi profiles

For an enterprise design that uses certificates, check the requirements for client and server certificates. Confirm trusted issuers, permitted certificate uses, names, renewal and removal. Configure clients to validate the server and set the controller or NPS policy. Keep validation enabled while fixing certificate errors.

Check the protection used by a connection

Connect the test device and use authorized network diagnostics to confirm the authentication and encryption actually selected. Check what happens when a certificate expires or is revoked. Look for other saved profiles that could connect to an unapproved network as a fallback.

Decide what mobile devices may access

List the device types, who owns them and why they need access. Record the services, applications and data each may reach. State whether CUI may be downloaded or only viewed through an approved connection. Identify the local client, remote host and service used for that connection.

Apply access conditions

If you use Intune compliance and Conditional Access, set up the device compliance policy first. Check that a test device meets it, then apply the access policy to the intended users and resources. Review supported clients and any exclusions. Test access at the service itself; Intune enrollment restrictions do not enforce that access decision.

Monitor and log connections

Name the reviewer, decide how often they will check connection logs and write down what they should do about unexpected access. For services that authenticate through Entra, open Entra ID > Monitoring & health > Sign-in logs with the appropriate reader rights. Look for who connected, the device or client used, what they accessed, when and whether access succeeded. Some records may lack device details. Add network, AVD or application logs for connections the tenant record does not cover. Check that records arrive, only authorized people can read them and they are kept for the period you need. Use connection logs as well as enrollment or compliance reports.

Test connection and removal

At the service people use, try a connection from a device in an approved state and one that does not meet the rules. Use a test device record and test data to try the documented process for removing access or responding to a lost device. Record how existing tokens or sessions affect removal and any delay before access stops.

Find local copies and plan recovery

List mobile devices that hold CUI in files, synchronized copies, application data or permitted exports. Record the approved encryption settings, where recovery keys must be stored and who may recover a device.

Set up supported encryption

For supported Windows devices, review BitLocker policy in GPO, the applicable MDM tools or an approved local management process. Where required, choose the approved method before encryption starts. Verify that the recovery key is backed up. Use instructions specific to each other mobile operating system for its encryption and management.

Check encryption and recovery

Inspect encryption and protection status on the volumes themselves, including whether protection is suspended. Use authorized access to confirm the recovery record exists. Test recovery only on a dedicated test device after protecting its data. Keep production protection active during this demonstration.

List external connections and what they are used for

Include partner tenants, personal devices, external applications, support systems and services that process or store information elsewhere. Record who is responsible for each system, why it is used, what information it handles, how it connects and what use is allowed. Include browser and API access.

Check the conditions before approval

Review the agreements, responsibilities and security conditions needed for that system and information. Check the records that support those conditions before approving access. Technical trust and vendor certifications may support the review, but do not complete it on their own.

Apply and test limits

Check SharePoint sharing at the organization and site levels, including existing guests and links. Review enterprise application consent, permissions on the services and data, and device access rules that apply. Restrict both whether the external system can connect and what it can do. Include external applications opened inside AVD.

Approve or prohibit external use

List the organization's USB drives and other portable storage, who is responsible for them, what information they may hold and which external systems may use them. State the conditions for approval. If this use is prohibited, document the restriction and how people must follow it.

Set restrictions on devices you manage

On managed Windows devices, review Computer Configuration > Administrative Templates > System > Removable Storage Access, along with encryption and management settings that apply. Check which storage classes are covered, which policy takes precedence and how the restrictions affect work. An all-class deny policy, if selected, overrides settings for individual classes.

Control how drives leave your environment

Record who receives and returns each drive, allow only authorized people to hold it and restrict what they may take out of the environment. Apply the technical protection your design calls for. Check AVD drive and USB redirection separately. Plan for use on unmanaged external computers, where your local device settings cannot enforce the rules.

List public systems and publishers

List public websites, repositories, storage, customer portals and publishing tools. Name the people or processes allowed to publish, who approves content and who reviews and removes prohibited information.

Review content before release

Document how reviewers identify CUI and keep it out of public posting or processing before release. Restrict publishing accounts and deployment permissions. Where used, check SharePoint anonymous links and Azure Blob anonymous-access settings. Include the ways applications publish content too.

Review public content and test removal

Name the person who reviews public content, set a schedule and document how they remove content and report a problem. Use harmless content to test approval, anonymous access and removal. If actual CUI is found, follow incident and contract reporting procedures as well as removing it; people may already have accessed a copy.