CMMC Level 2 Defender for Endpoint Onboarding in Intune

A device can look healthy in Intune and still fail your CMMC story. If the Defender sensor never onboards, you lose threat telemetry, device risk, and clean audit evidence.

When I handle CMMC Intune onboarding, I treat Intune as the deployment plane and Defender for Endpoint as the proof plane. As of April 2026, that means working across Microsoft Intune, Microsoft Defender for Endpoint, Microsoft Entra ID, and the Defender portal at security.microsoft.com.

What onboarding means for CMMC Level 2, and what it does not

Microsoft’s current Intune integration guidance and its page on onboarding using Microsoft Intune draw a clean line between setup and outcome. Intune deploys the onboarding configuration. Defender for Endpoint receives the device and starts sensor-based telemetry. Microsoft Entra ID can then use device signals in Conditional Access.

If your runbooks still say Azure AD or Microsoft Endpoint Manager, I’d update them now. Those old names create confusion during audits and handoffs. For CMMC work, I keep the terms current because assessors will look for consistency across screenshots, policy names, and procedures.

I split the work into three buckets:

Area	What I configure	What I prove
Intune	Endpoint security policy and assignment	Policy status and device assignment
Defender portal	Sensor onboarding and device health	Device inventory and last-seen status
Entra ID	Access policy using device state	Conditional Access policy and sign-in logs

That distinction matters because onboarding alone does not satisfy CMMC Level 2. Microsoft’s CMMC offering overview and CMMC Level 2 access control guidance point to a wider control set around identity, logging, scoping, and protection of CUI.

A green status in Intune is not the same as successful Defender onboarding.

The Defender for Endpoint onboarding workflow I use in Intune

I start with prerequisites before I build a single policy. Licensing must line up, supported operating systems must be in scope, and the service-to-service connection between Intune and Defender has to be active. If one piece is missing, the rollout looks fine on paper and weak in practice.

Then I move through the workflow in order:

1. Confirm the Defender and Intune connection in the tenant.
2. Create the platform-specific onboarding policy in Intune.
3. Assign it to a pilot group, not the full fleet.
4. Check that the device enrolls and the Defender sensor reports in.
5. Add compliance and Conditional Access rules only after telemetry is stable.

Microsoft also described a simplified onboarding experience update, which helps with visibility during deployment. I still pilot first because policy conflicts hide easily. A security baseline, AV policy, and custom settings profile can collide without warning.

For CMMC Level 2, I care about more than deployment success. I want EDR data, device risk, and a repeatable process for failed devices. If a laptop enrolls in Intune but never appears in Defender, I treat that as an exception to investigate, not a minor delay.

How I verify onboarding and build evidence for an assessor

Once devices appear in Defender, I shift from deployment mode to evidence mode. An assessor usually wants to see that the setting exists, reached the endpoint, and produced a security result over time.

The screenshots and reports I save most often are:

• Intune policy configuration, assignments, and per-device status
• Defender device inventory showing onboarded state and last seen
• Sample device timelines or health views from the Defender portal
• Entra Conditional Access policies and sign-in results tied to device state

I also keep timestamps, pilot notes, and a short exception log. That helps when a device misses policy, falls out of scope, or needs manual review.

The most common failures are predictable. I see devices enrolled in Intune without successful Defender sensor onboarding. I see duplicate policies fighting over antivirus or EDR settings. I also see licensing gaps, especially when teams expect risk-based access decisions without the right stack. The biggest mistake, though, is assuming onboarding alone meets CMMC requirements. It doesn’t. It supports the control story, but it is not the whole story.

In my Small Business IT work, I tie this to Cloud Infrastructure, Office 365 Migration, Data Center Technology, and Cloud Management. For firms that need Restaurant POS Support or Kitchen Technology Solutions, I scope those devices carefully. That connects Endpoint Security and Device Hardening to broader Cybersecurity Services. It also supports Tailored Technology Services, Innovative IT Solutions, Technology Consulting, Infrastructure Optimization, Digital Transformation, IT Strategy for SMBs, Secure Cloud Architecture, Managed IT for Small Business, and Business Continuity & Security. That’s the value I bring as a Business Technology Partner.

CMMC Level 2 lives or dies on proof. If Intune deploys the policy but Defender never reports, you have configuration without evidence.

I start small, verify in the Defender portal, and save proof as I go. If you’re planning your next rollout, build one pilot group, one policy set, and one evidence folder before you scale.