Entra Administrative Units for CMMC Level 2

Most CMMC trouble starts with a simple identity mistake, too many admins with tenant-wide reach. In Microsoft 365, that creates more access than the job requires, and it makes audits harder than they need to be.

When I set up Entra administrative units for CMMC-minded tenants, I use them to narrow admin scope, split duties, and cut risk. They help a lot, but they don’t prove compliance by themselves. The value comes from how you design, assign, test, and monitor them.

Why administrative units fit a CMMC Level 2 approach

CMMC Level 2 puts pressure on access control, role separation, and accountability. That doesn’t mean every identity feature maps one-to-one to a control. It does mean your Microsoft 365 tenant should reflect least privilege in a way an assessor can understand.

Administrative units in Microsoft Entra ID help me do that by scoping directory administration to defined users, groups, and devices. If your help desk only supports one business unit, that team shouldn’t manage the rest of the tenant. If HR support manages employee profile changes, that team doesn’t need rights over privileged accounts.

Microsoft documents this model in its guide to administrative units in Microsoft Entra ID. The core idea is simple, I assign the smallest admin boundary that still lets people do their jobs.

That boundary supports separation of duties in a practical way. A regional support admin can reset passwords for one unit. A directory admin can manage a privileged unit. A security lead can review logs and role assignments without handing out broad rights.

If your team still says Azure AD, you’re talking about the same identity layer, now called Microsoft Entra ID. The name changed, but the identity problem did not. Too much standing access is still too much standing access.

Administrative units narrow who an admin can manage. They do not satisfy CMMC on their own.

I treat AUs as one control point inside a larger security program. They work best when they sit inside a tenant that already uses MFA, logging, approval workflows, and disciplined role design.

Plan the AU model around job boundaries first

I never start by clicking “Create.” I start with a whiteboard, a role matrix, and a list of admin tasks that happen every week. That planning step saves rework later.

For most CMMC-focused tenants, I use business function and sensitivity as the first design filters. A common pattern looks like this: one AU for general workforce users, one for help desk operations, one for privileged accounts, and one restricted unit for high-value objects. In larger tenants, I may add geographic or program-based units.

Names matter more than people expect. I use labels that show purpose and scope at a glance, such as “AU-HelpDesk-East,” “AU-HR-Users,” or “AU-Privileged-Accounts.” Good names shorten audit conversations because the structure reads clearly.

I also decide early which objects belong in the unit. Users are the obvious starting point, but groups and devices matter too. If your admins support a controlled enclave, the device boundary may be as important as the user boundary.

Next, I map tasks to roles before I map roles to people. A help desk team may only need Helpdesk Administrator or Authentication Administrator. A user lifecycle team may need User Administrator. I avoid broad roles unless a narrow role clearly won’t do the job.

A short design note helps later. I document the unit’s purpose, owner, membership rule, approved roles, and review cycle. That note becomes useful during policy reviews, turnover, and audit prep.

I also decide where I need restricted management. Sensitive accounts, break-glass accounts, and critical groups deserve extra isolation. Those objects should not sit in the same AU as everyday user support.

How I set up administrative units in Microsoft Entra

Once the design is clear, the actual setup is quick. I sign in with Privileged Role Administrator or a higher role, then I work in the Microsoft Entra admin center under Identity, Roles and admins, Administrative units.

I follow this order because it keeps scope clean:

1. Create the administrative unit with a clear name and a plain-language description.
2. Decide whether the unit will use manual membership or dynamic membership, if your licensing and design support dynamic rules.
3. Add only the users, groups, or devices that belong inside that boundary.
4. Keep privileged accounts in their own AU, separate from general support populations.
5. Assign scoped roles to the AU, not tenant-wide roles to the person.
6. Use the smallest role that completes the task.
7. Record the owner, approval path, and review date before moving to production.

During creation, I keep descriptions direct. “Scoped help desk administration for East Coast employees” is better than vague text. Auditors and internal reviewers should understand the unit without guessing.

For restricted scenarios, I create a separate AU for sensitive accounts and critical groups. That keeps high-value objects behind tighter admin control. If your tenant supports restricted management administrative units, this is where I use them.

I avoid adding “just in case” objects. That habit weakens the model fast. If a device or group doesn’t need to be there, I leave it out.

After the unit exists, I pause before assigning admins. First, I confirm membership. Then I check whether the unit matches the written design. Only after that do I scope roles to it. That order prevents role assignments from spreading into a unit that was populated too broadly.

Add members, assign scoped roles, and test the result

This is the stage where a good design becomes real control, or turns into a false sense of safety. I want proof that the scoped admin can do the approved task and nothing more.

For membership, I choose manual assignment when the population is small or highly sensitive. I choose dynamic membership when the rule is stable, such as department, region, or a known attribute tied to a controlled business unit. If attribute quality is weak, I stay manual until HR and identity data improve.

Then I assign the role at the AU level. This is the point many teams miss. Giving a person a directory role without scoping it to the AU defeats the whole purpose. I double-check the assignment screen every time.

A simple pilot works well. I create one AU for a small department, add a few test users, and assign a test admin the narrowest role needed. Then I sign in as that admin and try real tasks. Can that admin reset a password inside the unit? Good. Can that admin change a user outside the unit? That action should fail.

I also test group management and device visibility if those objects sit in the AU. If a support team should only manage managed endpoints in one business area, I want that boundary verified before go-live.

The Practical365 write-up on delegated management with administrative units shows how useful these scoped models can be when rights need to stay narrow. I like it because it mirrors real tenant problems, not lab-only examples.

If a scoped admin can still affect objects outside the pilot AU, stop and fix the design before rollout.

Finally, I review audit logs after testing. A clean test leaves a paper trail that shows who acted, where they acted, and whether the scope held.

What to pair with AUs for real control

Administrative units are one layer. CMMC-minded tenants need more than one layer because admin scoping does not cover sign-in risk, device state, or session control.

I pair AUs with Privileged Identity Management when a role is sensitive or rarely used. That cuts standing privilege and adds approval, activation time, and audit records. A help desk admin may need standing access to a small AU. A privileged admin usually does not.

I pair AUs with Conditional Access because admin scoping does not block risky sign-ins. High-value roles should require strong MFA, trusted device posture, and location or risk-based conditions when appropriate. If an admin signs in from an unmanaged device, the AU boundary alone will not save you.

Groups still matter because AUs are not a replacement for workload authorization. I use groups for app access, SharePoint permissions, Teams ownership, and role-based app patterns. I use AUs for directory administration scope. Those are related, but they are not the same thing.

Intune belongs in the picture too. If CMMC scope includes endpoints, I connect identity boundaries with device compliance, Endpoint Security, and Device Hardening. That creates a stronger chain between who can administer, what device they use, and what condition that device is in.

In client environments that need Cybersecurity Services, Cloud Management, and Secure Cloud Architecture, this layered design pays off quickly. It also strengthens Business Continuity & Security because admin misuse and account compromise have less room to spread.

Limits and audit mistakes I see most often

The biggest mistake is treating AUs like a compliance checkbox. They are useful, but they don’t grant CMMC status. They scope admin authority inside Entra. They do not replace policy, logging, access reviews, or technical controls in other Microsoft 365 workloads.

I also see teams build AUs that are too large. A single unit for “All Users” may feel neat, but it barely improves admin exposure. If the unit contains the entire workforce, you’ve recreated broad access with extra steps.

Another problem is unsupported assumptions. Not every role or management scenario behaves the way people expect, so I always verify current Microsoft support before I commit to a design. The same caution applies to dynamic rules, restricted management, and hybrid identity edge cases.

Security research has also shown that AUs can become a blind spot if no one reviews how they’re used. The Datadog Security Labs analysis of Entra AU abuse is a useful reminder that scoping features need monitoring, not blind trust.

I also avoid mixing privileged accounts with regular workforce identities. When those objects sit together, routine support rights can drift too close to high-value targets. That is exactly the kind of design choice that raises questions in an audit.

The fix is not complicated. Keep units small, roles narrow, documentation current, and reviews scheduled. Then test the scope with real accounts, not assumptions.

A practical pattern for small business IT teams

I see the most value from this model in lean Microsoft 365 environments where one or two people wear too many hats. That is common in Small Business IT, and it is where scoped administration can reduce risk without adding heavy process.

Here is a pattern I use for a 150-user defense subcontractor:

Administrative unit	Typical members	Scoped roles	Purpose
Workforce Users	Standard employee accounts	Helpdesk Administrator, Authentication Administrator	Password resets and MFA method help
HR Users	HR staff and employee profile targets	User Administrator	User lifecycle tasks for HR-owned objects
Privileged Accounts	Admin identities only	Privileged Role Administrator, limited and reviewed	Isolation for sensitive identities
Secure Devices	Managed endpoints in scope	Device-related scoped admin roles where supported	Device-focused administration boundary

This model fits well during Office 365 Migration projects, Cloud Infrastructure cleanups, and Data Center Technology modernization, because old admin habits usually surface during those changes. I also use the same identity discipline in Managed IT for Small Business, Technology Consulting, and Infrastructure Optimization work.

When I act as a Business Technology Partner, I tie AU design to IT Strategy for SMBs, Digital Transformation, and Tailored Technology Services instead of treating identity as a side task. The result is more than access hygiene. It gives owners a clear admin map they can understand and defend.

The same least-privilege thinking also helps outside defense work. Teams that handle Restaurant POS Support and Kitchen Technology Solutions often deal with shared accounts, vendor access, and mixed devices. Scoped administration reduces unnecessary reach there too. That is why I treat identity design as part of Innovative IT Solutions, not a bolt-on afterthought.

Conclusion

A clean CMMC-ready tenant rarely starts with a new tool. It starts with smaller admin boundaries and better discipline around who can touch what. Entra administrative units help me build that discipline in a way that is visible, testable, and easier to defend.

The winning pattern is consistent, keep the AU small, keep the role narrow, and pair it with PIM, Conditional Access, groups, and Intune. When I follow that model, I get stronger separation of duties without handing out tenant-wide power.