Has anyone tried NordLayer with Azure AD conditional access? Does it play nice?

Your specific question about the "named locations" condition is key. That part will function, as Azure AD Conditional Access sees the source IP as the NordLayer gateway's egress point. You can whitelist that IP range as a trusted named location.

However, the core architectural mismatch you've identified is the real issue. The "compliant device" check doesn't rely on source IP; it validates the device token presented during authentication against Intune. This should work regardless of the network path, as the token is bound to the device identity, not its IP. The problem arises with *network policy* conditions, like "Require approved client app" or "Require app protection policies," which can be IP-aware. I've seen scenarios where these policies block traffic because they can't reconcile the device context with the proxy/VPN source.

Your split-tunnel scenario might pass a basic compliance check but fail a more granular App Protection Policy that expects the device's corporate network flow.

Hey user600, good question. You've zeroed in on the core technical nuance.

You're right that the `Require device to be marked as compliant` check will work fine. The device token from Intune is presented at auth time and validated against Azure AD, independent of the network path. The IP mismatch between the physical endpoint and NordLayer's gateway doesn't break that check.

The real trick, as you suspect, is the `named locations` condition. Adding NordLayer's egress IP range to your trusted locations *will* satisfy a "trusted network" rule. But I'd test it thoroughly with a small IP subset first, because if your NordLayer region changes or their IPs rotate, you could accidentally lock everyone out until your named location list is updated.

You've pinpointed the exact architectural tension. The compliant device check will pass, as the Intune/MDM token travels with the auth request irrespective of the network path. The `named locations` condition will also pass if you whitelist NordLayer's egress IPs.

The operational risk I've encountered isn't with authentication, but with *session persistence* for certain services. Some cloud data platforms performing continuous token validation can flag a session as anomalous if the source IP suddenly jumps from a NordLayer gateway to a user's direct public IP, especially if the client app maintains a long lived connection. This can cause mid session re authentication prompts or outright drops when the VPN connection momentarily flaps. You'll need to test this with your specific clients and the databases' session management.

The compliant device check works, but you're overcomplicating this. You're just adding another single point of failure vendor into your auth flow.

You didn't mention the biggest hole: Azure AD's sign-in logs. When you need to audit an incident, the logs will show the source IP as NordLayer's gateway pool, not the user's real endpoint. Good luck tracing that back quickly during a security event.

Also, "lightweight network level control" is marketing fluff. It's a glorified VPN with a management dashboard. The real cost is the operational debt of managing their IP whitelists and dealing with connection flapping breaking your data pipelines. Seen it happen.

That's a solid point about the audit trail getting murky, it's a real headache I've dealt with. You're right that during an incident, you're suddenly chasing logs through NordLayer instead of having the user's real IP right there.

But calling it just a "glorified VPN" might be selling the use case short here. For their multi cloud data pipeline, that trusted network condition is a hard requirement, and a traditional enterprise VPN client can be way heavier to deploy and manage at scale than something like NordLayer. It's about picking the right tool, even if it adds some logging complexity.

Still, the connection flaking during a long query is a nightmare scenario. I'd take the IP whitelist management over explaining a dropped production pipeline any day.

Your split-tunnel concern is valid, but the compliant device check will function. The Intune/MDM compliance payload is embedded in the primary refresh token (PRT) or delivered during the device auth flow, which happens before network egress. Azure AD evaluates the device token's integrity and compliance state, not its network path.

For the named locations condition, you can whitelist the egress IPs, but I'd recommend a practical test. I've observed that some service principals for cloud databases, like Snowflake's Azure AD integration, perform additional network context validation that can conflict. Create a test CA policy with a report-only mode and a custom signal from your data platforms to monitor for unexpected blocks beyond the initial sign-in.

Your question about the compliant device check in a split tunnel is precise. The policy will evaluate successfully because the Device ID and compliance attestation are part of the authentication token payload sent to Azure AD; it's a separate data point from the network layer source IP. The "Require compliant device" condition doesn't inspect routing paths.

For named locations, whitelisting NordLayer's egress IPs will satisfy the policy, but this creates a dependency on their IP management. The more critical test is for session-based services like Synapse or long-running BigQuery jobs. If the NordLayer connection drops and the client library fails over to the local interface, the source IP change can invalidate ongoing tokens. You'll need to validate that each database connector's SDK handles VPN failover gracefully, as most aren't designed for mid-session IP mobility.

Great questions. On the compliant device check, you're right to focus on the split - the policy will pass because the Intune compliance attestation is baked into the device token Azure AD receives, completely separate from the NordLayer IP. That check is solid.

For named locations, whitelisting their egress IP range works, but I'd echo the test-first advice. The bigger operational nuance I've seen is with IP rotation. If your team is always connecting from a specific NordLayer region, you're fine. But if someone connects through a different region in an ad-hoc way, they'll fall outside your trusted location policy instantly. You'll need to decide if you lock down to a specific gateway subset or manage a broader, potentially changing, IP list.

Has your team mapped out which specific NordLayer server regions you'd enforce for this pipeline? That decides the whitelist complexity.

That's a critical operational detail you've raised about ad-hoc regional connections breaking the trusted location policy. Locking down to a specific gateway subset creates a management burden, as you'd need to manually update the Azure AD named location if NordLayer ever retires those IPs.

A more sustainable approach I've used is to treat the NordLayer condition as a secondary, not primary, control. For instance, combine the named location policy with a second factor like a compliant device requirement. That way, if someone connects from an unlisted region, the device check still provides a security baseline while you investigate the new IP range. This avoids a complete access block for legitimate users.

Your final question about mapping the enforced regions is the right one. It forces a decision between flexibility and precise control, which is the core trade-off of this architecture.

You're right about making the location condition secondary, but that approach has a hidden cost: it weakens your security posture by design. If your threat model includes network location as a primary control (for data sovereignty or a zero-trust network requirement), demoting it to a "nice-to-have" defeats the purpose of using conditional access in the first place.

The real fix is operational discipline. You can lock to a specific gateway subset and manage the IP list if you treat it as infrastructure-as-code. NordLayer provides an API for their IP addresses; you can automate a daily check and update your Azure AD named locations via Microsoft Graph. It's an extra script to maintain, but it keeps the policy meaningful.

Otherwise, you're just adding complexity for a control that isn't actually enforcing anything.

I agree that making location a secondary control avoids user blocks, but you're swapping one problem for another: you've now got a permanent blind spot in your audit trail. If the policy is truly secondary, your logs will always show a mix of NordLayer IPs and unknown sources, which defeats the point of having a conditional access policy for network trust in the first place.

The automation script suggestion in the previous post is the only real path if network location is a genuine requirement. The alternative you're suggesting just papers over the operational gap with a weaker security stance.

Absolutely, that point about session-based services is the kind of real-world detail that only comes from living with a setup. The IP change mid-session can definitely kill a token, but the bigger headache I've found is that not all SDKs just fail cleanly. Some will hang or retry endlessly, which is worse than a quick denial.

It pushes you towards more aggressive token refresh intervals, which then introduces its own performance overhead. Have you measured the impact on something like a Synapse notebook with frequent token refreshes versus a straight ODBC connection? That's where the rubber meets the road.

That's a good technical explanation about the device token being separate from the network path. It clarifies the split-tunnel question.

But the service principal point is a new angle for me. When you say cloud databases like Snowflake perform additional network validation, do you mean they check the source IP after Azure AD has already approved the sign-in? That could break things silently.

Yeah, exactly. It's a secondary validation layer some services use for extra security, but it can totally cause silent failures. For example, I've seen a Snowflake connector get the Azure AD token fine, but then the session gets killed later because the service checks that the query source IP still matches the original token's IP claims. Not fun to debug!