CMMC Level 2 Entra Terms of Use Setup Guide

A Terms of Use prompt looks small, yet it closes a gap that auditors notice fast. If users can reach Microsoft 365 resources tied to CUI without accepting the rules, your written policy and your live controls drift apart.

I use Microsoft Entra Terms of Use to put user acknowledgment right in the sign-in path. For CMMC Level 2, that matters, but it does not satisfy the requirement by itself. The setup only holds up when I scope it well, tie it to Conditional Access, and keep evidence.

Why Entra Terms of Use matters in a CMMC Level 2 tenant

Terms of Use gives me a recorded acknowledgment tied to a real identity. That record helps when I need to show that employees, contractors, or admins accepted rules before access. In a CMMC Level 2 environment, that is useful because access control is not only about blocking bad sign-ins. It is also about proving that approved users saw the conditions for using the system.

Microsoft’s own CMMC Level 2 access control guidance points admins toward identity-based controls in Entra. I treat Terms of Use as one part of that larger access story. It supports user acknowledgment, while group scoping, MFA, sign-in controls, and logging do the heavy lifting.

I don’t treat this feature as a magic compliance switch. It will not write your SSP. It will not fix weak group membership. It will not prove device trust or stop risky sessions on its own. What it does well is simple and useful: it places a policy acknowledgment in front of the user, captures acceptance, and gives me something concrete to review later.

That makes it a strong supporting control for Level 2 tenants that live in Microsoft 365. It is even more helpful when contractors, remote workers, or privileged staff touch in-scope SharePoint, Teams, Exchange, or line-of-business apps through Entra.

Terms of Use is evidence of acknowledgment. It is not a substitute for policy, MFA, logging, or technical enforcement.

What I prepare before I open the admin center

I get better results when I spend ten minutes on prep before I click anything. Most failed rollouts come from bad scope, weak document content, or licensing surprises.

This is the short checklist I use first:

Area	What I check	Why it matters
Licensing	I confirm users are covered for Conditional Access and Terms of Use, often through Entra ID P1 included with Microsoft 365 Business Premium or enterprise suites.	The policy will not work as planned if the tenant lacks the right entitlement.
User scope	I identify the exact groups that access in-scope apps or CUI.	Good scope keeps the prompt targeted and avoids user confusion.
Emergency access	I exclude break-glass accounts and document why.	A bad policy should never block recovery access.
Service accounts	I find non-interactive accounts before rollout.	Service accounts cannot click Accept.
Cloud type	I confirm feature behavior in commercial, GCC, or GCC High tenants.	Menu labels and timing can differ across clouds.
Document owner	I decide who owns the legal and policy language.	IT should not publish terms that HR, legal, or compliance has not approved.

I also clean up the document before upload. The best Terms of Use file is short, plain, and strict. I avoid generic acceptable-use filler. For a CMMC-minded tenant, I want language about approved devices, handling of CUI, consent to monitoring, MFA protection, incident reporting, and restrictions on personal storage or forwarding.

If I am working in a tenant that has gone through an acquisition, a rushed pilot, or a messy merger, I pause and fix group sprawl first. Terms of Use works best when the people in scope are already mapped to the right cloud apps and security groups.

Build the Terms of Use object in Microsoft Entra

When I create the policy object itself, I keep the name boring and searchable. “CMMC L2 Terms of Use – Internal Users” is far better than something vague like “user notice.”

Inside the Entra admin center, I usually find it at Identity Governance -> Terms of use. If Microsoft moves the menu again, I use the search bar and go straight to “terms of use.”

1. Open the Microsoft Entra admin center and go to Identity Governance -> Terms of use.
2. Select New terms.
3. Enter a clear Name for admins and a clean Display name for users.
4. Upload the approved document, usually a PDF. If you support more than one language, add those files now.
5. Turn Require users to expand the terms to On. I always enable this in compliance-focused tenants.
6. Turn Require users to consent to On.
7. Set Expire consents based on your review cycle. Annual re-acceptance is common, and a document change may justify a fresh acknowledgment sooner.
8. Save the object, then review what the end-user prompt will look like.

The document itself matters more than the click path. I want the file to state rules such as:

• use only approved devices and approved accounts for in-scope work
• do not move CUI to personal email, personal cloud storage, or unmanaged apps
• accept monitoring, logging, and security review on company systems
• protect MFA methods, passwords, and session tokens
• report lost devices or suspected incidents at once through the company process

Microsoft calls out this pattern on its Level 1 controls page, and the same acknowledgment model still helps at Level 2 when I need stronger evidence around access use.

For screenshots in a runbook, I capture the New terms pane, the uploaded file details, the setting where users must expand the document, and the accepted-users report after testing. Those four visuals save time later.

Apply Conditional Access so acceptance is required

Creating the Terms of Use object does nothing until Conditional Access enforces it. This is the step many teams miss.

In the Entra admin center, I go to Protection -> Conditional Access and create a new policy. If the tenant is sensitive, I start with a pilot group. I do not point it at all users on day one unless I already tested in a lab or a separate pilot tenant.

1. Create a new Conditional Access policy with a clear name, such as CA – Require Terms of Use for CMMC scope.
2. Under Users, include the pilot group or the production groups that need the acknowledgment.
3. Exclude break-glass accounts and any service accounts that sign in without user interaction.
4. Under Target resources, choose the cloud apps that are in scope. For many SMB tenants, that means core Microsoft 365 apps first.
5. Under Grant, select Require terms of use and choose the Terms of Use object you created.
6. In the same grant section, add Require multi-factor authentication if the users should complete both controls at sign-in.
7. Set the grant logic to Require all selected controls.
8. Enable the policy after testing, or use a limited pilot first if the tenant cannot tolerate mistakes.

If I pair Terms of Use with MFA, I always use Require all selected controls. “Require one” weakens the policy.

This is also where I think about app scope. If your CUI lives in SharePoint Online, Teams, and Exchange Online, target those first. If your tenant uses all cloud apps for in-scope work, that broader scope may fit. Still, I do not widen the net until I know how users, mobile clients, and contractors will react.

Microsoft’s Level 2 additional controls guidance is useful here because it places this policy inside a wider Entra security model instead of treating consent as a stand-alone fix.

Settings I recommend for compliance-minded tenants

A few settings make the difference between a policy that looks good in a demo and one that survives real use.

First, I keep Require users to expand the terms turned on. That does not prove someone read every line, but it is stronger than a passive accept button. Second, I set a real expiration schedule. Annual re-acceptance works for many teams, especially when policy language changes each year.

I also keep scope tight. Named groups beat “All users” during the early phase. Later, if the tenant is mature and the document applies widely, I may broaden it. For admins, I often use a separate policy or a separate admin-focused document. Privileged users should accept stronger language because their access is stronger.

Legacy auth needs its own attention. A sign-in path that does not use modern authentication may never see the prompt. Because of that, I block legacy auth with a separate Conditional Access policy or phase it out before I count on Terms of Use for evidence.

Service accounts are another trap. They cannot accept terms. If I find them in scope, I exclude them from the acknowledgment flow and protect them with other controls, such as narrowed permissions, certificate-based auth where possible, and close review.

For contractors and guests, I test every path. Some organizations want the same text for employees and external users. Others need a separate contractor document. I choose clarity over reuse. If the wording is not right for the audience, the acceptance record is weaker.

How Terms of Use fits with MFA and user acknowledgment workflows

Terms of Use works best when I place it beside, not above, the other controls. Conditional Access decides when the rule applies. MFA confirms the user has more than a password. Terms of Use adds the acknowledgment record. Together, those steps give me a much better story for CMMC than any one of them alone.

The user flow should feel direct. A user signs in, meets the MFA requirement, opens the terms, accepts them, and then reaches the app. That is simple enough for daily use, yet it still gives me a point-in-time record tied to identity.

I do keep a separate acknowledgment process for broader policy sign-offs. For example, an annual HR or GRC workflow may still be the right place for handbook changes, export-control notices, or training attestations. Entra Terms of Use is better when the acknowledgment must sit in the access path itself.

This matters during tenant changes too. If I am cleaning up after an Office 365 Migration, reworking Cloud Management, or tightening a Secure Cloud Architecture design, I review the terms content at the same time. Access rules, app scope, and document language should match the tenant that users see today, not the one you had a year ago.

The same logic applies to mobile users. I test browser sign-in, desktop apps, and mobile Office clients because the prompt experience can vary by app and platform. If the acknowledgment does not appear where users actually work, the policy needs more tuning.

Rollout, testing, and audit evidence I always collect

A careful rollout saves support hours and keeps compliance evidence clean. I start with a pilot group that includes one normal user, one contractor or guest if relevant, one mobile user, and one help desk contact who can report the experience in plain language. I also verify that my excluded emergency account still bypasses the policy.

Then I test the sign-in path end to end. I want to see the prompt, open the document, accept it, and reach the app. After that, I repeat the test with a user who already accepted the terms to confirm that the policy is not nagging on every sign-in without reason.

For evidence, I keep five items together in the same ticket or change record. I save the PDF that users accepted, screenshots of the Terms of Use settings, screenshots of the Conditional Access grant controls, proof of pilot results, and the acceptance record for one or more test users. If an assessor or internal reviewer asks later, I can pull the full story in minutes.

I also document the user groups and exclusions. That step matters because scope is part of the control. If an admin asks why a break-glass account did not receive the prompt, I want the answer written down before the question comes up.

When I update the terms later, I treat it like a real change. I record who approved the new language, when it took effect, and whether users had to re-accept. That small discipline turns a routine Entra feature into strong operational evidence.

Where this control fits in a broader SMB security stack

I rarely deploy this control by itself. In Small Business IT, the real job is to connect identity policy to daily operations. That often means checking Cloud Infrastructure, cleaning up old access paths after an Office 365 Migration, and reviewing hybrid dependencies tied to older Data Center Technology.

The same pattern shows up outside office users. For restaurant clients, Restaurant POS Support and Kitchen Technology Solutions bring shared devices, shift changes, and back-office accounts into the conversation. That makes Endpoint Security and Device Hardening matter even more, because a signed acknowledgment is only strong when the device and session controls match it.

When I build this out for clients, it sits inside broader Cybersecurity Services and Cloud Management. Good policy scope also depends on Infrastructure Optimization, clean group design, and practical Technology Consulting. Over time, that becomes Tailored Technology Services, not a pile of unrelated settings.

That is also where I bring in the business view. A strong Business Technology Partner does not stop at one prompt screen. I tie the work to IT Strategy for SMBs, Managed IT for Small Business, and Business Continuity & Security so the tenant stays usable during audits, staff turnover, and app changes. The point of Digital Transformation is not new tools by themselves. It is safer access, better proof, and Innovative IT Solutions that still hold up when the assessor starts asking questions.

Put acknowledgment where access begins

A well-built Entra Terms of Use policy does one job clearly: it places user acknowledgment at the moment access is granted. For a CMMC Level 2 tenant, that is useful evidence, especially when I pair it with MFA, tight Conditional Access scope, and clean records.

The strongest setup is usually the simplest one. Use approved language, target the right users, exclude recovery accounts, test every sign-in path that matters, and keep proof of acceptance.

That is how I make CMMC Entra Terms of Use worth more than a checkbox. It becomes a small control with a clear purpose, a clean audit trail, and a real place in a stronger Microsoft 365 security program.