How I Build a CMMC Named Locations Policy in Entra ID

A trusted office IP can lower risk, but it can also create false comfort. When I build a CMMC named locations policy in Entra ID, I treat location as one signal, not the signal.

If a company handles CUI, I don’t stop at “trusted locations.” I pair named locations with MFA, device compliance, logging, exception handling, and clean documentation, because that’s what stands up during an assessment and during a bad day.

Named locations help, but they don’t satisfy CMMC Level 2 on their own

In Entra ID, named locations are saved definitions for public IP ranges or countries and regions. Conditional Access uses those definitions to make access decisions. On their own, named locations don’t allow or block anything.

That distinction matters for CMMC Level 2. Microsoft’s own guidance for configuring Entra ID for CMMC compliance is clear that the platform can help with identity-related practices, but my organization still owns the surrounding controls, process, and evidence. I read named locations as supporting data for policy, not as proof of compliance by themselves.

Named locations are policy inputs. The evidence comes from the full control set around identity, device trust, monitoring, and documented process.

For CUI access, I usually build around four requirements. First, users need MFA, and for admins I prefer phishing-resistant methods when possible. Next, the device should be compliant, or at least meet a defined trust state through Intune or hybrid join. I also block legacy authentication, because location won’t save an old protocol. Finally, I keep privileged access separate with PIM, approval flow, and tighter policy.

That means a named location is helpful when I want to recognize a corporate egress IP, a managed VPN exit point, or a country I never expect to see in sign-in logs. It is not enough when a user signs in from an unmanaged laptop, a proxy network, or a stolen session.

How named locations fit into Zero Trust and Conditional Access

I use named locations inside a broader Zero Trust model. In 2026, that still means verifying identity, device state, session risk, and access path every time, even when the user sits inside a known office.

Microsoft calls out named locations in its CMMC Level 2 access control guidance and its Zero Trust network protection guidance. I use both as guardrails. A practical pattern is simple: target CUI-related apps, include all users, then require MFA and a compliant device when the sign-in comes from outside trusted named locations. For privileged roles, I go stricter. I don’t give admins a location-based bypass.

A common example is Microsoft 365 access to CUI stored in SharePoint Online, Exchange Online, or Teams within a controlled tenant. My baseline policy is usually “all locations,” with exclusions only for well-documented office or VPN egress IPs. Then I add a second policy for admins that applies from any location, because admin risk doesn’t shrink when the source IP looks familiar.

In my Small Business IT projects, this work often lands next to Cloud Infrastructure planning, Office 365 Migration cleanup, and older Data Center Technology that still affects identity traffic. I treat it as part of Cybersecurity Services, Cloud Management, and a Secure Cloud Architecture. That keeps the policy grounded in the rest of the environment, not floating as a one-off setting.

How I configure IP-based and country-based named locations

I start with IP-based named locations because they are more precise and easier to defend during an assessment. Country-based locations help too, but I use them for broad restrictions, not fine-grained trust.

This is the comparison I keep in mind:

Location type	Best use	Main strength	Main limit
IP-based	Office egress, data center exits, VPN gateways	Precise and auditable	Breaks when public IPs change
Country-based	Blocking countries with no business need	Fast to deploy	Weak signal for travelers, VPNs, and proxies

For a manufacturer handling CUI, I might define these named locations:

Name	Example range	Trusted
HQ Firewall Egress	203.0.113.8/29	Yes
Secondary Office	198.51.100.24/32	Yes
Corporate VPN East	198.51.100.64/27	Yes
High-Risk Countries	Country list only	No

I only use public IP ranges. Private ranges like 10.0.0.0/8 have no value here because Entra evaluates internet-facing sign-ins. I also name every entry so the owner, purpose, and change path are obvious. “HQ Firewall Egress” is better than “Office1.”

If I need repeatable changes across tenants, I script updates with the Set-Entra Named Location Policy cmdlet. That helps when an ISP changes circuits or when I maintain separate production and test environments. As a Business Technology Partner, I don’t want guesswork in change control. Good Technology Consulting is often plain naming, version history, and verified ownership.

I also stay careful with the “trusted location” checkbox. I mark an IP as trusted only after I verify who owns it, how stable it is, and who will tell me when it changes. Innovative IT Solutions don’t help if the wrong broadband block ends up marked trusted.

Remote users, VPNs, dynamic IPs, and exception handling

This is where many policies fail in real life. Location is easy to describe on a diagram, but users don’t live on diagrams.

A home worker with a dynamic ISP address should not become a trusted named location. If that user needs CUI access, I would rather require MFA, a compliant device, and a managed session than trust a home IP that may change next week. The same caution applies to hotel networks, coffee-shop Wi-Fi, and mobile hotspots.

VPNs help, but they add their own issues. If remote staff route traffic through a corporate VPN, I trust the VPN egress IP, not the home network. If the VPN provider changes egress addresses, or if a failover path uses a new block, the policy can misfire. The same issue shows up in distributed sites that need Restaurant POS Support or Kitchen Technology Solutions, where LTE backup circuits can swap public IPs without warning. In those cases, Endpoint Security and Device Hardening carry more weight than a location label.

Country-based rules also have limits. Geolocation can be wrong, and users can appear to sign in from a VPN or proxy exit node. That is why I never use country data as my only allow rule for CUI. It is a filter, not a trust anchor.

For exceptions, I keep them narrow and time-bound. If a cleared engineer must access CUI while traveling, I don’t add the hotel IP to a trusted list. I place the user in a temporary exception group, require stronger MFA, confirm device compliance, log the approval ticket, and set an expiry time. For Managed IT for Small Business, that kind of discipline beats a bloated trusted-location list every time.

Documentation and evidence collection for assessments

Assessors care about what I can show, not what I say I configured last quarter. So I document named locations as if someone else will need to explain them under pressure.

My evidence set usually includes these items:

• A named location register with names, IP ranges, owners, purpose, and trust status
• Conditional Access policy exports or screenshots that show how locations affect access
• Change records for ISP updates, VPN changes, and exception approvals
• Entra sign-in logs, audit logs, and Conditional Access results
• Device compliance reports, MFA settings, and PIM records for privileged access
• A review record that shows I checked stale entries and removed what no longer belonged

I map that evidence to the control objective. For example, a named location entry alone proves little. When I pair it with sign-in logs, device compliance results, and policy documentation, I can show how authorized access is limited and how remote access is controlled. Microsoft’s identity access controls for CMMC Level 2 are useful here because they keep the focus on the full control picture.

I also keep logs long enough to support audits and internal reviews. When licensing and SIEM design allow it, I prefer at least a year of relevant history. That makes trend reviews easier and gives me better proof when a policy changed mid-cycle.

For clients buying Tailored Technology Services, I tie this paperwork back to Infrastructure Optimization, Business Continuity & Security, and a practical IT Strategy for SMBs. During a larger Digital Transformation, I still keep the same standard. A real Business Technology Partner treats evidence as part of the build, not as cleanup after the fact.

Conclusion

A strong Entra named locations policy can reduce noise and strengthen Conditional Access, but it does not satisfy CMMC Level 2 by itself. I trust it as one signal inside a broader identity and device control set.

When CUI is in scope, the winning pattern is clear: verify the user, verify the device, verify the access path, and document every exception. That is how I turn location data into usable evidence, not false confidence.