1 \u2013 Block or protect specific Access to specific App with ConditionalAccess Policy<\/u><\/strong><\/h4>\nUpon integrating a third-party application into the Entra ID Tenant, we followed the consent procedure as outlined by the software provider. The objective was to restrict access to the application and its data under specific conditions, such as when the accessing user is not within the office. To achieve this, ConditionalAccess is used to restrict access to the application from Trusted Networks (could be also Global Secure Access):<\/p>\n
![\"\"](\"https:\/\/msb365.abstergo.ch\/wp-content\/uploads\/2025\/01\/Hilpi3.png\")
<\/p>\n
\u00a0<\/p>\n
The access to the app was not blocked as expected and when checking the SignIn-Logs
\nthe App is \u2018not included\u2019 even if in the policy configuration it is:<\/p>\n
![\"\"](\"https:\/\/msb365.abstergo.ch\/wp-content\/uploads\/2025\/01\/Hilpi4.png\")
<\/p>\n
According to the article mentioned above, this could be interpreted as expected behaviour. Conditional Access is designed to protect resources (APIs) that are integrated with Entra ID and not applications. In this instance, since the user is not accessing any resources beyond the excluded scopes, Conditional Access policies are not enforced.<\/p>\n
It seems thatConditional Access cannot enforce controls<\/strong> for certain specific applications when no resources or only excluded resources within Microsoft 365 are used, such as when Entra ID is used as an Identity Provider.<\/p>\nUntil recently, it was generally understood that Conditional Access is applied to the applications in the Tenant and not just the resources behind them. Not sure if the renaming from \u201cAll cloud apps\u201d to \u201cAll resources\u201d was to address those wrong assumptions or if it was more than just a simple renaming and the policy enforcement behaviour changed.<\/p>\n
Following this finding, it is advisable to verify whether any application is protected with MFA or compliant device enforcement with CA-Policies targeted to all applications.<\/p>\n
\u00a0<\/p>\n
2 \u2013 Protect all Applications with ConditionalAccess<\/u><\/strong><\/h4>\nUpon further inspection, it is observed that not all authentications to an application connected to Entra ID are consistently protected by Conditional Access Policies, even when these policies are targeted to \u201cAll resources\u201d (previously referred to as \u2018All cloud apps\u2019). In some instances, access was granted without requiring a compliant device or multi-factor authentication (MFA).<\/p>\n
A closer analysis revealed that Conditional Access policies may exclude specific applications for various reasons, such as the exclusion of any resource from a policy.<\/p>\n
To illustrate this, a standard policy was created targeting all resources and client app types, necessitating either a compliant device, app protection, or MFA. The policy excludes one target resource, in this case \u201cReport phishing\u201d, but it could be ANY<\/strong> Resource<\/strong>.<\/p>\nThis discrepancy highlights the necessity for thorough verification of Conditional Access policies, ensuring that applications expected to be protected are indeed subject to the intended security measures.<\/p>\n
![\"\"](\"https:\/\/msb365.abstergo.ch\/wp-content\/uploads\/2025\/01\/Hilpi5.png\")
<\/p>\n
\u00a0<\/p>\n
The Policy can have different user assignments, conditions or grant controls, the behaviour stays the same.<\/p>\n
The application used in this tests has three platforms configurations for authentication:<\/p>\n
![\"\"](\"https:\/\/msb365.abstergo.ch\/wp-content\/uploads\/2025\/01\/Hilpi6.png\")
<\/p>\n
\u00a0<\/p>\n
\u00a0<\/p>\n
Upon conducting the tests, it was anticipated that the Conditional Access policy would uniformly enforce multi-factor authentication (MFA) or require a compliant device\/app for all authentication attempts. However, analysis revealed inconsistencies. Specifically, during two out of three authentication attempts, an authorization code was obtained and utilized with single-factor authentication, bypassing the expected MFA challenges or device compliance requirements.<\/p>\n
When analysing the SignIn Logs, the App assignment is not matched and the App shows up as \u201cApp excluded\u201d for these authentications.<\/p>\n
\n\n\nApplication platform<\/strong><\/td>\nResult<\/strong><\/td>\nReason<\/strong><\/td>\n<\/tr>\n\nMobile and desktop applications<\/strong><\/td>\n| CA Policy not applied<\/td>\n | App excluded<\/td>\n<\/tr>\n | \nSingle-page application<\/strong><\/td>\n| CA Policy not applied<\/td>\n | App excluded<\/td>\n<\/tr>\n | \nWeb<\/strong><\/td>\n| Require multifactor authentication<\/td>\n | All apps included<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n \u00a0<\/p>\n ![\"\"](\"https:\/\/msb365.abstergo.ch\/wp-content\/uploads\/2025\/01\/Hilpi7.png\") <\/p>\n
\u00a0<\/p>\n \u00a0<\/p>\n The only request, where the Policy was enforced correctly, requiring MFA was the one to the Web platform:<\/p>\n ![\"\"](\"https:\/\/msb365.abstergo.ch\/wp-content\/uploads\/2025\/01\/Hilpi8.png\") <\/p>\n
\u00a0<\/p>\n When testing further, the excluded resources where excluded, so that the CA policy now appears as follows:<\/p>\n ![\"\"](\"https:\/\/msb365.abstergo.ch\/wp-content\/uploads\/2025\/01\/Hilpi9.png\") <\/p>\n
\u00a0<\/p>\n When making the identical authentication requests as before the results are different, but finally as expected:<\/p>\n \n\n\nApplication platform<\/strong><\/td>\nResult<\/strong><\/td>\nReason<\/strong><\/td>\n<\/tr>\n\nMobile and desktop applications<\/strong><\/td>\n| Require multifactor authentication<\/td>\n | All apps included<\/td>\n<\/tr>\n | \nSingle-page application<\/strong><\/td>\n| Require multifactor authentication<\/td>\n | All apps included<\/td>\n<\/tr>\n | \nWeb<\/strong><\/td>\n| Require multifactor authentication<\/td>\n | All apps included<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n \u00a0<\/p>\n After that result I did other tests, excluding completely random Apps from the policy, getting always the same result: the Policy is applied only to the Web platform, not covering \u201cSingle-page application\u201d & \u201cMobile apps and desktop clients\u201d authentication platform.<\/p>\n Further tests where done, excluding completely random applications from the policy, which repeatedly yielded the same result: The policy consistently applies only to the Web platform, while it does not cover the \u201cSingle-page application\u201d (SPA) and \u201cMobile apps and desktop clients\u201d authentication platforms.<\/p>\n \u00a0<\/p>\n Conclusion<\/strong><\/h3>\nThis inconsistency poses a significant challenge for ensuring the security of applications, especially for third-party integrations where Entra ID is used as Idp.<\/p>\n The consequence of this behavior extend to Zero Trust and Secure Access Service Edge (SASE) implementations. Until an app is configured with the platform \u201cMobile and desktop applications\u201d or \u201cSPA\u201d and doesn\u2019t access other resources within Microsoft 365, ConditionalAccess is not enforcing controls such as compliant devices, networks (including GSA), or even blocking specific users from accessing certain apps. This limitation undermines the effectiveness of Zero Trust and SASE strategies, which rely on robust access controls to secure applications and data.<\/p>\n \u00a0<\/p>\n Author<\/strong><\/h3>\n![\"\"](\"https:\/\/msb365.abstergo.ch\/wp-content\/uploads\/2025\/01\/Hilpi_.png\") <\/p>\n
\u00a0<\/p>\n","protected":false},"excerpt":{"rendered":" Recently, an unexpected problem popped up with some ConditionalAccess policies: it is not possible to enforce controls. Applications show up as \u2018excluded\u2019 from the targeted resources when ConditionalAccess policies are evaluated. This behaviour allows users to access resources without MFA or compliant devices. This is possible for Applications which use Entra ID as Idp or […]<\/p>\n","protected":false},"author":1,"featured_media":5781,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_crdt_document":"","om_disable_all_campaigns":false,"_monsterinsights_skip_tracking":false,"_monsterinsights_sitenote_active":false,"_monsterinsights_sitenote_note":"","_monsterinsights_sitenote_category":0,"_uf_show_specific_survey":0,"_uf_disable_surveys":false,"footnotes":""},"categories":[12,1923],"tags":[1773,2003,2000,2004],"class_list":["post-5780","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-azure","category-microsoft-365","tag-azure","tag-conditionalaccess","tag-entraid","tag-microsoft365"],"post_mailing_queue_ids":[],"_links":{"self":[{"href":"https:\/\/www.msb365.blog\/index.php?rest_route=\/wp\/v2\/posts\/5780","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.msb365.blog\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.msb365.blog\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.msb365.blog\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.msb365.blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=5780"}],"version-history":[{"count":12,"href":"https:\/\/www.msb365.blog\/index.php?rest_route=\/wp\/v2\/posts\/5780\/revisions"}],"predecessor-version":[{"id":5809,"href":"https:\/\/www.msb365.blog\/index.php?rest_route=\/wp\/v2\/posts\/5780\/revisions\/5809"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.msb365.blog\/index.php?rest_route=\/wp\/v2\/media\/5781"}],"wp:attachment":[{"href":"https:\/\/www.msb365.blog\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=5780"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.msb365.blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=5780"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.msb365.blog\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=5780"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}} | | | | | | | | | | | | | |
![](\"https:\/\/learn.microsoft.com\/en-us\/media\/open-graph-image.png\")
<\/div><\/div>![\"\"](\"https:\/\/msb365.abstergo.ch\/wp-content\/uploads\/2025\/01\/Hilpi1.png\")
<\/p>\n![](\"https:\/\/devblogs.microsoft.com\/identity\/wp-content\/uploads\/sites\/74\/2023\/10\/developer_screens.png\")
<\/div><\/div>![\"\"](\"https:\/\/msb365.abstergo.ch\/wp-content\/uploads\/2025\/01\/Hilpi2.png\")
<\/p>\n