When looking at security measures in Microsoft Entra ID environments, a common recommendation is to implement Conditional Access policies.
Whether Conditional Access is implemented can be quickly checked, and you can put a check mark next to it in your best-practice compliance form. However, simply implementing conditional access will not provide much security. A phishing attack that we recently analyzed highlights this very well.
The Phishing Attack
The employees of one of our clients received a wave of phishing emails. While most employees recognized the phishing emails as malicious, some clicked the links they contained.
The link led to a phishing site mimicking a login form for AD / mail credentials. After the users entered their credentials, it took only a few minutes before the attackers tried to actually use them. But they failed to log in. This was due to conditional access policies that prohibited logins from non-German IP addresses. In this case, the attackers’ IP was geolocated in Stockholm, Sweden.
Here, conditional access policies – at a first glance – seemed to have prevented the attack.
The Trustworthiness of IPs
Our client’s conditional access policies for Entra ID relied on the fact that it is a German company, operating in Germany. While MFA was enforced for all accounts in general, a conditional access policy deactivated MFA for all login attempts originating from German IPs.
After the attackers were not able to solve the MFA challenge, they switched IP addresses, tried again, and found a whitelisted (German) IP.
IP Geolocations
The attackers used several distinct IP ranges for their attack:
- 1 IP geolocated in Stockholm
- 1 IP geolocated in Toronto
- 25 IPs geolocated in Germany
The German IPs belonged to two AS and are likely backdoored server systems. They have a known bad reputation on VirusTotal. Interestingly, however, not surprisingly, the attack came only from IPv4 addresses.
Understanding Location Types
Before we dive deeper into best practices for Conditional Access and Network assignments, we must understand the building blocks Entra provides: Named Locations. The following different types exist:
- IP Ranges Location (IPv4 and IPv6): The most common approach is to define the organization’s corporate egress IP addresses. When setting these up, you define the network boundaries using CIDR notation.
- Countries Location: Sometimes, the exact IP address does not matter, but you care about the country from which access is made. Entra either determines geographic location by resolving the user’s public IP address against Microsoft’s internal mapping or by using GPS coordinates. GPS locations rely on the Microsoft Authenticator app and push notifications, which the user needs to accept before coordinates are shared.
After defining the Named Locations, either based on IP addresses or countries, they can be marked as trusted and then be used as either include or exclude conditions within Conditional Access policies. Such a condition can either target all Trusted Networks/Locations or only specific ones.
In addition to Named Locations, Microsoft introduced Global Secure Access (GSA) and Compliant Networks. When a GSA client is deployed on an endpoint, it can route traffic to Entra ID without the need for traditional VPNs or proxies with public IP addresses, which can then be added to Named Locations. Instead, the GSA client ascertains that the endpoint is part of a “compliant network”. More on that later.
Microsoft’s Stance on Network Assignments and Trusted Networks/Locations
If you have followed Microsoft’s documentation on Network assignments and Trusted Networks/Locations for a while, you might have seen a general change in their stance regarding the topic. For quite some time, Microsoft has stated that, even though you know the originating location during access, it shouldn’t be considered trustworthy and shouldn’t be excluded from any Conditional Access policies. In earlier versions of the documentation (which you can still find on GitHub), it was included as an explicit warning, but now it is completely removed and not mentioned at all. What remains is a note that Conditional Access is not intended as an organization’s front line of defense, as it is enforced after first-factor authentication and thus not effective against Denial-of-Service attacks. One might wonder if this was a deliberate change or just an oversight.
Even before the warning was removed, Microsoft deviated from this recommendation, as they have, for example, a Conditional Access policy template and policy recommendation for protecting the registration of security information by requiring multi-factor authentication. Definitely a good policy to have, but at the same time, the template also excludes all trusted locations. This effectively means that if you have the right IP address, you do not need to provide MFA when registering the first MFA method for a user account. So not that great of a recommendation after all.
Note: Microsoft makes this recommendation, so it applies to most businesses. If you require MFA to register the first MFA method, the question arises: how can this be done during a new employee’s onboarding? They receive a new user account with no MFA method registered, so how are they supposed to provide MFA when registering the first method? Kind of the chicken-or-the-egg problem. This is solved by providing Temporary Access Passes to users for the first sign-in. But this needs to be included in the organization’s onboarding process. Microsoft seems to assume that new users will be physically present at the organization’s (trusted) office during onboarding. Hence, they exclude these locations from the MFA requirement to not impact the business processes of their customers, but protect at least against attackers registering a MFA method on a new account from outside these offices, e.g., after a successful password spraying attack on a new user account (which potentially still has an easily guessable default password).
Now the big question is: can Network assignments and Trusted Networks/Locations even be used in a meaningful way to increase security?
Dos and Don’ts
First of all, and as an overarching recommendation, Network assignments in Conditional Access should never be used as the only line of defense when protecting resource access. This recommendation is part of the broader topic that essential security decisions should not be based on untrusted inputs, and it also applies to Conditional Access and Trusted Locations. Keep in mind that the following recommendations are meant as an addition to other best practices you should already be following. None of them replace general requirements such as MFA enforcement, the use of specific managed/compliant devices, or the evaluation of user/sign-in risk levels.
From our point of view, the following should be considered when using Trusted Networks/Locations:
The use case we see most often is the blocking of country-based locations that are not relevant to an organization. For example: Your business is based in Germany, and all employees work from Germany without any travel abroad, so you have a Conditional Access policy that blocks access from all locations, with an exclusion for a Trusted Location that covers Germany. While this is a perfectly reasonable thing to do, you must be aware of its limitations. As the described incident has shown, an attacker with valid credentials could easily iterate through IP addresses from different countries to find one that is not blocked. Does this make such a policy obsolete? We would say no, as it could still limit the use of stolen credentials if an attacker is not too persistent, or at the very least slow down the attack so that other security mechanisms might kick in first. After all, remember that this should not be your only line of defense.
When an organization has users traveling abroad, the way of thinking should also be adjusted: instead of removing the access block completely, additional security controls should be layered on top of the already existing requirements for all users. This could mean that access is only possible if a phishing-resistant MFA method is provided (e.g., a FIDO2 security key) or access must take place from a compliant or at least managed device. While this is, of course, not a silver bullet, as it still relies on IP addresses or GPS locations, it can deter some attackers and trigger other security controls, such as sign-in risk detection in Entra Identity Protection.
A variant of the country-based approach that we also see quite often is the blocking of all access except for IP-address-based Trusted Locations that cover all office locations. Compared to country-based locations, this is much better suited for restricting resource access, as an attacker cannot easily use, for example, public VPN services to obtain an allow-listed IP address, but must access the corporate network (even if only via VPN). But this approach comes with its own set of challenges. On the operational side, you must keep the IP address ranges up to date and maintain them regularly to prevent gaps or overblocking, as well as ensure that no publicly accessible networks (e.g., your public Wi-Fi) connect to the Internet via the same IP address as your office networks, which could be exploited by an attacker. The management also becomes more complicated if you route users’ Internet access through a cloud proxy (like Zscaler or Prisma Access), as you must define IP address ranges as trusted that you do not control at all, and that could be poorly defined, too broad, or shared between multiple customers. Even if you have tight control over your office networks and Trusted Locations, the risk remains that one of the devices on your corporate network is already compromised and can be used for code execution and thus for reusing stolen credentials. And this does not have to be a sufficiently secure endpoint with hardening and monitoring; it could be any device (e.g., an IoT device) as long as it has Internet access and connects to Entra ID via a public IP address that has been defined as trusted. And again, the only way to protect against this is to combine the Network assignment with other measures, such as MFA enforcement and device status checks.
dsadas
With that, we also come to the most often seen misconfiguration: using Trusted Locations to completely bypass MFA (or other essential requirements) by excluding all Trusted Locations from the general MFA enforcement. For some inexplicable reason, it is common practice to assume that a device is suddenly more secure just because it is in a “trusted” network. If an attacker has valid credentials and compromises a device within the corporate network or one that can connect to the corporate network via VPN, they gain immediate, unfettered access to cloud resources. Our recommendation in this scenario is pretty simple: do not do that! Of course, we are also aware of the operational realities and the struggles that come with broad MFA adoption in large enterprises. In our experience, there will always be arguments against MFA and some forms of exceptions. In such cases, and if the reasoning is user comfort, the better approach would be to use Conditional Access session controls and the sign-in frequency to define how often a user needs to re-authenticate, and with that provide MFA within the corporate network and outside the corporate network (e.g., 7 days within a corporate network vs. 8 hours outside a corporate network). In all other cases, it is never a good idea to reduce security standards based on a user’s network location, as a compromise may already have occurred.
However, there is one scenario where we actually recommend allowing actions from a defined network location. If you need a device code authentication flow (Teams-enabled conference room systems might use this), it is recommended to block this flow for all locations and exclude trusted locations. Conditional Access will use the attacker’s (the phisher’s) IP address for policy evaluation. This control, however, must be combined with a second policy that limits device code flow to defined user accounts (Scope: All Users, with dedicated exceptions for users who require Device Code Authentication). Without a second policy, all users would be susceptible to Device Code Phishing attacks from attackers that already have a foothold in the company network.
A Peek at the Future of Trusted Networks/Locations
As more organizations move away from funneling all user traffic through VPNs and corporate proxies, it becomes harder to define what qualifies as a Trusted Location. Combined with the aforementioned management overhead and limitations of IP-address-based Network assignments, we must look at alternative ways to prevent malicious access to Cloud resources.
Also, for now, we have only discussed stolen credentials that can be used for initial authentication, but we have ignored tokens issued afterward. Once a user is successfully authenticated at a trusted network location, a corresponding claim is added to the issued Refresh Tokens and Access Tokens. If these tokens are stolen, they can be used from arbitrary network locations, even though the tokens claim the user is still at a Trusted Location. For Access Tokens, this can be mitigated by Continuous Access Evaluation (CAE), which allows resource providers to reject access tokens if the source IP address changes within a session. However, only first-party Microsoft applications are CAE-capable, and exceptions for IP address variations must be explicitly turned off. For Refresh Tokens, there is no similar mechanism.
This is the moment where the previously mentioned Global Secure Access (GSA) and Compliant Networks come into play. GSA serves as Microsoft’s Security Service Edge (SSE). It acts as the unified, cloud-delivered gateway for an organization’s traffic, encompassing both Entra Internet Access and Entra Private Access. The GSA Client (installed on the user’s endpoint) intercepts traffic destined for Microsoft 365, SaaS applications, or internal private resources. Rather than routing directly over the open Internet, the intercepted traffic is forwarded to Microsoft’s global edge network. As traffic enters the GSA infrastructure, it is logically bound to a specific Entra ID tenant. A “Compliant Network” in the context of Conditional Access is not a physical network subnet or a range of IP addresses. In the Entra ecosystem, a Compliant Network is a metadata signal generated by the GSA edge and consumed by Entra ID.
Enabling GSA signaling establishes a continuous communication bridge between the GSA edge and Entra ID authentication servers. When a user attempts to authenticate to a resource, the GSA edge signals network location information during the authentication flow. This information is used as proof that the request successfully passed through a specific tenant’s GSA infrastructure. Entra ID automatically translates this signal into a dynamic Named Location called “All Compliant Network locations.” This removes the administrative overhead of managing and updating lists of egress IP addresses. Also, the big difference compared to Trusted Networks/Locations is that the Compliant Network information is not derived from the user’s token and included claims, but from the GSA edge signaling that Entra ID receives and checks when applying Conditional Access.
To enforce these restrictions in Entra ID, a Conditional Access policy that requires the Compliant Network signal must be configured. The policy would cover all users and all resources (except Microsoft Intune Enrollment and Microsoft Intune), provided that “Any location” is included and “All Compliant Network locations” is excluded. The grant access controls would be set to “Block Access”. With this setup, token theft and replay of the Refresh Token or a session cookie from any device other than the user’s device where the GSA client is actively running is impaired, as all Access Token requests that come from the open Internet instead of the tenant’s GSA infrastructure are immediately dropped due to the missing Compliant Network information signaling. Unless the attacker directly compromises the user’s device, stolen tokens cannot be successfully replayed from external networks. For Access Tokens, the primary protection mechanism remains CAE, as they are presented directly to the application rather than Entra ID, so no Compliant Network signaling check occurs. In any case, the attacker would still be limited by the token’s 60 to 90-minute lifetime.
If you want to learn more about best practices surrounding Conditional Access, as well as how to secure Entra ID in general, do not miss out on ERNW’s 2-day “Entra ID Security Essentials” training hosted at this year’s TROOPERS conference.