Update conditional access policy for device compliance

[Jhope188]

Added condition to exclude non-compliant devices from access.

This step was missing to truly only target noncompliant devices.

[prmerger-automator]

@Jhope188 : Thanks for your contribution! The author(s) and reviewer(s) have been notified to review your proposed change.

[learn-build-service-prod]

Learn Build status updates of commit 6770ab3:

✅ Validation status: passed

File	Status	Preview URL	Details
docs/identity/conditional-access/policy-all-users-app-enforced-restrictions.md	✅Succeeded

For more details, please refer to the build report.

[v-dirichards]

@MicrosoftGuyJFlo

Can you review the proposed changes?

Important: When the changes are ready for publication, adding a #sign-off comment is the best way to signal that the PR is ready for the review team to merge.

#label:"aq-pr-triaged"
@MicrosoftDocs/public-repo-pr-review-team

[Copilot]

Pull Request Overview

This PR adds a new conditional access filter step to exclude compliant and domain-joined devices from the app enforced restrictions policy. This allows organizations to apply restrictions only to unmanaged devices while exempting managed ones.

• Adds a device filter condition to exclude devices that are both compliant and domain-joined

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Should be 'Conditions' (plural) not 'Condition' (singular) to match Microsoft Entra Conditional Access terminology.

Suggested change

	1 Under **Condition** filter for devices **Exclude filtered devices** set to device.isCompliant -eq True -and device.trustType -eq "ServerAD"
	1 Under **Conditions** filter for devices **Exclude filtered devices** set to device.isCompliant -eq True -and device.trustType -eq "ServerAD"

[learn-build-service-prod]

Learn Build status updates of commit 0fb29a9:

✅ Validation status: passed

File	Status	Preview URL	Details
docs/identity/conditional-access/policy-all-users-app-enforced-restrictions.md	✅Succeeded

For more details, please refer to the build report.

[prmerger-automator]

Invalid command: '#sign-off'. Only the assigned author of one or more file in this PR can sign off. @MicrosoftGuyJFlo

[Jhope188]

@MicrosoftGuyJFlo MicrosoftGuyJFlo are you able to review

[MicrosoftGuyJFlo]

Pending Ignite release branch merge on Tuesday. Will approve and sign off after merge.

[v-dirichards]

@MicrosoftGuyJFlo Are you waiting for something specific to merge first before this PR?

The PR review team will resume merging on the morning of the keynote address for the regularly scheduled daily publish cycles. If you sign off now, you don't need to take further action on this PR.

[nathanmcnulty]

App enforced restrictions already handles determining managed vs unmanaged without the need for Filter for devices, so this really shouldn't be necessary.

Having said that, it shouldn't hurt anything to use Filter for devices to exclude compliant or hybrid joined devices, but you might consider changing it to an OR instead of an AND to have it operate the same way as Exchange and SharePoint handle app enforced restrictions ;)

[Jhope188]

Really appreciate that. I didnt fully understand that the app control does determine managed vs unmanaged. That was where confusion on my part occurred. Ive also worked on the premise that the device filter to have it work. Thanks for the information Nathan. Appreciate that.

…

On Tue, Nov 18, 2025 at 12:18 AM Nathan McNulty ***@***.***> wrote: *nathanmcnulty* left a comment (MicrosoftDocs/entra-docs#1813) <#1813 (comment)> App enforced restrictions already handles determining managed vs unmanaged without the need for Filter for devices, so this really shouldn't be necessary. Having said that, it shouldn't hurt anything to use Filter for devices to exclude compliant or hybrid joined devices, but you might consider changing it to an OR instead of an AND to have it operate the same way as Exchange and SharePoint handle app enforced restrictions ;) — Reply to this email directly, view it on GitHub <#1813 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADJKRZ7GWBJWSA7A7ILSIR335LI4DAVCNFSM6AAAAACLIF4X3KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTKNBWGEYTCNZQGI> . You are receiving this because you were mentioned.Message ID: ***@***.***>

-- *Jon Hope* *804-467-5008*

[Jhope188]

App enforced restrictions already handles determining managed vs unmanaged without the need for Filter for devices, so this really shouldn't be necessary.

Having said that, it shouldn't hurt anything to use Filter for devices to exclude compliant or hybrid joined devices, but you might consider changing it to an OR instead of an AND to have it operate the same way as Exchange and SharePoint handle app enforced restrictions ;)

That makes complete sense Nathan. Thank you for clarifying some aspects of how that operates. I see similar policies that do the app enforced restriction but still do the device filtering. Which your point makes sense. Not sure if should include it in the KB or not by switching to an And vs Or. Curious your thoughts?

[MicrosoftGuyJFlo]

Thanks @nathanmcnulty. Agree with your points. I'd leave it out for now.

[Jhope188]

Sounds good, thanks!

…

On Thu, Nov 20, 2025 at 12:01 PM John Flores ***@***.***> wrote: *MicrosoftGuyJFlo* left a comment (MicrosoftDocs/entra-docs#1813) <#1813 (comment)> Thanks @nathanmcnulty <https://github.com/nathanmcnulty>. Agree with your points. I'd leave it out for now. — Reply to this email directly, view it on GitHub <#1813 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADJKRZYXC4DKJKM6NHNDVYT35YMZHAVCNFSM6AAAAACLIF4X3KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTKNJZHAYTCNJVGQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[nathanmcnulty]

App enforced restrictions already handles determining managed vs unmanaged without the need for Filter for devices, so this really shouldn't be necessary.
Having said that, it shouldn't hurt anything to use Filter for devices to exclude compliant or hybrid joined devices, but you might consider changing it to an OR instead of an AND to have it operate the same way as Exchange and SharePoint handle app enforced restrictions ;)

That makes complete sense Nathan. Thank you for clarifying some aspects of how that operates. I see similar policies that do the app enforced restriction but still do the device filtering. Which your point makes sense. Not sure if should include it in the KB or not by switching to an And vs Or. Curious your thoughts?

Sorry I missed finishing a reply to you on this!

You can certainly use filter for devices to make the decision at Conditional Access rather than passing the decision along to the resource (like EXO or SPO). I've been trying to think through if there are any risks or downsides of one way over the other, and assuming the filter in the CA policy is configured the same (using OR logic) as what the resource uses, I can't think of any meaningful difference. Biggest risk is honestly misconfiguring the filter to do something like selecting include instead of exclude and not apply at all :p

[Jhope188]

i Appreciate that Nathan. I can honestly say if you feel good about it i trust your expertise and definitely learned something in the process so I truly appreciate it. *Jon Hope* *804-467-5008*

…

On Sat, Nov 22, 2025 at 1:05 AM Nathan McNulty ***@***.***> wrote: *nathanmcnulty* left a comment (MicrosoftDocs/entra-docs#1813) <#1813 (comment)> App enforced restrictions already handles determining managed vs unmanaged without the need for Filter for devices, so this really shouldn't be necessary. Having said that, it shouldn't hurt anything to use Filter for devices to exclude compliant or hybrid joined devices, but you might consider changing it to an OR instead of an AND to have it operate the same way as Exchange and SharePoint handle app enforced restrictions ;) That makes complete sense Nathan. Thank you for clarifying some aspects of how that operates. I see similar policies that do the app enforced restriction but still do the device filtering. Which your point makes sense. Not sure if should include it in the KB or not by switching to an And vs Or. Curious your thoughts? Sorry I missed finishing a reply to you on this! You can certainly use filter for devices to make the decision at Conditional Access rather than passing the decision along to the resource (like EXO or SPO). I've been trying to think through if there are any risks or downsides of one way over the other, and assuming the filter in the CA policy is configured the same (using OR logic) as what the resource uses, I can't think of any meaningful difference. Biggest risk is honestly misconfiguring the filter to do something like selecting include instead of exclude and not apply at all :p — Reply to this email directly, view it on GitHub <#1813 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADJKRZYNS4IDH754MROX6XT3574JZAVCNFSM6AAAAACLIF4X3KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTKNRVG43TCNBZGY> . You are receiving this because you were mentioned.Message ID: ***@***.***>