A few days ago, Microsoft announced that Global Secure Access is now generally available. Since I have been working with the product for some time now and more and more proof of concepts are being launched, it is high time for me to do a blog series about it.
Here is an overview of the parts (planned so far):
In the overview to Global Secure Access, I particularly emphasized the good integration in Conditional Access for both Microsoft Entra Internet Access and Microsoft Entra Private Access. Accordingly, my first detailed blog in the Global Secure Access series also deals with this.
In this blog, we will first take a look at the Conditional Access controls introduced with Global Secure Access and the Global Secure Access-related resources.
After that, I will discuss a few use cases that result from Global Secure Access.
With Global Secure Access, Conditional Access has been enriched by several configuration elements, some of which can be integrated into the existing policies and some of which are necessary for new special policies.
Conditional Access can now use GSA as a Compliant Network Location Condition in policies.
On this occasion, the network-relevant conditions were also moved from the Conditions section to the first level of the policy.
Even if access to Entra ID integrated apps can then be linked to the use of GSA, Conditional Access cannot, of course, restrict access at network level. Instead, it only controls the issuing of OAuth2/SAML tokens. We are therefore not automatically protected against token replay by GSA, but are still dependent on features such as Continuous Access Evaluation and Token Protection.
<aside> 💡 The restriction to Compliant Network Control acts as a User Condition Change for CAE-capable applications and therefore forces instant re-authentication - so the combination of both features provides very effective protection against token replay!
</aside>
At the moment, the following conditions cannot be selected when GSA is selected as the target: