This is an established space, with provides like Okta, Teleport, JumpCloud, and even Microsoft Entra ID. Most of those options have fewer barriers of protection as it's simpler, which leads to better security and reliability in practice.
Your target audience is likely companies running old-school, legacy Microsoft installations. These tend to be on-prem for the reasons you list.
The problem, though, is if these companies want a VPN, they already have it. You'll have to convince them that the VPN they've been using for decades is insecure (it's not).
----
Lastly, at a technical level, I'm not entirely sure what you achieve by requiring user/pass+yubikey on multiple layers of the stack. You don't gain any additional technical protection (since L3 would wrap everything else) while still having a single point of failure.
> You don't gain any additional technical protection
There is strong value in security in layers. While VPN access requires remote users to have a hardware key, internal VMs may need a file based pre-shared key/certificate. If an attacker somehow manages to gain VPN access without a hardware key, they’d still either need a hardware key or they’d have to additionally comprise the TLS PKI be able to complete an mTLS connection to an app. Checking the hardware key on the way up the stack keeps an attacker on the VPN from having a privileged position.
But if an attacker can breach your VPN, why would they not be simultaneously breaching all other layers of the stack?
Running the same, breached check in multiple places doesn’t make anything more secure, it simply runs a vulnerable check more.
——
Layers do add to security, but the argument here is that you’re adding more doors to a bank vault while completely ignoring they all open with the same key.
I think your analogy is flawed. You assume that any attacker that breaches a layer of defense will do so by breaking the encryption or by stealing the key, but that doesn't have to be the case.
In your analogy of the bank robbers, the robbers might exploit a weakness in an exterior wall, and gain entrance to the lobby. The other locked doors will still prevent them from robbing the vault.
Let’s say an attacker compromises a machine that was joined to the mesh network via a pre shared key file (not a hardware key). The attacker still doesn’t posses a hardware key, so the higher level checks are still valuable.
Another way to put it is, that attacker is walking a part of the vault floor, but still doesn’t have keys to the lockboxes.
What you’re describing is simply multi-factor authentication.
What I’m focused on is the repeated authentication on multiple layers of the network stack. It just isn’t necessary. Either your authentication mechanisms work at the lowest level, or they’re broken across the entire stack.
Your target audience is likely companies running old-school, legacy Microsoft installations. These tend to be on-prem for the reasons you list.
The problem, though, is if these companies want a VPN, they already have it. You'll have to convince them that the VPN they've been using for decades is insecure (it's not).
----
Lastly, at a technical level, I'm not entirely sure what you achieve by requiring user/pass+yubikey on multiple layers of the stack. You don't gain any additional technical protection (since L3 would wrap everything else) while still having a single point of failure.