Let's get this out of the way: calling NordLayer a "zero-trust network access" solution is like calling a moat around a castle "zero-trust." It's a perimeter, just a slightly more flexible one. It's a VPN with a nicer UI and an API. That's fine, but don't confuse it with the actual principles of zero-trust.
We used it as a rapid-response band-aid when we needed to lock down access to a legacy admin interface that couldn't be easily refactored. The promise was quick team onboarding and IP-based allow-listing. The reality? It solved the immediate problem while creating a tangle of long-term issues. You're still managing a *network* perimeter, just now it's defined by who's in your NordLayer team. The moment you need service-to-service auth, device posture checks, or granular application-level policies (not just "this IP can access this port"), you hit a wall. You've just moved the problem.
The config for their "service" tokens feels like a throwback to the age of static credentials. It's a secret you bake into your automation, which then grants *network-level* access. Hardly a recipe for least privilege.
```yaml
# Example: Their 'machine authentication' for CI/CD
nordlayer connect --token ${NORDLAYER_SERVICE_TOKEN} --group prod-us-app
# Congrats, your runner now has full IP-based access to everything in 'prod-us-app'.
# One leaked token = perimeter breach.
```
The real irony? It can actively delay a proper zero-trust migration. It "works" just well enough that the business sees the problem as solved, draining the urgency to implement true identity-aware proxies or fine-grained service meshes. You end up with a hybrid monster: new services on proper ZTNA, legacy stuff hanging off the NordLayer gateway, with confusing routing rules between them.
It's a decent stopgap for human access to legacy systems. But if your roadmap says "zero-trust" and your tool is NordLayer, you've misunderstood the destination. You've bought a better drawbridge, not a system of continuous verification.
Exactly. It's the classic trap of using a tool that fits your immediate technical constraint but does nothing for the architectural shift. You end up with the same perimeter mindset, just with a new set of config files to manage.
That "band-aid" phase is where it gets you. The quick win feels good, but then you're six months in with a dozen of these service tokens floating around, and you realize you've built a shadow IT network. Revoking access means hunting down secrets instead of flipping an identity policy.
I've seen teams try to stretch it by adding a proxy in front of the legacy app, but then you're just layering workarounds. At that point, you've spent more effort duct-taping than you would have on a real ZTNA pilot.
> the quick win feels good
That's the sales pitch, right there. The pressure to ship something, anything, that looks secure. So you slap on NordLayer, tell the auditors "we have ZTNA", and move on. The technical debt accrues quietly.
The real cost isn't the monthly fee, it's the team's time. Every hour you spend onboarding a new service token or debugging a split tunnel is an hour you're not putting into a real identity-aware proxy or proper service mesh. It's a tax on your future velocity.
You end up with two perimeters to manage: the old one you pretended to leave, and this new, slightly shinier one. Double the fun when something breaks.
If it ain't broke, don't 'upgrade' it.