Neowin first reported both changes under a Windows 11 headline. Microsoft's documentation scopes both features to "Windows" in general, and this article follows Microsoft's wording. Admins should also expect the usual Intune timing: Microsoft says monthly service updates reach tenants gradually, so a feature can appear in one tenant days before another.
Intune Deployment Plans Bring Ring-Based Rollouts to Windows Apps and Policies
Microsoft's release note describes deployment plans as a new way to roll out apps and configuration policies in stages instead of all at once. From the new Deployments experience in the Intune admin center, you can stage a rollout across multiple rings, control rollout timing, and integrate with Multiple Admin Approval to reduce risk when deploying changes to large device fleets. According to the HTMD blog, which walked through the new interface, you can access deployments in the Microsoft Intune admin center under Devices > Manage devices > Deployments.
The scope is narrow. The feature applies to Windows, and the supported payloads are Win32 and Enterprise app catalog apps, plus Settings catalog and Endpoint security policies. Microsoft does not list other app types, legacy configuration profile templates, compliance policies, or macOS, iOS or Android devices. Admins who hoped to stage a new compliance policy or a line-of-business MSI this way will need to keep using their current methods.
Microsoft's own wording also changed. A pre-release version of the entry in Microsoft's documentation repository said administrators "will be able to" stage rollouts. The What's new page now says Intune "now supports" deployment plans. The feature has moved from roadmap item to shipping capability, though tenants will see it at different times.
How Intune Deployment Plans and Deployments Split the Work
The new feature has two parts. Microsoft's overview defines a deployment plan as a reusable template that defines a standardized rollout pattern for delivering a payload across devices in controlled stages, or rings. A plan holds no app or policy itself. It sets the number of deferral days and hours between rings, supports scope tags for delegated administration and visibility, and can be edited after it is created.
A deployment is the part that actually delivers something. A deployment delivers one Intune payload, such as an app or device configuration policy, to devices through a gradual rollout. You can use a deployment plan or manually define rings, timing, and group assignments. Teams can build a standard pattern once, such as IT pilot, then early adopters, then everyone, and reuse it across many apps and policies. For a one-off change, they can define rings by hand.
HTMD's walkthrough explains what happens to assignments during a rollout. When the deployment starts, the payload keeps its existing Required assignment. As each ring becomes active, the groups from that ring are added to the payload. This allows the app or policy to reach more devices step by step. The earlier assignments remain in place as the deployment moves forward. In practice, the rings add up. Ring 2 extends the audience of ring 1 rather than replacing it.
Rings that use a virtual group, such as an all-devices target, are the exception. Microsoft notes that a ring that contains a virtual group is treated as the final ring in the plan and in deployments created from the plan. Virtual groups and Microsoft Entra security groups can't be combined in the same ring. When that ring starts, the virtual group replaces the payload's Required include-group assignments to Microsoft Entra security groups. The admin center shows a confirmation dialog when you pick a virtual group, which is a sign of how much this final step changes.
Prerequisites Before Creating an Intune Deployment
Microsoft's setup guide lists a few conditions to check before building a first deployment:
- Admins need Read and Assign permissions for the payload's category: for a device configuration payload, use the Device configurations category. For an app payload, use the Mobile apps category.
- The supported app or policy that you want to deploy must already exist in Intune. A deployment wraps an existing object. You do not create the app or policy inside it.
- The payload can't be selected in more than one scheduled or active deployment.
- Each ring must have at least one group assignment.
The documentation available for this article describes how a rollout moves forward on its deferral timer. It does not describe any automatic halt when problems appear. Admins should assume that stopping a bad rollout still takes a person watching ring 1 before the timer expires.
Where Multiple Admin Approval Fits into Intune Deployments
The Multiple Admin Approval (MAA) link is the feature's governance piece. The pre-release entry in Microsoft's documentation repository described it as integrating with Multiple Admin Approval for change control. This helps you reduce risk when introducing changes to large device fleets.
MAA is Intune's four-eyes control. Microsoft's documentation explains that when any account in the Tenant is used to make a change to a resource that's protected by an access policy, Intune won't apply the change until a different account explicitly approves it. The prerequisite is simple but easy to miss in small shops: to use Multi Admin Approval, your tenant must have at least two administrator accounts. Microsoft also warns that one related option, Allow access to unlicensed admins, is irreversible. Once enabled, you can't turn it off.
Rings and approvals guard against different failures. Rings limit how many devices a faulty package or policy can reach before someone notices. MAA stops a single mistaken or compromised admin account from pushing a change in the first place. Microsoft has a dedicated page on permissions, scope tags and approvals for deployments, but it was not reviewed for this article. Exactly which MAA access policy covers a deployment of a Settings catalog policy, as opposed to an app, is a detail to confirm in your own tenant before relying on it.
What Deployment Plans Change Compared with Assignment Filters
Before this feature, Intune admins built staged rollouts by hand. They assigned a policy to a pilot group, waited, and then edited the assignment to add broader groups, or they used assignment filters to control scope. The 2608 service release in late August made the "operatingSystemVersion property in assignment filters generally available. Microsoft's example was using it to pilot a configuration on a newer build before rolling it out broadly.
Those tools still matter, and they solve a different problem. Filters decide which devices qualify for an assignment. Deployment plans decide when each group of devices gets it, and they turn that schedule into a reusable object instead of a series of manual edits. For teams that already run pilot-then-broad rollouts by hand, the gain is consistency and less manual work. Deployment timing is enforced by deferral values, not by someone remembering to add a group on Thursday.
This follows the pattern Microsoft already uses for Windows updates. Autopatch and update rings have long offered staged exposure for OS content. Deployment plans bring a similar model to the apps and security policies admins write themselves, which can do as much damage as a bad cumulative update when pushed to every device at once.
Client-Driven Compliance Evaluation Speeds Up Windows Compliance Status
The second change arrived a week earlier. Microsoft's What's new log for the week of September 14, 2026 says Intune now supports client-driven compliance evaluation for Windows devices. Supported devices can notice changes in firewall, antivirus, BitLocker, Microsoft Defender status, OS build, real-time protection and Secure Boot state, and ask for reevaluation instead of waiting for the next scheduled check-in. Microsoft says this gives faster compliance updates for remediation, reporting and access decisions.
The Windows compliance settings reference describes two ways this works. With scheduled monitoring, the Intune Management Extension (IME) regularly checks compliance-related settings on the device, compares them against a previously known baseline, and starts a check-in if something has changed. With real-time monitoring, Intune watches the seven settings listed above for changes as they happen and requests a device check-in right away, so compliance is reevaluated much faster than periodic checks alone would allow.
Microsoft adds one limit. Intune throttles compliance-triggered reevaluations to protect service reliability. If several changes happen in a short period, some may not be processed until a later evaluation cycle. The feature makes status updates faster, not instant.
The compliance rules themselves have not changed. Organizations still write and assign Windows compliance policies as before. Microsoft's compliance overview still says evaluation depends on device check-in and refresh cycles, and it now adds that supported Windows devices can request reevaluation when they detect local state changes.
Why Faster Compliance Matters for Conditional Access
Timing matters most when compliance controls access. When Intune compliance results feed Microsoft Entra Conditional Access with a "Require device to be marked as compliant" control, the status Intune reports decides whether a device can reach email and other company resources. If a user turns off the firewall or real-time protection, the device can now be flagged much sooner than the next scheduled check-in would allow. Once the user fixes the problem, the device can also get access back sooner.
Some existing Windows compliance behaviors still apply and should shape expectations. Microsoft's settings reference notes that the Require BitLocker setting, which relies on Device Health Attestation, is measured only at boot. A device may need a reboot before it shows as compliant, even after encryption has finished. A reasonable inference is that faster reevaluation does not remove that reboot requirement for health-attestation-based settings. The same reference says the firewall setting may report as an Error if a device syncs right after a reboot or wake from sleep. It also says a Group Policy object that turns off the firewall will make the device noncompliant even when Intune tries to enable it. Faster evaluation will surface those conflicts sooner. It will not resolve them.
Microsoft's release note refers to "supported" Windows devices. The documentation reviewed for this article does not list the specific Windows builds or IME versions that qualify. Admins with mixed fleets should watch their compliance reports instead of assuming every PC gets the faster path.
What Intune Admins Should Do About Deployment Plans and Compliance
Teams that push Win32 apps or Endpoint security policies to large Windows fleets should try deployment plans now. Everyone else can let client-driven compliance take effect and simply adjust their expectations about timing.
For deployment plans, a sensible first step is to build one reusable plan that mirrors your existing pilot structure. Then run a low-risk Win32 app update through it and watch how assignments grow at each ring before moving security policies onto it. Remember that a deployment starts from the payload's existing Required assignment. Check that assignment before you begin, or the "pilot" may already reach more devices than you intended. Hold off on virtual-group final rings until you understand that they replace your Entra group assignments.
For compliance, review Conditional Access policies that depend on compliance status and tell your helpdesk that users may now see access blocked, and restored, faster after security changes. This is also a good moment to review the tenant-wide "Mark devices with no compliance policy assigned as" setting. Microsoft recommends setting it to Not compliant when compliance feeds Conditional Access.
- Deployment plans are in Intune for Windows as of the week of September 21, 2026, but tenants receive monthly updates gradually and may not see the Deployments node right away.
- Only Win32 and Enterprise app catalog apps, Settings catalog policies and Endpoint security policies can be delivered through a deployment.
- Each payload can be in only one scheduled or active deployment, it must already exist in Intune, and each ring needs at least one group.
- MAA requires at least two admin accounts, and the "allow unlicensed admins" option cannot be reversed once enabled.
- Client-driven compliance watches firewall, antivirus, BitLocker, Defender status, OS build, real-time protection and Secure Boot, and throttling can delay some reevaluations.
- BitLocker compliance based on Device Health Attestation still depends on boot-time measurement, so a reboot may still be needed before a device shows as compliant.
Deployment plans cover the release process: they control how widely an app or policy spreads, how fast, and with whose approval. Client-driven compliance covers what happens afterward, making sure access decisions reflect the device's current state instead of its last check-in. Both are limited to Windows and to a specific list of payloads and signals for now. For Intune shops, the practical next step is to move routine Win32 and Endpoint security rollouts into reusable plans as soon as the Deployments node appears in their tenant.