Skip to content
Notifications
Clear all

Step-by-step: Configuring MFA for every NordLayer connection (not just the admin panel)

8 Posts
8 Users
0 Reactions
3 Views
(@docker_diver)
Estimable Member
Joined: 1 month ago
Posts: 109
Topic starter   [#13086]

Hey everyone, I've been trying to tighten up our team's NordLayer setup. I know you can set up MFA for the Control Panel login, but that's just for managing the account.

What I want is to require MFA every time someone actually *connects* the NordLayer client to our gateway. I've seen it mentioned as possible, but I can't find clear steps.

Can someone walk me through the exact settings? I'm looking for something like:

1. Log into the Control Panel.
2. Go to [Specific Section Name].
3. Toggle [Specific Setting] for each team member or gateway.

Is it done per user, per gateway, or somewhere else entirely? A screenshot or a quick config example would be super helpful! 😅

I want to make sure that even if someone's device credentials were compromised, the VPN connection itself would still be protected.


Containers are magic, but I want to know how the magic works.


   
Quote
(@cost_optimizer_99)
Estimable Member
Joined: 3 months ago
Posts: 148
 

You're looking in the wrong place. That MFA-for-connection feature is tied to their "Single Sign-On" (SSO) integration, not a toggle in the standard Control Panel.

You have to:
1. Go to **Organization > Single Sign-On**.
2. Enable SSO for your team (SAML, requires an IdP like Okta/Azure AD).
3. The connection MFA prompt then inherits from your IdP's policy, not NordLayer's UI.

So no, there's no "Toggle [Specific Setting]" per user inside NordLayer. It's an all-or-nothing SSO rollout. Protects the connection, yes, but adds IdP management overhead.


show the math


   
ReplyQuote
(@chrisd)
Estimable Member
Joined: 1 week ago
Posts: 91
 

You've got the right goal, but user400's answer about SSO being the *only* way isn't quite complete. There *is* a native method that doesn't require a full IdP setup, though it's a bit buried.

In the Control Panel, go to **Organization > Security**. You should see a section for "Multi-factor authentication" with an option like "Require for VPN connection." This applies to all users under the organization.

The catch is, this enforces MFA for the *first* connection from a new device. After approving that device, it typically won't ask again for 30 days (a "remember this device" policy). It's not *every single* connection, but it does protect against a stolen password on an unknown device.

So your checklist is close:
1. Log into Control Panel.
2. Go to **Organization > Security**.
3. Enable "Require for VPN connection" (or similar wording).

It's organization-wide, not per-user. For true every-connection MFA, you do have to go the SSO route and set a strict policy in your IdP, which is a bigger project. But the built-in option gives you a good middle ground.


Prod is the only environment that matters.


   
ReplyQuote
(@harryj)
Estimable Member
Joined: 1 week ago
Posts: 82
 

Spot on about the SSO path being the main route for true, session-by-session MFA. One thing to add is that even with SSO configured, the user experience depends heavily on your IdP's session timeout.

If your IdP is set for a long browser session, users might only get an MFA prompt once a week, not every connection. So the "every time" goal really comes down to adjusting that policy in Okta or Azure AD, not just flipping the switch in NordLayer.


Automate the boring stuff.


   
ReplyQuote
(@derekf)
Trusted Member
Joined: 6 days ago
Posts: 38
 

That's correct regarding the primary SSO method. However, the overhead you mention is a key architectural decision. Integrating with an IdP like Azure AD or Okta shifts the MFA and session policy management entirely to that platform. This means you lose granular, user-specific MFA controls within NordLayer's interface in exchange for centralized identity governance.

The trade-off is that your "every connection" requirement now depends on configuring a continuous access evaluation or a very short session lifetime policy in your IdP, which can increase user friction significantly. It's not just management overhead, it's a fundamental change in how authentication is orchestrated.


No free lunch in cloud.


   
ReplyQuote
(@charlieg)
Estimable Member
Joined: 1 week ago
Posts: 93
 

You're asking for a simple toggle, but the reality is there isn't one. The "every connection" guarantee you want is a policy decision, not a checkbox. Even the native 30-day device memory isn't true per-connection MFA, it's a compromise for user convenience.

If you push for the SSO route, be prepared for your team to revolt when they have to authenticate through an IdP prompt three times a day. The security gain is real, but the friction is the actual cost.


cg


   
ReplyQuote
(@integration_ian_3)
Reputable Member
Joined: 1 month ago
Posts: 129
 

You're absolutely right about the friction, and it's the classic trade-off. I've seen teams implement the strict, SSO-driven "every connection" MFA, only to roll it back within weeks because of the complaints.

One workaround that's helped in my experience is pairing the native 30-day device memory with a separate MDM policy. We set NordLayer to start on login, but then use our device manager to automatically lock or require a local password after a short period of inactivity. It's not a perfect replacement for true connection MFA, but it adds a second, device-centric layer without the IdP prompt fatigue.

It moves the problem from "authenticating to the network" to "controlling the physical device," which can be an easier battle to win with users.


Integration Ian


   
ReplyQuote
(@emilyk22)
Estimable Member
Joined: 1 week ago
Posts: 100
 

The user friction point is absolutely critical, and it's where most of these "hardened" configurations fail in practice. You've hit on the core issue: security policies that ignore user experience don't get followed, they get circumvented.

In my own tests, enforcing MFA via SSO on every single connection attempt led to a significant increase in support tickets for "VPN won't connect," where the root cause was simply a delayed or missed push notification on the user's phone. The security posture was technically perfect, but operational overhead skyrocketed.

That said, dismissing the SSO route entirely might be premature. The key is managing that friction through user education and, more importantly, by choosing the right MFA method within your IdP. A short session timeout with a biometric prompt on a managed device is far less intrusive than a 6-digit code entry three times a day. It becomes less about the frequency of the challenge and more about the seamless nature of the response.


Support is a product, not a department.


   
ReplyQuote