CMMC Level 2 DNS Filtering Checklist for Endpoints and Phones

One missed DNS setting can hand a phishing site a straight path to a managed device. For CMMC DNS filtering, I treat it as a practical control that lowers exposure on laptops, tablets, and phones, especially when users work away from the office.

If you support CUI, you need more than a blocked-domain checkbox. I use the checklist below to verify coverage, close bypasses, and collect evidence an assessor can review with confidence.

Where DNS filtering fits in CMMC Level 2

As of 2026, CMMC Level 2 assessments still measure implementation against the 110 security requirements in NIST SP 800-171 Rev. 2. DNS filtering is not a named product requirement. Still, it helps support access control, system and information integrity, and communications protection because it can block known malicious domains, phishing sites, and some command-and-control traffic before a session starts.

I keep expectations realistic. DNS filtering acts at name resolution. It does not inspect full URL paths, judge page content the way full web filtering can, stop every hard-coded IP connection, replace EDR, or manage the device itself. That’s why I pair it with Endpoint Security, Device Hardening, MDM, and firewall controls.

In small environments, this gap shows up often. I’ve seen teams invest in Cloud Infrastructure, Office 365 Migration, or Data Center Technology and still miss the phone in a supervisor’s pocket. The same pattern appears in Restaurant POS Support and Kitchen Technology Solutions, where tablets and handhelds fall outside normal Cybersecurity Services.

As Vaultes’ overview of CMMC requirements for small businesses notes, DNS filtering is part of many practical CMMC stacks. I also like Lakeridge’s write-up on egress filtering and DNS controls because it connects DNS policy to outbound traffic control, not a stand-alone feature.

Endpoint checklist for Windows and macOS

When I build endpoint coverage, I start with the simple question that catches most failures: does the device use company-controlled DNS on and off the network?

• Put every in-scope Windows and macOS endpoint on approved DNS filtering, both on-site and remote. A control that only works on office Wi-Fi leaves a large hole.
• Use a roaming client, agent, or VPN-based method for off-network users. If the device falls back to home router DNS, the policy is gone when it matters most.
• Block resolver bypass in browsers. Chrome, Edge, Firefox, and other apps can use secure DNS or DoH and skip the operating system resolver unless I manage those settings.
• Limit local admin rights. Users with local control can change DNS servers, remove agents, or alter browser policies. Least privilege still matters here.
• Separate policies by role and risk. Admin devices, executives, IT staff, test systems, and general users do not need the same browsing policy.
• Log blocked lookups with asset context. I want hostname, username, IP, policy group, timestamp, and domain category tied together.
• Alert on meaningful events. Repeated hits on malware domains, newly registered domains, or suspicious command-and-control patterns matter more than raw block volume.
• Keep retention long enough for reviews and investigations. If the DNS platform stores little history, export events to your SIEM or log platform.
• Test enforcement on and off the VPN. I verify office LAN, corporate Wi-Fi, split-tunnel VPN, hotspot tethering, and home broadband because bypasses hide in path changes.
• Write down your exception process. Business apps break. When I approve an exception, I record the owner, reason, reviewer, date, and expiration.

For Windows, I usually manage DNS and browser settings through Intune, Group Policy, or the endpoint tool already in place. For macOS, I rely on MDM profiles, browser policy, and a quick validation script or test procedure. The key is consistency. I don’t want one policy in the console and a different reality on the laptop.

DNS filtering reduces exposure, but it does not prove a device is managed, patched, or clean.

This is where broader service work matters. In Small Business IT, I want DNS controls folded into Cloud Management, Secure Cloud Architecture, and the rest of the stack, not left as a side project. Good Managed IT for Small Business should connect DNS filtering to IT Strategy for SMBs, not treat it as a one-time install.

Phone checklist for iPhone, iPad, and Android

Phones need their own checklist because mobile traffic behaves differently. Users move between cellular data, home Wi-Fi, guest networks, and captive portals all day. Without MDM or UEM, mobile DNS policy is mostly trust.

• Push DNS settings or the approved filtering app through MDM. Manual setup on phones does not last.
• For iPhone and iPad, use supervised enrollment when possible. That gives me stronger control over DNS settings, content filtering, and related network restrictions.
• Review iCloud Private Relay and similar privacy features. If policy requires company DNS visibility, I disable or restrict conflicting settings through MDM where allowed.
• For Android, use Android Enterprise in work profile or fully managed mode. I also control Private DNS so users cannot point the device at an outside encrypted resolver.
• Decide how off-network enforcement works. Some tools use a local mobile agent, while others depend on always-on VPN or per-app VPN. I test both Wi-Fi and cellular paths.
• Confirm which apps are in scope. Office apps, browsers, remote support tools, line-of-business apps, and messaging clients may all touch CUI or sensitive workflows.
• Keep BYOD access narrow. Personal phones are hard to defend under Level 2 because logging, policy enforcement, and proof of control are weak.
• Review mobile alerts with the same discipline as laptop alerts. Repeated hits on phishing domains from a phone may point to SMS phishing, QR abuse, or a risky app.

I treat MDM and DNS filtering as separate jobs. MDM pushes settings and enforces device state. DNS filtering blocks lookups to bad domains. EDR or mobile threat defense watches behavior on the device. Firewalls and conditional access help after that first lookup. When teams mash those together, they usually miss a gap.

This matters during broader Digital Transformation work. Mobile email, file access, and collaboration apps can move faster than policy. If I am the Business Technology Partner on the account, I want mobile DNS rules built into the same Technology Consulting motion as identity, MDM, and endpoint hardening.

Common gaps and the evidence I keep ready

The gaps I find most often are boring, which is why they survive so long. Browser DoH bypasses the agent. Split-tunnel VPN sends DNS outside the company path. A replacement iPhone never receives the right supervised profile. Android Private DNS stays user-controlled. An exception gets approved and never expires.

A blocked-domain list by itself is weak evidence. I want proof that the policy exists, the devices received it, the logs show activity, and staff review alerts.

Here’s the evidence set I keep ready for assessments:

Evidence	What I keep	Why it helps
Policy language	A written requirement that in-scope endpoints and phones must use approved DNS filtering and may not override DNS settings without approval	It shows intent, scope, and governance
Deployment records	Intune, Jamf, RMM, or MDM rollout reports with asset counts and dates	It shows coverage across devices
Screenshots	Policy pages, blocked categories, browser secure DNS restrictions, mobile profiles	It shows configured enforcement
Logs and alerts	Block events, domain categories, user and host mapping, analyst review notes, ticket references	It shows the control operates in practice
Exception approvals	Approved requests, owner, reason, date, reviewer, expiration, and follow-up review	It shows risk decisions are managed
Proof of enforcement	Test results from sample Windows, macOS, iPhone/iPad, and Android devices on and off network	It shows the control works where users work

If the DNS platform protects in-scope assets, I document it in the SSP, asset inventory, and vendor records. I’ve seen the scope question come up often, and this discussion of DNS providers under CMMC scope shows why I don’t leave that decision undocumented.

I also keep the control tied to the wider operating model. In my view, Innovative IT Solutions and Tailored Technology Services only matter when they produce repeatable evidence. That means linking DNS filtering to Infrastructure Optimization, Business Continuity & Security, cloud admin records, and incident workflows, not leaving it in a separate console no one checks.

Conclusion

A strong CMMC DNS filtering control is easy to explain and easy to prove. Every in-scope endpoint and phone uses company-approved DNS, bypass paths are closed, alerts are reviewed, and exceptions are documented.

When I can show policy language, deployment records, screenshots, logs, approvals, and live test results, the control stops looking theoretical. Proof of enforcement is what turns DNS filtering from a helpful tool into assessment-ready security.