CMMC Level 2 Authentication for CUI SharePoint Sites

Most SharePoint sites can live with a baseline sign-in policy. A site that stores CUI can’t.

When I protect Controlled Unclassified Information in Microsoft 365, I want one extra checkpoint before a user opens that content. That is where CMMC Level 2 authentication context matters, because it lets me raise the bar for one site without forcing the whole tenant through the same friction.

The concept gets much easier once the Microsoft terms are stripped away.

What authentication context means in plain English

Authentication context is a tag in Microsoft Entra ID. I attach that tag to a SharePoint site, and Conditional Access reads it when a user tries to open the site.

If the tag says the site is sensitive, Entra can ask for stronger proof. That might mean MFA, a stronger authentication strength, a compliant device, or a trusted network. Meanwhile, the rest of Microsoft 365 can keep its normal policy.

I explain it this way to admins and compliance teams: the tenant has a front door, but some rooms need their own lock. A public-facing HR site might need normal MFA. A SharePoint site with CUI might need MFA plus a managed device before the page even loads.

That targeted control fits the spirit of Level 2. CMMC expects you to identify users, limit access, and protect CUI based on risk. Microsoft’s CMMC Level 2 access control guidance is a solid reference for the Entra side of that work, and I use it as a map when I build policies.

Authentication context raises the sign-in bar for a site. It does not replace permissions, labeling, device trust, or audit evidence.

That last point matters. I do not treat authentication context as a shortcut to compliance. It helps enforce one part of access control. It does not fix broad SharePoint permissions, weak data classification, poor guest governance, or missing logs. If those gaps stay open, the site may still fail a CUI review even if sign-in looks strong.

How I gate a CUI SharePoint site with Conditional Access

When I build this for SharePoint Online, I start with the site boundary. A program workspace, engineering library, or contract repository may hold CUI. The rest of the tenant usually does not, and that distinction shapes the whole design.

Next, I create an authentication context in Entra ID. Then I build a Conditional Access policy that targets that context. For most CUI sites, I require strong MFA, and when the risk is higher, I use a stronger authentication strength. I also require a compliant device, or a hybrid-joined device where that fits the environment.

After that, I apply the context to the SharePoint site. In many tenants, I use a sensitivity label for the container because it can package site privacy, external sharing, and unmanaged device rules in one place. If label-based assignment does not fit, PowerShell can attach the authentication context directly to the site.

This is the difference I usually want on day one:

Area	Standard collaboration site	CUI SharePoint site
Sign-in	Baseline MFA	Strong MFA or stronger auth strength
Device	Approved user access	Compliant or hybrid-joined device required
Sharing	Limited external sharing if needed	Guest sharing blocked by default
Session	Normal browser and sync use	Web-only or blocked download on unmanaged devices

The pattern is simple. The CUI site gets tighter proof, tighter device trust, and tighter session rules.

I also pair the policy with SharePoint controls outside Conditional Access. Site membership stays narrow. Owners are limited. Guest access is off unless a contract requires it and the risk is documented. If browser access from unmanaged devices is allowed at all, I prefer web-only viewing with download restrictions.

A concrete example helps. If a defense supplier keeps drawings and contract mods in a site called “Program Falcon CUI,” I would not let every project manager in the tenant browse it after a normal sign-in. I would require a managed device, approved group membership, and stronger MFA. For teams that want a second viewpoint on that approach, this guide on MFA and process-based access controls is a useful cross-check.

Before rollout, I test the policy with real users, real browsers, and the OneDrive sync client. I also keep emergency access accounts out of the normal user scope and protect them with separate controls and logging. Poor policy scope causes more pain than the feature itself.

Common failure points on CUI SharePoint sites

I see four mistakes more than any others, and each one weakens the whole model.

• Overbroad access usually starts with group sprawl. A site can have perfect sign-in rules and still be too open because the wrong Microsoft 365 group grants access.
• Guest sharing often stays enabled by accident. A label, site setting, or Teams-connected site can allow external users long after the business forgot about them.
• Unmanaged devices create quiet risk. If the policy only checks sign-in and ignores device state, a user can reach CUI from a personal laptop with weak controls.
• Poor scoping breaks either security or operations. I have seen admins target the wrong users, miss service accounts, or forget the OneDrive sync path.

Legacy baggage makes those problems worse. After an Office 365 Migration, old sharing links, stale owners, and inherited permissions can stay behind. The site looks locked down on paper, but the real access path is wider than anyone expects.

I also watch for sites that mix CUI with ordinary project content. Once that happens, people push for broad access because “the team needs it.” I would rather split the content and put the stricter policy on the smaller site. That keeps the rule set clean and cuts user complaints.

Logs matter, too. Conditional Access reports, SharePoint audit events, access reviews, and approval records all support the story you will need later. If I cannot show who had access, how they got it, and what controls applied, I do not have a strong compliance position.

Where this fits in a broader CMMC program

When I advise a contractor, I treat authentication context as one layer in a larger control stack. CMMC Level 2 pulls from NIST SP 800-171, so identity rules must line up with logging, data handling, training, incident response, and written procedures. Microsoft’s technical reference guide for CMMC L2 is helpful here because it ties Microsoft controls to the framework, but I never read it as a promise of certification.

For a Small Business IT team, that broader work often touches Cloud Infrastructure, Secure Cloud Architecture, and day-to-day Cloud Management. Old permissions can survive an Office 365 Migration, while on-prem connectors and Data Center Technology can still shape who reaches a site. Good Endpoint Security and Device Hardening matter because Conditional Access only trusts the device state it sees.

That is why I want a Business Technology Partner that can connect Technology Consulting, Infrastructure Optimization, IT Strategy for SMBs, and Managed IT for Small Business. I group that work under Cybersecurity Services and Business Continuity & Security, but the point is practical: fewer exceptions, cleaner evidence, and safer collaboration around CUI.

The same discipline applies outside classic manufacturing. I have seen firms known for Restaurant POS Support and Kitchen Technology Solutions run into CUI rules when they support federal facilities or defense dining contracts. In those shops, Digital Transformation, Innovative IT Solutions, and Tailored Technology Services only matter if access controls stay tight and support staff do not get blanket rights to sensitive sites.

Final thoughts

Not every SharePoint site needs the same front door. CUI sites do, and authentication context gives me a clean way to ask for stronger proof right where risk goes up.

The strongest result comes from tight scoping, narrow permissions, managed devices, and solid evidence. Used that way, authentication context is a smart control component inside a real CMMC program, not a shortcut around one.