If you’ve ever sat through an Entra ID review, you’ve heard it. “Have you turned on Conditional Access?” Tick. Next item.
We picked apart a phishing job that showed how thin that comfort blanket can be. The policies were there. They even stopped the first try. Then, a couple of minutes later, the attackers were in mailboxes — reading, changing and deleting mail like they owned the joint.
The emails that almost didn’t work
Staff at one of our clients copped a wave of phishing emails. Most people clocked them. A few clicked. The page looked like a normal login. They typed in their details. Minutes later the attackers tried those credentials and bounced. Conditional Access was blocking logins from outside Australia. First IP sat in Singapore. Looked like a win. One minutes later they were in the first mailbox.
How they walked around the gate
The client is an Australian outfit that mostly works in Australia. MFA was on for everyone… except when the login came from an Australian IP. That one policy quietly switched MFA off for anything that looked local. So the attackers changed address. Tried again from IPs Entra thought were Australian. One of them was on the allow list.
In they went
They used a handful of ranges: one in Singapore, one in London, and a stack in Australia. Those Aussie addresses looked like compromised servers. VirusTotal already had them flagged. All IPv4. They didn’t need to be brilliant. They just needed an IP the policy trusted.
What “location” actually means
Named Locations come in two main flavours. IP ranges — you list the organisation’s egress addresses and call that home. Country locations — Entra looks up the public IP, or uses GPS if the user accepts an Authenticator prompt. Mark them trusted, then include or exclude them in policies. Microsoft has also added Global Secure Access and Compliant Networks. The GSA client can send traffic through Microsoft’s edge instead of a public IP you have to babysit. Worth knowing about later. Microsoft’s advice has gone a bit quiet. For years the docs said: even if you know where the request is coming from, don’t treat that location as trustworthy and don’t exclude it from Conditional Access. That warning used to be explicit. Now it’s gone. Their own templates don’t always follow the old line either. The policy that protects security-info registration requires MFA… then excludes trusted locations. Right IP, no extra proof. New starters make that messy — Temporary Access Passes are the proper fix — but it’s still a soft spot.
Can you use trusted locations without shooting yourself in the foot?
Yes. As one layer. Never the only one. Blocking countries you never use isn’t stupid. Australian company, everyone works here, no travel? Block everywhere except Australia. A determined attacker will just cycle IPs until one gets through — we just watched that — but it can slow them down. Other controls then get a look in. If people travel, don’t just turn the block off. Stack extra requirements: phishing-resistant MFA or a compliant device. Still not perfect, but it raises the bar.
Tighter is allowing only office IPs rather than a whole country. An attacker can’t just fire up a public VPN and look local. The catch is keeping those ranges current, making sure guest Wi-Fi isn’t sharing the same egress, and remembering that any compromised box already on that network can reuse stolen credentials from a “trusted” address. The worst habit we see is using trusted locations to switch MFA off completely.
“It’s on the corporate network, so it must be safe.”
That’s how someone with creds and a foothold walks straight into the cloud. Don’t do it. If the real fight is user friction, use sign-in frequency instead. MFA every seven days on the office network, every eight hours everywhere else. At least you’re not dropping the actual bar. One exception that does make sense: device-code flow (some Teams room systems). Block it everywhere, allow it only from trusted locations, and limit it to the accounts that actually need it. Otherwise anyone inside the network can get phished with a device-code attack.
Where this is heading
Fewer shops want all traffic hairpinned through VPNs. Listing trusted IPs gets harder and less useful. There’s another gap. Once someone authenticates from a trusted location, that claim lands in the tokens. Steal the tokens and you can use them from anywhere. Continuous Access Evaluation can help with access tokens on first-party Microsoft apps. Refresh tokens have no equivalent. That’s where GSA and Compliant Networks get interesting. A Compliant Network isn’t a subnet. It’s a live signal from Microsoft’s edge: this request came through our pipe. Replay a stolen refresh token from some other machine on the open internet and it fails, unless the attacker has the actual device with the GSA client running. Conditional Access is useful. It is not a force field. Treat location as one signal among many, keep MFA and device checks on, and stop giving “local” IPs a free pass. Otherwise you’re just training attackers to shop around for an Australian address.