Common use case
Keep private access under European operational control
Data residency says where systems run. Digital sovereignty also asks who operates them, holds the keys, and can be compelled to provide access.
Short answer
Self-host the WireZTNA control plane, broker, publishers, logs, and key material on premises or with a provider selected by your organisation. This reduces mandatory third-party control, but the legal outcome still depends on the complete deployment and supplier chain.
The problem
Keeping data in an EU region does not by itself settle jurisdiction or control. A foreign-controlled provider may remain subject to third-country access requirements, while a mandatory SaaS access layer can expose identities, policies, network topology, logs, or keys to another operator. European rules and procurement frameworks increasingly expect organisations to understand and reduce that exposure.
Choose and scope the connection model
WireZTNA is self-hosted and cloud-agnostic. The organisation chooses where the control plane, broker, DNS, and publishers run, who administers them, and where keys, logs, and backups remain. This supports a sovereign architecture without claiming that software alone grants legal compliance or certification.
- 1Define the jurisdictional boundary and review providers, parent companies, subprocessors, support access, and data flows.
- 2Deploy the control plane, broker, DNS, and publishers on premises or on selected European or qualified infrastructure.
- 3Keep administrative access, WireGuard keys, session material, logs, and backups under the organisation's governance.
- 4Document access policies, supplier exit plans, update paths, and the controls required by the applicable regulatory framework.
Example access flow
Control plane
Customer-operated in the chosen jurisdiction
Private connectivity
Broker and publishers on selected infrastructureKey and log custody
Retained under customer governanceMandatory external control plane
None for core operation
When this pattern fits
- Public-sector or regulated procurement requires control beyond simple EU data residency.
- Financial, healthcare, industrial, or critical-infrastructure workloads need an auditable private-access layer.
- A European cloud provider or MSP wants to operate ZTNA without delegating its control plane to another SaaS vendor.
- An organisation wants portability across on-premises, European cloud, and hybrid environments.
Security boundary and limitations
- Self-hosting reduces third-party control but does not by itself establish GDPR, EU Data Act, DORA, NIS2, SecNumCloud, or other legal compliance.
- Using a US-controlled hyperscaler, subprocessor, remote support service, or external key system may preserve third-country exposure even when the region is in Europe.
- Assess the whole system, including identity, application credentials, monitoring, backups, DNS, updates, support, and the destination services themselves.
Frequently asked questions
Is hosting in an EU data centre enough for digital sovereignty?+
No. Location matters, but ownership, jurisdiction, operational access, key custody, support, and subprocessors also determine who can control or disclose data.
Does WireZTNA guarantee protection from the CLOUD Act or FISA Section 702?+
No product can make that universal guarantee. WireZTNA can operate without a mandatory foreign SaaS control plane, reducing one source of exposure; the remaining legal position depends on the entities, infrastructure, services, and access arrangements selected.
Does deploying WireZTNA automatically make an environment SecNumCloud-qualified?+
No. SecNumCloud qualifies cloud service offerings and their operators, not an isolated software component. WireZTNA can be deployed as part of an architecture using appropriately qualified infrastructure and assessed controls.