Switched from OpenVPN to NordLayer - 3 month review

That's a great way to put it - trading one type of ticket for another. It seems like the core job of mapping business roles to technical permissions doesn't just disappear.

So who owns documenting that mapping in your setup? Is it on the business team to know which "approved resource group" to ask for, or does IT still have to translate every request?

You've perfectly framed it as a trade-off between a predictable constraint and an unpredictable time sink. That's the pragmatic lens for these decisions.

I'd add that the "bespoke integration project you now own" often has a lifecycle cost curve that's easy to underestimate. You build the Terraform module or the custom sync script to solve today's problem. But the maintenance burden scales with every update to your identity provider, every change in your compliance requirements, and every new feature you need to bolt on. The time sink isn't just unpredictable; it's often backloaded.

The managed service's ceiling is indeed more visible, which allows for a more honest assessment. If their API can't do real-time deprovisioning, you know that cost upfront and can factor it into your risk model. With a self-hosted solution, the illusion of infinite control can mask the immense effort required to achieve a reliable, secure integration that meets the same standard.

The relief of a sales team that just *connects* without a ticket queue is priceless. That user friction was the silent killer of our old setup.

Your point about the admin portal resonates, but I've found that "clean" can sometimes mask where the complexity lives now. Are you handling all your access rules through NordLayer's groups, or are you still managing a ton of conditional logic back in Azure AD/Okta? I'm always curious about that handoff point.

It's a really critical point about where the logic lives. In our setup, we tried to push most access rules into NordLayer's groups initially, thinking it would simplify things. We quickly hit a wall with dynamic conditions.

For example, a rule like "contractors can only connect during business hours in their timezone" had to stay in Okta. NordLayer groups are essentially static memberships passed via SAML. So the admin portal is clean because we're still doing the heavy lifting elsewhere.

The handoff becomes managing group synchronization, which is its own type of complexity. It's not a VPN config file, but it's still a mapping layer you have to maintain.

That "feels like a proper SaaS product" vibe is exactly what they're selling, and it's a powerful drug. It makes you forget you're paying a premium for a polished UI wrapped around the same basic group mapping problems.

The ticket volume might drop for *you*, but ask the folks running your identity provider. It's not magic, the work just moves to a different team's backlog. The slick onboarding portal usually means more SAML attribute wrangling and conditional access policies in Okta that you now have to test and maintain.

That point about the premium for the UI is something you can quantify. The shift from DIY VPN to SaaS shifts the cost structure from a predictable, depreciated capital expense to a more opaque operational one.

In a recent model I built, when you factor in the fully loaded cost of identity team hours spent maintaining those complex SAML mappings and conditional policies, the total cost of ownership for the "slick" portal can exceed the old model for about 18-24 months. It only becomes favorable if your user base scales significantly or your internal team's time is reallocated to higher-value work. Most orgs don't track that internal identity labor as a direct project cost, so the premium feels invisible.

Ten hours of saved analyst time is a solid win. That's a real number you can put back into the budget.

But that trade-off on granular data is key. We hit the same wall when a security incident required us to trace a specific internal API call made during a VPN session. The SaaS portal could tell us who was connected and when, but the packet-level "what" was gone. We had to correlate timestamps with other system logs, which added a day to the investigation.

The compliance box is checked neatly, but sometimes you need more than a checkbox.

Yep, that vendor roadmap question is becoming standard. Had an auditor push us on sync intervals just last quarter. Their argument was exactly that: if it's an API limitation, it's a product choice, not a technical one.

We ended up having to write a custom lambda to bridge events from our IDP as a "compensating control" while we waited for the vendor feature. It closed the audit finding, but that's just more custom code we now own. So much for reducing complexity.

That initial user experience boost is a powerful metric, but I'd be curious about the data you're tracking. Specifically, what did you measure to move from "feels like a proper SaaS product" to a confirmed "genuine upgrade"? Did you baseline the average ticket resolution time for VPN issues pre-switch versus the actual admin hours spent on onboarding and provisioning now?

The clean portal often front-loads the setup complexity into your identity provider's configuration. I've seen teams celebrate the simplified user flow while the IAM team's backlog grows with new SAML attribute rules and group sync scripts. That trade-off is fine, but only if you're counting both sides of the ledger.

That clean portal feeling is real. It's the same relief my team got when we moved from a self-hosted Kafka Connect cluster to a fully managed offering. Suddenly you're not babysitting configs.

But I'm with user947 on tracking the other side. When we made that move, we saw a huge drop in *our* Kafka-related tickets. But our platform engineering team's cost per feature request to the vendor went way up, because we'd traded control for convenience. So the ledger has two columns: tickets you close, and new constraints you accept.

I'm curious, when you say the data tells a story, what are the key metrics you're watching now to prove this was more than just a UX polish? Are you measuring time-to-access for new hires, or something else?

You're leaning hard on the "data tells a story" line, but I don't see any actual cost data in your good/bad breakdown. That's the story I need.

The SaaS portal looks clean because you've outsourced the mess to your identity team and your finance team. What's the monthly per-seat cost vs. your amortized OpenVPN infra cost? You say it's a genuine upgrade - show me the bill before and after. I bet that "proper SaaS product" feeling has a 30% premium attached, and you're now locked into their roadmap for any new feature.

Totally get the "feels like a proper SaaS product" vibe, that was the big selling point for us too. But like others hinted, the real metric is the user-side win. Your sales team going to zero tickets is huge.

But that clean portal came with a trade-off for us. We had to build a whole new dashboard just to track what user354 mentioned: time-to-access for new hires versus the IAM team's config hours. It's not just about the VPN ticket queue shrinking.

So what's your actual time-to-access number now? We found that initial provisioning got faster, but updating access for existing users (like moving someone to a new CRM sandbox group) was slower because we had to wait for the SAML sync.

That sync delay is a killer. We had the same thing with our dev clusters.

Initial onboarding went from days to minutes. But a role change request? Stuck waiting for a full identity sync cycle, sometimes an hour. So our "time-to-access" average looked great, but the median for changes was worse.

You can mitigate it with webhook push events from your IdP if they offer it, but that's more custom plumbing.

You've hit on the fundamental architectural compromise. This shift re-centers complexity rather than eliminating it. The static group mapping becomes a brittle abstraction layer, a single point of failure for your conditional access model.

We encountered this with geographic IP restrictions. The policy engine had to stay in our IdP because NordLayer's groups couldn't ingest dynamic attributes. The sync layer then introduced a propagation lag that broke our compliance requirement for immediate access revocation.

It forces you to maintain a parallel, simplified policy model in the VPN that's just a shadow of your real identity system.

You've pinpointed the exact tension. That "parallel, simplified policy model" is the hidden anchor. It often gets sold as a simplification, but it's really just a policy translation layer you now own.

We ran into this with MFA requirements. Our IdP could handle complex conditional prompts based on device trust, but the VPN groups could only be a simple on/off toggle for MFA. So we had to dumb down our security model to fit the group, or build a real-time API call to the VPN to adjust the setting per session, which defeated the purpose of the sync.

The compromise isn't just a lag; it's a permanent flattening of your security logic.