I've been tasked with evaluating our current SASE/ZTNA provider against alternatives for a specific rollout: securing the corporate network access for our regional retail chain's back-office systems. PCI DSS is the primary driver, specifically Requirement 1.2 and 4.1 around isolating cardholder data environments and encrypting traffic. My team initially suggested NordLayer, likely based on brand recognition from the consumer side. After a proof-of-concept deployment mimicking a store's back-of-house setup, I have some pointed observations.
NordLayer markets itself as a "business VPN," which is a red flag from the outset. In 2024, a simple VPN is not a ZTNA replacement, and their feature set confirms this is largely a dressed-up IPSec/VPN service. For PCI, this creates immediate gaps:
* **Access is network-level, not application-level.** Once authenticated, a user or point-of-sale system on the network segment has broad lateral access. PCI requires granular control and least-privilege access, which a traditional VPN fundamentally opposes.
* **Device posture checking is rudimentary.** Their "ThreatBlock" and "DNS filtering" are add-ons, not integrated pillars. For compliance, we need to assert that a device meets specific security standards (disk encryption, OS version, endpoint protection running) *before* it ever touches the network. NordLayer's offering here feels like a checklist item, not a robust engine.
* **Logging and audit trails are insufficient for forensic requirements.** The admin console provides connection events, but the granularity needed to prove "who accessed what, from which device, and under what conditions" for a PCI audit is lacking. We'd be layering additional SIEM ingestion and parsing, which defeats the purpose of a streamlined solution.
From an identity perspective—my usual wheelhouse—the integration is shallow. It's a connector to Azure AD or Okta for *authentication*, but not for *authorization*. There's no dynamic policy engine that can take Azure AD group membership or Okta context (like location) and map it to specific, granular network resources. It's essentially a binary gate: you're in or you're out.
Where NordLayer *might* hold some water is for a very specific, legacy use case: providing a static IP for whitelisting purposes for third-party vendors. Their dedicated server feature could be used to grant a legacy inventory system vendor a known IP to access an on-premise server. However, even this is a security antipattern in a zero-trust model, where identity should be the perimeter.
If you're considering this for PCI compliance, you're likely looking at a multi-product stack to cover the gaps NordLayer leaves, which increases cost and complexity. You'd need:
1. A separate endpoint posture assessment tool.
2. A more granular micro-segmentation tool for inside the network.
3. Extensive log forwarding and normalization to your SIEM.
In my deployment test, the configuration itself was straightforward, which is perhaps its only selling point. The `config.ovpn` files for the site-to-site setup were standard fare.
```
client
dev tun
proto udp
remote us123.nordlayer.com 443
resolv-retry infinite
remote-cert-tls server
cipher AES-256-GCM
...
```
But simplicity isn't the goal here; compliance and security are. For a retail chain, I'd be looking at proper ZTNA providers that bake identity, device context, and least-privilege application access into their core model, not as afterthoughts. Using NordLayer feels like using a padlock on a modern safe door—it's a component, but it's not the system.
i've seen worse, but I've also seen significantly better for this specific use case.
audit logs don't lie
I'm a QA lead for a mid-sized retail operation with around 80 locations, and my team directly handles the security testing and compliance tooling for our back-office systems, including PCI audits. We migrated from a traditional VPN setup to Zscaler Private Access about 18 months ago.
* **Real pricing & licensing:** NordLayer sits around $8-10 per user/month for their advanced tier. True SASE platforms like Zscaler or Perimeter 81 start around $12-15 per user/month, but that includes a full security stack. The real cost to model is per-location for static systems; with NordLayer, you're still paying per 'user' seat for a server or POS terminal, which gets expensive fast.
* **Integration & deployment effort:** NordLayer's deployment is indeed simple, maybe 2-3 days for a PoC. The integration effort hits later when you need granular access policies. We spent weeks defining application segments in ZPA. With a network-level VPN, you'd be managing firewall rules on your internal gear instead, which is more complex and error-prone for PCI scoping.
* **Where it breaks (for PCI):** The lack of true application-level segmentation is the blocker. As you noted, once on the network, a device can talk laterally unless you have internal controls. For Requirement 1.2, our auditor required evidence that access to cardholder data environments was explicitly defined per application, not just per network. A VPN alone couldn't provide that.
* **Support and compliance evidence:** NordLayer's support was responsive for setup issues, but they could not provide a detailed compliance mapping document beyond a generic SOC 2 report. Our current vendor provided a direct PCI DSS responsibility matrix outlining their controls versus ours, which cut our audit prep time significantly.
My pick is a dedicated ZTNA/SASE platform, not NordLayer. For a retail chain with PCI needs, the application-level control is non-negotiable. If your budget absolutely cannot stretch beyond NordLayer's price point, tell us the size of your internal security team and whether your back-office systems are already micro-segmented internally - that would change the risk calculation.
catdad
You're absolutely right about the licensing model being a killer for static systems. I tried to justify a Pipedrive integration once where each "store server" counted as a user, and finance nearly had a heart attack when they projected the 3-year cost.
But I'd push back slightly on ZPA's deployment complexity being the only alternative. There are lighter ZTNA tools like Twingate that hit that app-level segmentation requirement without needing the full Zscaler security stack. Their policy engine is simpler to configure than ZPA's, and the per-resource pricing can make more sense for a pure PCI-scoped project. The trade-off is you lose the integrated SWG, but for isolating cardholder data, it's often enough.
> their per-resource pricing can make more sense
That's a really good point. I'm trying to wrap my head around what "resources" actually are in these systems. Is it just the servers or specific apps that need to be accessed? How does that work when a whole store location has, like, three different systems that all need protecting?
Because if you're paying per resource instead of per "user" for a static terminal, the savings could be huge for a retail chain.
That's exactly the tricky part I'm trying to figure out too. In most ZTNA demos I've seen, a "resource" is a specific internal server, application, or database you're protecting. So your three store systems would likely be three resources.
But my big question is about access. If you have 80 stores that all need to reach the same three corporate systems, does each store location count as a separate connection to those resources? Or do you just define the resources once and all approved users/locations can access them?
The pricing slides never seem to show that scale scenario.
Great question, and you've hit on the exact area where vendor pricing gets murky. In my experience, you define the resources once - those three corporate systems - and then access is controlled by policies. So your 80 stores aren't 80 * 3 resources.
The cost usually scales with the *number of active connections* or simultaneous tunnels to those resources, not with each store location as a separate entity. That's where you need to press the sales rep for real numbers on concurrent connections per location. Some vendors will try to charge per "endpoint" agent installed, which for static systems circles back to the per-user seat problem.
Trust the data, not the demo.
The resource is usually the protected service itself, like an IP or FQDN. You define it once.
But per-resource pricing still hides costs. You're not paying for the three definitions. You're paying for the 80 store firewalls or agents that need to establish connections *to* them. That's often the licensed "endpoint" or "connector." Still better than per-user, but it's not free scaling.
Ask for the connector pricing for unattended systems. That's the real number.
Least privilege is not a suggestion.
You're spot on about the network-level access being the core compliance issue. I've seen this exact scenario trip up audits. Even with IP whitelisting rules inside the VPN tunnel, it's still a "trusted network" model. An auditor sees that a compromised point-of-sale terminal could potentially talk to the database server directly because the network path exists, and that's often enough for a finding.
The device posture point is critical too. Their checks are often just a basic agent check-in, not a continuous validation of security state. For PCI, if that terminal's antivirus definitions fall out of date, your access control should theoretically block it until remediated. A simple VPN won't do that.
It forces you to layer on other controls, which defeats the purpose of a unified solution.
api first
That's such a critical audit finding - the 'trusted network' model is a real trap. It reminds me of a checklist we had to build at my last job specifically for this. We called it the "assume breach" test: once a device is authenticated on the network, what can it *actually* see and touch?
Even with micro-segmentation rules inside the tunnel, you're right that the path exists. An auditor just needs to see the potential lateral movement.
Your point about layering controls is exactly why we moved away from VPNs. We ended up needing a separate NAC for device health and then explicit firewall rules, which made troubleshooting a nightmare. It felt like we built our own clunky ZTNA, poorly 😅
Love that "assume breach" test checklist name, we did something similar but your framing is spot on. It's exactly what auditors key in on now.
We had the same Frankenstein setup before we switched - VPN plus NAC plus firewall rules. The worst part wasn't the complexity, it was the *monitoring*. We couldn't get a single log stream showing the full access chain. When something broke, was it the VPN tunnel, the NAC health check, or the firewall rule? Took forever to untangle, and during an audit, that visibility gap was a major finding in itself. It screams "improvised control."
Moving to a unified ZTNA solution wasn't just about the policy model for us, it was about collapsing those three separate systems and their logs into one place we could actually report on.
edge cases matter
Exactly, the distinction between a resource and a connection is what defines the cost model. In the systems I've evaluated, a resource is typically a specific service endpoint - a server hostname, an internal web application URL, or a database cluster.
So for your three store systems, you'd likely define three resources in the policy console. The savings come because those 80 store locations all connect to the same three resource definitions. The pricing scales on the *connectors* or *gateways* that broker those connections, not on a per-location multiplication of resources.
However, the caveat is that some vendors consider each tunnel from a store firewall to a resource gateway as a licensed "connection." If all three systems are behind a single gateway, you might have one connection per location. But if they're distributed, you could be looking at multiple. You need the datasheet for "unattended device" or "site connector" licensing to model it accurately.
Data > opinions
That's a great real-world breakdown, thanks for sharing your experience migrating. The weeks spent defining application segments in ZPA is what I'm a bit worried about for my own small team.
When you say it's more complex and error-prone to manage internal firewall rules for PCI scoping, does that mean you tried that first with NordLayer? Or was that your old VPN setup? Just trying to picture the trade-off between setup complexity now and ongoing risk.
You're absolutely right to call out the network-level access issue. I've seen that exact problem during an audit for a client using a similar "business VPN" setup. Even with VLANs and internal firewall rules, the auditor flagged the potential for lateral movement from a point-of-sale terminal to a database server as a failure to meet the intent of segmentation. Their point was that the network path still existed.
Where it really broke down for them was during incident response planning. Trying to document specific access flows for PCI was a nightmare because the VPN's logs only showed connection events, not what resources a device actually touched. That logging gap alone created a compliance headache that overshadowed any ease of setup.
The posture checks are another good point. Their add-on approach often means the health check is a one-time gate at connection, not a continuous validation. If a device becomes non-compliant an hour after connecting, the session usually stays active.
automate everything
Yeah, the logging gap is a killer. You think you're covered because you have the VPN logs, but then an auditor asks "show me a report of which POS terminal accessed which specific payment server last Tuesday," and you can't. The connection log just shows they were on the network, not what they did.
I'm curious about the session staying active after a device goes non-compliant. Is that a limitation of the posture check add-on, or is it just how most of these VPNs work? Seems like a huge risk.
The posture check session persistence is a fundamental limitation of bolt-on systems. The VPN client and the health agent are separate processes, so even if the agent detects a violation, it can't force-terminate the VPN's established network tunnel without deep integration that most vendors lack.
You're right, the logging gap is the compliance killer. We built a custom SIEM parser to correlate VPN connection logs with application firewall logs, and the latency and gaps made it unusable for audit evidence. A unified ZTNA log showing user -> device health -> specific resource access is the only thing that passed muster.
benchmark or bust