Most enterprise networks still operate on a fundamental assumption that anything inside the perimeter can be trusted. That assumption collapsed years ago, and NIS2 and DORA have now codified its replacement in law. Zero-trust network access is no longer an architectural aspiration: for European enterprises in finance, energy, healthcare, and critical infrastructure, it is a compliance baseline. The question is not whether to implement it, but how to do it on infrastructure that actually meets European sovereignty requirements.
This guide works through the architecture decisions that matter in practice, the trade-offs that vendor marketing glosses over, and where ZTNA implementation on sovereign European cloud infrastructure differs from the generic hyperscaler playbook.
What ZTNA actually means, and what it does not
NIST SP 800-207 defines zero trust as “an evolving set of cybersecurity paradigms that move defenses from static, network-based perimeters to focus on users, assets, and resources.” Zero Trust Architecture (ZTA) is the overarching framework; Zero Trust Network Access (ZTNA) is the network-layer application of those principles, specifically the enforcement of identity-based access control for every connection to every resource.
The distinction matters because ZTNA is not a product you buy. It is a set of architectural decisions: where you enforce policy, how you evaluate trust continuously, how granularly you segment your network, and how you handle privileged access. A vendor selling you a “zero trust solution” is selling one component of that architecture, not the architecture itself.
The four principles that should drive every decision are: never trust, always verify (every request is treated as originating from an untrusted network, regardless of source); least privilege access (users and systems get only what they need for the specific task, in the specific context, at that specific moment); microsegmentation (network segments are as granular as operationally feasible, containing lateral movement when a breach occurs); and continuous monitoring and validation (trust is evaluated continuously, not assumed to persist after initial authentication).
The regulatory floor: NIS2 and DORA requirements for access control
NIS2 Article 21 mandates access control measures including multi-factor authentication for all entities in scope. The directive explicitly names MFA and continuous authentication solutions as requirements, and directly addresses lateral movement prevention as part of its technical and organisational measures. Penalties for essential entities reach €10 million or 2% of global annual turnover. The directive entered application in October 2024, though transposition is still incomplete in several member states including Germany and France.
DORA, which entered application on 17 January 2025, goes further for financial entities. Article 9 requires documented information security policies, access controls, strong authentication for remote and privileged access, and patch management. Article 10 requires anomaly detection and user behaviour monitoring. DORA’s Regulatory Technical Standards require strong authentication for any access to ICT assets supporting critical functions or publicly accessible systems. DORA operates as lex specialis for financial services, so financial entities complying with DORA satisfy NIS2 ICT security obligations simultaneously.
The architecture that satisfies NIS2 and DORA is not a compliance overlay on top of your existing network. It is a network redesigned around the assumption that the perimeter does not exist.
Practically, both regulations point to the same set of technical controls: MFA everywhere, least-privilege access enforced at the resource level, microsegmentation to contain lateral movement, continuous monitoring of user and system behaviour, and privileged access management for administrative functions.
Core architecture decisions
Identity as the control plane
In a ZTNA architecture, identity replaces network location as the primary trust signal. Every access request carries identity context: who is requesting, from what device, in what state, for what resource, and under what conditions. Your identity provider becomes load-bearing infrastructure, not an authentication convenience.
This has concrete implications. Your IdP needs to be highly available across the regions where your workloads run. It needs to integrate with your cloud IAM layer, your on-premises directory, and your endpoint management platform. Single sign-on is not optional: it is the mechanism through which continuous authentication is operationally sustainable. We run SSO and IAM as a managed product precisely because identity infrastructure that is bolted on after the fact creates the gaps that ZTNA is designed to close.
Microsegmentation: where the real work is
Microsegmentation is the most labour-intensive part of any ZTNA implementation, and the part most often underestimated. The goal is to reduce the blast radius of a compromised credential or workload by ensuring that lateral movement between segments requires explicit authorisation, not just network reachability.
On cloud infrastructure, microsegmentation is implemented at several layers simultaneously:
- Network layer: security groups and network ACLs enforced at the hypervisor, not at a perimeter firewall. Traffic between workloads in the same virtual network should be denied by default and permitted only by explicit rule.
- Application layer: service meshes or application-aware proxies that enforce policy based on service identity, not IP address. IP-based rules do not survive container orchestration at scale.
- Data layer: encryption at rest and in transit, with key management that is separate from the workload. AES-256 for data at rest, TLS 1.3 for data in transit, and centralised key management that does not live on the same infrastructure as the data it protects.
The operational trade-off is real: more granular segmentation means more policy surface to manage. Start with your most critical assets, map their legitimate communication paths, and enforce deny-by-default. Expand outward. Attempting to microsegment everything simultaneously is how ZTNA projects stall.
VPN replacement versus VPN augmentation
ZTNA is often positioned as a VPN replacement. The reality is more nuanced. VPNs grant network-level access; ZTNA grants application-level access based on identity and context. For most enterprises, a phased approach works better: ZTNA for application access, with VPN retained only for legacy systems that cannot support application-layer policy enforcement, and a roadmap to eliminate those dependencies.
The practical difference matters for DORA-regulated entities in particular. DORA’s RTS requires strong authentication for remote access to the financial entity’s network. A VPN with MFA satisfies the authentication requirement but does nothing about lateral movement once the tunnel is established. ZTNA with per-application access control satisfies both the authentication and the containment requirements.
Sovereign infrastructure as an architecture requirement, not a compliance checkbox
ZTNA on infrastructure subject to non-European jurisdiction creates a structural problem. Your identity plane, your policy enforcement points, and your monitoring data are all sensitive. If your ZTNA vendor’s control plane sits outside Europe, or if your cloud provider is subject to foreign government access orders, your zero-trust architecture has a trust boundary you did not design.
We operate our infrastructure across MAD1 in Madrid, MUC1 in Munich, and HEL1 in Helsinki, all under European law, with no foreign parent company. Our direct peering with AWS, Azure, GCP, and Cloudflare at all sites means that hybrid architectures, where some workloads remain on hyperscalers during migration, do not require traffic to leave European infrastructure to reach European policy enforcement points. The policy plane and the data plane stay on the same side of the Atlantic.
For finance and critical infrastructure teams implementing ZTNA under DORA and NIS2, that is not a marketing point. It is an architecture requirement that determines whether your access control model is actually closed.
Implementation sequencing that works
- Inventory your access paths. You cannot enforce least privilege on access paths you have not mapped. Start with privileged access and remote access to critical systems.
- Enforce MFA universally. This is the minimum bar for NIS2 and DORA compliance and the foundation for everything else.
- Deploy identity-aware proxies for critical applications. Replace direct network access with application-level access control for your highest-risk systems first.
- Implement deny-by-default segmentation for critical workloads. Map legitimate traffic, write explicit permit rules, enforce deny-by-default, and monitor for violations.
- Instrument everything for continuous monitoring. DORA Article 10 requires anomaly detection and user behaviour monitoring. Your segmentation and access control generate the events; your SIEM needs to consume them.
Zero trust is not a state you reach. It is an operational posture you maintain. The architecture decisions above create the conditions for it; the monitoring and iteration sustain it.
