Microsoft is preparing to extend a powerful set of device access restrictions—until now exclusive to Intune-enrolled PCs—to Windows 10 and 11 machines managed solely through Microsoft Defender for Endpoint. The company hasn’t provided a rollout date, but its unusually direct warning to administrators is clear: any existing Device Control policies assigned to devices that aren’t yet enrolled in Intune will automatically take effect as soon as the feature ships. That means USB lock-downs, printer restrictions, and removable-media blocks you thought were limited to your enrolled fleet could silently land on a much broader population of devices.

The change was confirmed in Microsoft’s Intune “In development” documentation and its Defender for Endpoint Device Control guidance. It eliminates the last major policy gap between traditional Intune management and the newer Defender security settings management path, and it puts every existing Device Control assignment under the microscope.

What’s Changing and Which Devices Are Affected

The new capability appears inside the Microsoft Intune admin center under Endpoint security > Attack surface reduction > Device control. Until now, those policies only applied to devices fully enrolled in Intune. After the update, the same policies will also target Windows 10 and Windows 11 PCs that are managed through Defender for Endpoint security settings management—even if those PCs have never enrolled in Intune.

Crucially, this does not mean every machine running Defender will suddenly inherit Device Control rules. The expansion is limited to the subset of Defender-protected endpoints that are already set up for security settings management. That setup allows certain Intune endpoint-security policies to reach unenrolled devices, and Device Control was one of the major holdouts. With the exception now being removed, any such device that belongs to an assigned group will start enforcing the associated rules.

Administrators should note that the update brings no new policy type; it simply changes the enforcement boundary. If you have an active Device Control profile assigned to a group that contains both enrolled and Defender-managed devices, the latter will begin complying with it after the feature goes live.

The Real-World Impact: From USB Blocks to Printer Snags

For end users, the first sign of trouble is likely a notification blocking a USB flash drive that worked yesterday, or a baffling refusal to print to a network printer that hasn’t changed. Device Control is often seen as a USB-only tool, but it can govern a wide range of hardware: removable media, CD/DVD drives, Windows Portable Devices (think phones and cameras), and printers.

A particularly dangerous scenario involves a policy with a default enforcement of “Deny.” That posture—often used to lock down all removable storage unless explicitly allowed—can extend to printers if the policy’s device-type list includes them. An admin who built the rule to stop unapproved USB drives might inadvertently block printing across the newly eligible Defender-managed fleet, generating a surge of help-desk tickets with no immediately obvious cause.

The same ripple effect can hit optical drives, specialist portable hardware, and media transfer workflows that were never part of the original enrollment scope. Because many IT teams historically built these policies with the understanding that only fully enrolled devices would process them, the risk is that countless assignments are grossly over-broad for the newly eligible population.

How We Got Here: Defender’s Expanding Policy Reach

Microsoft has been steadily eroding the wall between traditional Intune management and cloud-native Defender management for years. Defender for Endpoint security settings management, first released as a limited preview and later expanded, allows organizations to push certain security configurations to devices that don’t have a full Intune enrollment—a model attractive for contractors, bring-your-own devices, or acquisitions where full enrollment is impractical.

Initially, that bridge carried only core endpoint-security profiles like antivirus and firewall. Slowly, Microsoft added more. Device Control, however, remained exclusive to enrolled devices until this upcoming change. The company’s Intune “In development” page now marks Device Control support for security settings management as upcoming for Windows 10 and Windows 11.

That move aligns with Microsoft’s broader push toward centralized, policy-driven administration—the same philosophy behind Intune’s expanding endpoint-security capabilities and Windows Update controls. But Device Control carries a uniquely physical consequence: if a policy says “deny,” the user’s hardware stops working immediately. That makes a careful rollout plan essential.

What to Do Now: A Practical Preparation Guide

You can’t afford to wait for a general-availability date. Microsoft’s warning is explicit: assigned devices will apply settings once support becomes available. That turns your existing assignments into a ticking clock. Here’s how to get ahead of it.

Step 1: Take Inventory of Every Device Control Policy Assignment

Visit the Intune admin center and navigate to Endpoint security > Attack surface reduction. Open each policy that uses the Device Control profile. For every one, record:

  • The groups assigned (include and exclude)
  • The devices inside those groups, with special attention to any that are Defender-managed but not Intune-enrolled
  • The default enforcement setting (Allow or Deny)
  • The list of protected device types (removable media, printers, etc.)

If you’ve used broad groups—like “All Windows devices” or “All corporate endpoints”—there’s a high likelihood that Defender-managed machines are already members. Those will immediately inherit the policy.

Step 2: Narrow Down Broad Groups Before Enforcement Hits

A group that once contained devices unable to process the profile may become a live enforcement group overnight. This is the delayed-enforcement trap: the assignment already exists, the device is already in the group, and the only missing piece—platform support—will arrive silently.

Replace organization-wide Windows groups with narrower collections that accurately reflect the devices you intend to manage. Where possible, create separate groups for enrolled and Defender-managed endpoints, even if they need similar restrictions. That gives you a kill switch if something goes wrong on the Defender side without destabilizing your enrolled population.

Step 3: Build a Pilot That Mirrors Your Real Defender-Only Fleet

A conventional pilot tests a new policy on a few enrolled devices. Here, the policy may be unchanged; the variable is the population. Your pilot must include representative unenrolled, Defender-managed Windows 10 and 11 PCs. Testing only enrolled machines confirms an existing path, not the new one.

In the pilot:

  • Connect approved USB drives and attempt reads, writes, and executions.
  • Print through every standard workflow, including direct IP, shared queues, and Universal Print.
  • Test any optical drives still in use.
  • Plug in phones or cameras that employees rely on for file transfers.
  • Check that exclusions actually work—plug in a device that should be allowed and verify access.

Step 4: Check for Printer, Optical, and WPD Surprises

Before the pilot, map each enabled Device Control component to a real business workflow. Ask:

  • Do any of your policies block printers—even indirectly via default deny?
  • Are there legacy systems that still read CD or DVD media?
  • Do field workers use Windows Portable Devices for photo imports or data transfers?

If the answer is yes, and those workflows happen on Defender-managed devices, you need explicit inclusion rules or exclusions before the policy goes live. Don’t rely on the historical inability of those devices to process the policy; that shield is disappearing.

Step 5: Plan Your Escape Route (Rollback and Exclusions)

If the pilot produces unexpected denials, you need to act fast. The cleanest rollback is assignment-focused: remove the affected Defender-managed devices from the policy’s scope, or add an explicit exclusion group for those devices. This preserves the policy’s behavior for enrolled endpoints and gives you time to fix the design.

Document the group membership changes you’d make ahead of time. Consider creating a dedicated exclusion group for “Defender-managed, no device control” and leaving it empty until needed. That way, adding devices is a one-click change, not a policy redesign.

Step 6: Monitor, Don’t Just Block—Use Audit Mode First

Where the existing policy design allows, switch to audit-oriented enforcement before flipping to full deny. Device Control can generate events for Advanced Hunting without blocking access. That lets you observe matching activity—which devices, which users, which peripherals—before users see a hard failure.

Start with “AuditAllow” or “AuditDeny” entries for newly eligible devices. Review the logs for a few business cycles, confirm that only the expected actions would be blocked, and then tighten to enforcement. This extra step can save hours of panic when someone discovers their department’s crucial photo-upload workflow just broke.

What Comes Next

Microsoft has not specified a general-availability date, and the roadmap entry could sit “in development” for weeks or months. But the company’s tone is unusual. It isn’t asking admins to opt in; it’s warning them that their existing assignments will take effect. That suggests the engineering work is largely complete, and the feature could ship in a standard monthly service release with little fanfare.

Keep an eye on the Microsoft 365 roadmap and the Intune “What’s new” page. The moment you see a line about Device Control supporting security settings management, your deadline has arrived. By then, your audit should be complete, your pilot data analyzed, and your rollback plan tested. The goal isn’t to avoid the feature—centralized device control makes sense in a hybrid workplace—it’s to ensure that the transition doesn’t break the workflows you rely on every day.