Zero-Trust Architecture: Sovereign On-Premises Implementation Guide

Zero-trust architecture is a security model that eliminates implicit trust from network design and replaces it with continuous, explicit verification of every identity, device and connection before any resource is accessed. Codified in NIST SP 800-207, the model rests on three principles: never trust and always verify, enforce least privilege at every layer, and assume that a breach has already occurred. For European organisations in regulated sectors, applying these principles to sovereign on-premises or Swiss-hosted infrastructure is not a theoretical exercise; it is a direct response to the credential-theft epidemiology and lateral-movement speeds that make perimeter-based defences untenable.

Core Principles and Their Specific Meaning in a Sovereign Deployment

The three zero-trust principles translate directly into architectural decisions that differ meaningfully when the deployment must remain under exclusive European or Swiss jurisdiction.

Never trust, always verify means that no session is permitted on the basis of network location alone. In a sovereign on-premises deployment, this requires an identity provider (IdP) that itself runs on-premises or in a jurisdictionally controlled environment, not a US-based SaaS IdP subject to the CLOUD Act. Every access request, whether from a staff member opening a file share or a microservice calling an internal API, must present a verifiable claim that is evaluated in real time by a policy enforcement point (PEP) under the organisation’s own control.

Least privilege means that an authorised session grants access only to the specific resource required for the task, for the minimum duration necessary. In practice this means replacing broad role assignments with fine-grained, attribute-based access control (ABAC) policies that evaluate job function, data classification, device health and time of day simultaneously.

Assume breach means designing containment into the architecture before any incident occurs. Micro-segmentation ensures that a compromised workstation in the finance department cannot reach clinical records, source code repositories or HR systems, regardless of what credentials the attacker holds. This principle is architecturally incompatible with a flat internal network, which is why zero-trust and traditional perimeter security cannot meaningfully coexist without one undermining the other.

Identity and Access Management Across Sovereign and Non-Sovereign Segments

Zero-trust fundamentally reframes identity as the new perimeter, and this has concrete implications when an organisation operates across network segments with different sovereignty profiles.

Internal employees, external contractors and machine identities (service accounts, APIs, CI/CD pipelines) must all authenticate through the same policy engine, but the claims they can present differ. Human users in a sovereign deployment should authenticate using FIDO2 / WebAuthn hardware tokens, which bind the credential to a physical device and produce a phishing-resistant assertion that cannot be intercepted and replayed across network segments. Contractors operating from non-sovereign networks present a higher-risk context; the policy engine should respond by demanding stronger device posture evidence and issuing shorter-lived session tokens with narrower scope than it would grant to an on-premises employee on a managed device.

API-to-API authentication is handled through mutual TLS (mTLS), where both the calling service and the receiving service present X.509 certificates issued by a certificate authority under the organisation’s control. This eliminates the shared-secret anti-pattern (API keys stored in environment variables) and creates a cryptographically verifiable audit trail of which service called which endpoint, when, and with which certificate. In a sovereign deployment, the CA infrastructure must itself be hosted on-premises or in a controlled environment; using a public cloud-hosted CA would reintroduce the jurisdictional exposure the sovereign architecture is designed to eliminate.

Essential Technical Controls and How They Are Audited

A sovereign zero-trust workspace requires four technical control layers working together. Each layer must produce structured, tamper-evident logs that can be presented to regulators.

Micro-segmentation

Micro-segmentation divides the internal network into workload-level zones with explicit allow-lists governing east-west traffic. In practice this is implemented through software-defined networking policies or host-based firewalls managed by a central policy engine. Every attempted connection that is denied because it crosses a segment boundary is logged with the source identity, destination, timestamp and policy rule that triggered the denial. This log stream is the primary evidence that the “assume breach” principle is operationally active.

Device posture checks

Before granting a session, the PEP evaluates the requesting device against a minimum security baseline: operating system patch level, endpoint detection and response (EDR) agent status, disk encryption state, and certificate validity. A device that fails posture is either denied access entirely or directed to a quarantine segment with remediation resources only. The posture check result and the policy decision are logged per session, creating an auditable record that access was only granted to compliant devices.

Continuous session verification

Authentication at session initiation is necessary but not sufficient. NIST SP 800-207 requires that trust be re-evaluated continuously during a session, not only at login. Short-lived tokens with automatic re-authentication, combined with behavioural anomaly detection (unusual data volumes, access to resources not previously accessed, access at unusual hours), allow the policy engine to revoke an active session without waiting for the next login event.

Producing Audit Evidence for NIS-2 Article 21 and DORA Article 9

Regulatory compliance under these frameworks is not satisfied by architecture diagrams; it requires demonstrable, time-stamped evidence that controls were operative at the moment of any given access event.

NIS-2 Article 21 requires essential and important entities to implement measures covering access control, multi-factor authentication, encryption and supply chain security. As the legislative text states directly: “Member States shall ensure that essential and important entities take appropriate and proportionate technical and organisational measures to manage the risks posed to the security of network and information systems.” A zero-trust architecture addresses the access control and MFA requirements directly, but the audit obligation means the organisation must be able to produce, for any access event in the preceding audit window, a log entry showing: which identity authenticated, which device was used, what posture check result was recorded, which resource was accessed and which policy rule authorised the access.

DORA Article 9 requires financial entities to maintain ICT security policies that are reviewed, tested and documented. The specific zero-trust contribution here is the policy-as-code model: access control rules written as machine-readable policies (in frameworks such as Open Policy Agent) are simultaneously the operational control and the policy documentation. A version-controlled policy repository, with change history and approval workflows, satisfies the “documented and reviewed” requirement without requiring a separate manual policy document that diverges from operational reality.

ZTNA Versus VPN: Blast Radius When Credentials Are Compromised

The practical difference between a perimeter VPN and Zero Trust Network Access (ZTNA) becomes most visible at the moment credentials are stolen, which, according to the IBM Cost of a Data Breach Report 2023, costs organisations an average of USD 4.45 million per incident.

In a VPN model, a valid credential grants the authenticated session membership of the internal network. The network is typically flat or only coarsely segmented, which means the attacker can enumerate all reachable hosts, pivot laterally at will, and escalate privileges using credentials cached on other machines. The CrowdStrike Global Threat Report 2024 found that the median attacker breakout time from initial access to lateral movement was 62 minutes. A flat VPN-protected network gives the attacker 62 minutes to reach any system on the internal network before most security operations centres detect the intrusion.

In a ZTNA model, a valid credential grants access only to the specific application or resource the policy engine has authorised for that identity, device and context, and nothing else. An attacker who steals a contractor’s FIDO2 token and manages to authenticate still cannot reach any resource the contractor’s policy does not explicitly permit. They cannot enumerate the internal network topology because they have no network-layer access to it. Micro-segmentation means that even a fully compromised endpoint cannot initiate connections to other segments without passing a new policy evaluation. The blast radius is bounded by policy, not by the attacker’s initiative.

This architectural difference is why NIST SP 800-207 describes zero-trust as a shift “from a network-centric to a data-centric security model.” As Scott Rose and co-authors write in SP 800-207: “Zero trust is not a product or a service; it is a strategy built on the assumption that no user, device, or network segment is inherently trustworthy, even inside the perimeter.” For sovereign on-premises deployments, where the consequence of a breach may include regulatory sanction, reputational damage and the exposure of data that cannot be disclosed to foreign jurisdictions, that architectural discipline is not optional.

Frequently Asked Questions

Does zero-trust architecture require replacing all existing on-premises infrastructure?

No. NIST SP 800-207 explicitly describes zero-trust as an architectural strategy that can be layered onto existing environments through policy enforcement points and identity-aware proxies, rather than a wholesale infrastructure replacement. Most sovereign on-premises deployments introduce zero-trust controls incrementally, starting with identity, device posture and micro-segmentation.

How does zero-trust interact with GDPR data residency requirements?

Zero-trust does not move data; it controls access to data. When the policy enforcement points, identity providers and logging infrastructure are hosted within the EU or in a jurisdiction with adequate protection (such as Switzerland under the revised FADP), zero-trust strengthens GDPR compliance by ensuring that every access event is authenticated, authorised and logged without routing data through foreign cloud services.

Can contractors and API integrations be brought into a zero-trust sovereign model without giving them broad network access?

Yes, and this is one of zero-trust’s primary advantages. Contractors authenticate via FIDO2-compliant tokens and receive time-limited, scope-limited session tokens that grant access only to specific services. APIs authenticate via mutual TLS (mTLS) certificates rather than shared secrets, and every API call is authorised by a policy engine that checks the calling service’s identity and the sensitivity of the requested resource.

What does NIS-2 Article 21 specifically require that zero-trust controls satisfy?

Article 21 requires entities to implement measures covering access control, multi-factor authentication, encryption and supply chain security, as well as policies for vulnerability handling and incident response. A documented zero-trust implementation with continuous session verification, device posture logging and micro-segmentation directly addresses the access control, authentication and network security sub-requirements, and the associated audit logs provide the evidence regulators expect during supervisory review.

Is ZTNA only relevant for remote workers, or does it apply to on-premises users too?

ZTNA applies to all users regardless of physical location. On-premises employees present the same identity and device posture claims as remote workers, because zero-trust explicitly rejects the notion that physical presence on a corporate network confers trust. This is especially important for insider threat scenarios and for containing lateral movement after a workstation is compromised inside the building.