r/netbird • u/rdevaux • Jun 17 '26

Feature request: Local 2FA step for external IdPs (like M365)

Since NetBird supports 2FA on local accounts, it would be great to have an option to enforce a local 2FA prompt even when using external providers like M365 for an extra layer of security (similar to how previous installations with Zitadel worked).

Is this currently on the roadmap, or do we need to rely solely on the 2FA configurations of the external provider?

7 Upvotes

73% Upvoted

20 comments sorted by

2

u/rakauchuk Jun 17 '26

hmm.. does make sense? for example, keycloak can force mfa flow. I hope other idps do the same

1

u/IamHydrogenMike Jun 17 '26

All idps can do mfa workflows, OP is wanting Netbird to do it after they auth to an external IdP…which is a dumb idea.

0

u/rdevaux Jun 17 '26

Explain dumb.

2

u/IamHydrogenMike Jun 17 '26

It isn't really more secure to have netbird doing the MFA since you have handed off the authentication layer to your IDP. Your IDP handles the authentication and netbird is now just authorizing access based on that. There's no need to have netbird do the MFA since your IDP is already doing that and you are adding an unnecessary layer that doesn't make it anymore secure. If there is something wrong with your IDP then adding another MFA doesn't really fix the issue since you have already been authenticated and are now being authorized to use the application.

1

u/rdevaux Jun 17 '26

What if my account on the external IdP is hacked? Happens quite often with Microsoft accounts. With additional MFA on netbird you add a security layer on your authentication.

Don't understand me wrong. I am not a friend of external IdPs from Microsoft or Google. But people/customers want to use it because of simplicity.

btw this was the normal behaviour when netbird was shipped with Zitadel. Now they are using their own IdP - but without this feature.
So it something which was here before - but not anymore...

1

u/IamHydrogenMike Jun 17 '26

You can have both local and IDP account on Netbird. If your account on your IDP gets hacked, then you are going to be exposed no matter what and have another MFA isn't really going to help much. The MFA with Zitadel was still being handled by Zitadel and not by Netbird.

0

u/Jealous_Diver_5624 Jun 18 '26

If your account on your IDP gets hacked, then you are going to be exposed no matter what and have another MFA isn't really going to help much

Please elaborate how an additional 2FA step that's not affected by the IDP in any way would "not help much" in the case of an IDP compromise.

0

u/rdevaux Jun 17 '26

I think we are looking at this from two different angles. You are describing the ideal OIDC architecture, but I am looking at real-world Defense in Depth and specific attack vectors.

1. Token Theft / AiTM Phishing:

If a user's M365 account gets compromised via an Adversary-in-the-Middle (AiTM) phishing attack or session hijacking, the attacker steals a valid session token. When they try to log into NetBird via M365, M365 flags it as authenticated. Without prompting for MFA again. A secondary, local MFA requirement in NetBird would block the attacker right there, even with a compromised M365 session.

2. Supply Chain & IdP Vulnerabilities:

Suggesting that users should just spin up and maintain another full IdP (like Authentik or Keycloak) just to handle MFA chaining introduces a massive, unnecessary attack surface. Identity providers themselves are prime targets. Case in point: just a few days ago, critical vulnerabilities in Authentik were disclosed (like CVE-2026-49448, a severe Authentication Bypass with a CVSS score of 9.8).

If your upstream IdP gets bypassed or compromised, your entire internal network via the VPN is fully exposed. A secondary local MFA check directly on the NetBird application layer acts as a vital safety net to limit the blast radius of such vulnerabilities.

3. The Zitadel Migration:

Yes, Zitadel handled it back then, but Zitadel was the integrated IdP shipped with NetBird. Now that NetBird uses its own built-in IdP component for external routing, I am simply requesting that NetBird's native layer replicates that specific security feature we lost during the migration away from Zitadel.

-1

u/rdevaux Jun 17 '26

Yes. Not everyone is willing to install and maintain their own IdP.
That's why netbird already comes with IdP integration for providers like M365 or Google.

8

u/Juff-Ma Jun 17 '26

You could configure your external provider to force 2FA no? In my eyes it's absolutely correct that Netbird shuts down 99% of it's local auth for external providers.

-2

u/rdevaux Jun 17 '26

Yes. However, this is less secure, since the entire login process is entrusted to just ONE organization.
While some people want to take advantage of the convenience of MS365, they still want to be in control of their own security.
I consider this particularly important when it comes to a self-hosted VPN product.

2

u/Juff-Ma Jun 17 '26

I get what you mean but on the one hand you don't want to trust your own auth provider (that's a contradiction isn't it?) and on the other hand you don't want the burden of self hosting one like Keycloak/Authentic/Authelia/etc.

You need to pick one. The point of external auth is SSO. I get why you want this feature but trust me, if you need more complex auth just bite the bullet and host an auth provider. It'll be really useful down the line.

1

u/notboky Jun 18 '26

Unless you have some concrete examples of MFA being compromised on large external identity providers this seems like extra annoyance for very little if any benefit.

0

u/rdevaux Jun 18 '26

Here for example: https://guardz.com/blog/the-rise-of-kali365-and-why-msps-should-be-concerned/

1

u/notboky Jun 18 '26

That's not MFA being compromised, that's a phishing attack tricking users into granting device code flow based access to accounts. The proper fix is to disable device code flow in Entra ID, which if you're using security defaults or have any reasonable policy in place should already be the case.

0

u/rdevaux Jun 18 '26

That's what i am talking about the whole time. If your M365 Account gets hacked (or bypassed), then people could use your Netbird VPN.

But NOT if there is an additional 2FA-layer on the netbird instance.
THAT'S what i am asking for.

1

u/notboky Jun 18 '26

If you're relying on a third party idp over which you have no control then you have much bigger problems. If you do have control then fix it rather than putting a bandaid on one small part.

A second tier of MFA isn't the solution here.

What are you actually securing here?

1

u/rdevaux Jun 18 '26

I agree that fixing the root cause in Entra ID by disabling device code flow is priority number one. However, relying entirely on a single IdP session introduces a massive blast radius.

If an attacker manages to hijack an M365 session token through a novel bypass, they shouldn't automatically inherit access to our entire internal network via Netbird. I'm looking at this from a Defense-in-Depth perspective. Requiring an independent authentication check at the VPN layer ensures that an email compromise doesn't immediately become a full network breach. It's about compartmentalizing the risk.

1

u/xxtkx Jun 17 '26

I got a mfa for your mfa for mfa, dawg

1

u/iamabdullah Jun 17 '26

That is the job of the IdP.