Services without exposed ports: Embedded Zero Trust

Cybersecurity · October 2026 · 7 min read

By Arturo Navarro · 15 October 2026

A service that listens on no port cannot be scanned. That is the idea that separates Zero Trust embedded in the application from the network layers placed around an open port: the service publishes none and exists only for the identities a policy authorises. For a financial entity the shift has two measurable consequences: there is less surface to defend, and the question "who can reach this service" is answered by reading a policy, which is how Delegated Regulation (EU) 2024/1774 asks for it to be demonstrated.

The exposed surface starts at an open port

The core, internal APIs and administration consoles listen on a port reachable from some network. The firewall decides which addresses reach that port; the application then decides who gets in. Between the two layers, rules pile up with every integration, alongside supplier exceptions and legacy ranges nobody dares to close.

An open port answers before authentication. The TLS or HTTP server behind it processes data from anyone who reaches it, authorised or not, and a vulnerability in that layer is exploitable without credentials. Being inside the internal network is enough to find it.

Regulation already puts a price on that surface. Article 13 of Delegated Regulation (EU) 2024/1774, which develops the DORA ICT risk management framework, requires documenting all network connections and data flows (point (b)) and, for systems supporting critical or important functions, verifying the adequacy of firewall rules and connection filters at least every six months. The effort of that review grows with the number of rules.

From perimeter to identity, and from network to application

Moving access control from the IP address to the identity is not enough to close the port: where that control lives matters too. OpenZiti, the open protocol this approach is built on, distinguishes three deployment models that can coexist in the same network:

Where the control lives	Code changes	What stays exposed	Trust boundary
Network: overlay router in a trusted zone	None	The service still listens on the private network, behind the router	The network zone
Host: tunneler next to the service	None	The service only accepts connections from localhost	The host operating system
Application: SDK inside the process	Yes	No listening port, not even on localhost	The process itself

The application model is the strictest: cryptographic identity and encryption live inside the service process, not in a separate component someone has to remember to configure correctly.

A service with no inbound ports

With the SDK embedded, the service does not wait for connections. It opens outbound connections to the overlay routers and registers as the host of a named service. A client, which also has its own identity, requests a session for that service; the controller checks the policy; the overlay joins both ends with mutual authentication and end-to-end encryption.

In practice, a scan from the internet or from the internal network does not find the service because nothing is listening. A compromised machine inside the network gains no reach by being inside: without an authorised identity, the service does not exist for it.

What does not change deserves the same clarity. The service needs outbound access to the overlay routers. The existing network and segmentation stay in place, and flaws in application logic remain reachable by authorised identities. Embedded control reduces who can get there; it does not fix what happens next.

Access control inside the application

For a CTO, the exposed-surface conversation stops being a list of ports, rules and exceptions and becomes a list of identities and the services each one can reach:

One identity per service and per client, backed by a certificate, instead of an IP address shared by many processes.
Central policy, deny by default: who may connect to a service and who may host it are controller data, not rules scattered across firewalls.
Revocation in one place: withdrawing an identity or a policy is applied in the control plane, without touching network equipment.

The cost is in the code: embedding the SDK means modifying the service. For what cannot be touched, the host model with a tunneler provides the same identity-based access without code changes, with the trust boundary at the operating system.

An open protocol: OpenZiti

OpenZiti is open-source software under the Apache 2.0 licence, created and sponsored by NetFoundry, and it can be fully self-hosted on the entity's infrastructure. For a financial entity that has a regulatory reading: Article 28(8) of DORA requires exit strategies for ICT services supporting critical or important functions. With an open protocol and a control plane of its own, exiting a provider does not force the entity to rebuild its access architecture.

BlueUP develops noa, an independent Rust reimplementation of the OpenZiti client SDK, released under the Apache 2.0 licence and interoperable with the OpenZiti controller and routers. The SDK runs inside the process of the critical service, which is why being written in a memory-safe language matters. noa is at the research stage: there is no production deployment at a client yet and no external cryptographic audit, and it is not affiliated with NetFoundry or OpenZiti.

DORA and evidence of who accesses what

DORA does not mention Zero Trust, but its technical standards describe precisely what identity-based access control produces. These are the requirements it touches:

Requirement	Provision	What embedded control provides
Limit logical access to what is required for legitimate and approved functions	DORA, Art. 9(4)(c)	A service is reachable only by the identities a policy authorises; everything else is denied by default
Strong authentication mechanisms	DORA, Art. 9(4)(d)	Certificate-backed identity and mutual authentication on every connection
Unique identification and authentication of natural persons and systems	RTS 2024/1774, Art. 20(1)	One identity per service and per client, not per IP address
Least privilege and access rights review at least every six months for systems supporting critical or important functions	RTS 2024/1774, Art. 21(a) and 21(e)(iv)	The review reads a policy (identity and service) instead of rebuilding reachability from network rules
Log events related to logical access control and identity management	RTS 2024/1774, Art. 12(2)(c)(i)	The controller emits authentication, session and identity and service change events
Document all network connections and data flows	RTS 2024/1774, Art. 13(b)	Every permitted flow is a named policy; the inventory comes out of the control plane

The auditor's question

"Who can reach this service?" With network control, the answer is rebuilt by cross-checking firewall rules, ranges and exceptions. With embedded control, it is the list of identities a policy authorises, with the history of its changes.

Two limits should be written down. Embedded control does not replace the ICT risk management framework of DORA Article 6, nor the segmentation that Article 13(a) of the Delegated Regulation still requires. And the log it generates needs the same protection as any other: Article 12(2)(d) requires protecting it against tampering, deletion and unauthorised access. The access path produces the evidence; its custody remains with the entity.

Where to start

Inventory what listens. DORA Article 8(4) already requires identifying ICT assets and mapping their interdependencies. The starting point is the list of services supporting critical or important functions with a reachable port, from which networks and for whom.
Pick a candidate service. One with few known consumers and high impact if exposed: an internal API or an administration console.
Choose the model per service. A tunneler next to the service when the code cannot be touched; an embedded SDK for new development or the most sensitive workloads. It is the same recommendation the OpenZiti project itself makes.
Measure before and after. Reachable ports, associated firewall rules, identities with access, and whether the six-monthly access review can be answered by reading the policy.

Conclusion: What does not listen needs no defending

Embedded Zero Trust does not add another layer around the service: it removes the port those layers were protecting. The exposed surface is measured in authorised identities, and the access evidence DORA and its Delegated Regulation ask for comes out of the access path itself instead of being rebuilt by hand before each review.

It is not the only piece of a resilience architecture, but it is one of the few that reduce both what has to be defended and what has to be demonstrated. The first step is knowing what the entity's most critical service listens on today.

Zero Trust in banking: Why VPNs are no longer enough — Identity, mTLS and dark services as a model.
TLPT under DORA: Spain's first testing cycle — The tests that attack the exposed surface in production.
Agentic AI and Zero Trust: Identity, then connectivity — The same principle applied to AI agents.

What does your most critical service listen on today?

We review a candidate service with your technical team: which ports it has open, who can reach it and what access evidence it produces.

→ Request a demo

→ Back to blog · See technology

Services without exposed ports: Embedded Zero Trust ​

The exposed surface starts at an open port ​

From perimeter to identity, and from network to application ​

A service with no inbound ports ​

Access control inside the application ​

An open protocol: OpenZiti ​

DORA and evidence of who accesses what ​

Where to start ​

Conclusion: What does not listen needs no defending ​

Related reading ​