Private infrastructure no longer lives in one place. Teams now work across office networks, cloud environments, customer systems, and home networks. Internal tools and private services still need to remain reachable from wherever work happens, but reachability should not mean public exposure or broad network access.
Netsody addresses this by combining policy-driven access with encrypted connectivity. It is a Zero Trust Network Access (ZTNA) platform for centrally managed, identity-aware private access. In practical terms, an employee can reach a single internal admin dashboard without being placed on the whole office network, and a contractor can access one project system without being granted access to unrelated internal services.
Netsody treats access control and connectivity as one system. A central controller defines policy, while an encrypted QUIC, HTTP/3, and MASQUE-based connectivity layer can use direct peer-to-peer paths where possible and relayed paths where necessary, so private resources can stay reachable without being broadly exposed.
Netsody treats access control and connectivity as one system. A central controller defines who may access what, while the encrypted connectivity layer handles how that access is established across real-world networks. It uses QUIC, a modern encrypted transport protocol, to support resilient connections and can use direct paths when possible or relayed paths when necessary. This keeps private resources reachable without making them broadly exposed.
Private infrastructure is becoming harder to protect
Organizations traditionally treated private access as a network problem: place a VPN in front of the internal network, authenticate the user, and let the device in. That model is becoming harder to justify.
Internal systems are no longer protected simply because they sit “inside” an office network. Workloads, admin interfaces, dashboards, and self-hosted services are often reachable across too many users, devices, and network paths. That creates risk beyond the first login or exposed service. If access is too broad, one compromised account, device, or gateway can become a starting point for lateral movement.
Recent security reports point in the same direction. The 2025 VPN Exposure Report, based on a survey of 648 IT, network, and cybersecurity professionals, reported that 48% of surveyed organizations had experienced a VPN-related cyberattack. Verizon’s 2025 Data Breach Investigations Report found that exploitation of vulnerabilities accounted for 20% of known initial access vectors in non-error, non-misuse breaches, and that edge devices and VPNs represented 22% of targets within that vulnerability-exploitation category, up from 3% in the previous report.
The Zero Day Clock project tracks the shrinking time between vulnerability disclosure and confirmed exploit availability. At the time of writing, its 10% trimmed mean time-to-exploit estimate had fallen to about 10 hours, down from 56 days in 2024. While this metric depends on observed exploit data and should not be read as a universal constant, the trend is clear: shorter exploitation timelines make it riskier to rely on broadly reachable access infrastructure as a perimeter.
A dashboard, VPN gateway, remote desktop, or internal application exposed too widely can become an initial access point. If network access is broad, that initial compromise can become a path toward other systems.
ZTNA addresses this problem by changing the access model from “you are on the network” to “you may reach this specific resource under this policy.” NIST SP 800-207 describes Zero Trust as a shift away from static, network-based perimeters toward users, assets, and resources, with no implicit trust based solely on physical or network location.
In practice, access should be scoped to the actual need. A site should connect to selected cloud resources without opening broad lateral movement paths. An edge device behind Network Address Translation (NAT) should remain reachable for authorized users without exposing it publicly. Access should follow identity, device context, and policy rather than implicit trust in a network location.
Access needs to become explicit
Modern private access requires more than authenticating a user and placing a device on a network. Organizations need a clear way to define who may reach which private resource, under which conditions.
For example, giving a contractor access to a project dashboard should not require adding their device to a VPN profile that also reaches file shares, databases, or admin interfaces. The policy should describe the allowed relationship directly, and unrelated services should remain outside it.
In Netsody, policies describe relationships between users, groups, nodes, node groups, and private resources such as services, IP ranges, domains, and wildcard domains. They can also restrict access by protocol, port, device posture, and communication direction. For example, one policy can allow a user group to reach an internal dashboard, while another allows a site node to reach selected cloud resources. Directional rules make clear whether communication is one-way or whether the target may also initiate traffic back.
That access model has to be visible, reviewable, and centrally controlled. Otherwise, decisions end up scattered across VPN profiles, firewall rules, jump hosts, and one-off tunnels.
Introducing Netsody
Netsody implements that model as a centralized web-based control interface and an encrypted connectivity layer for distributed private infrastructure.
The controller is the default operating model for managed environments: a central, web-based interface for managing access across users, groups, devices, networks, resources, routes, DNS, and policies. It helps operators understand who can access what across the environment.
For environments that need a more decentralized setup, the underlying system can also be configured without a controller by providing each node with the local configuration required to construct the intended access relationships.
By default, Netsody keeps the operating model centralized: policy is managed centrally, data paths are encrypted, and private resources remain private by design.
Built for restrictive networks and multi-domain access
Private access has to work in the networks where users and devices actually are: home networks, mobile networks, customer networks, campus networks, restrictive environments, and networks hidden behind NAT and firewalls. A policy may allow a user to reach a private service, but the product still has to make that connection work reliably.
Netsody uses a QUIC-based transport with NAT traversal support, combined with HTTP/3 and MASQUE for signaling and indirect communication. Where appropriate, it can fall back to HTTP/2. This helps keep access usable as long as outbound web access is available, including networks where other VPN protocols, such as WireGuard, may be blocked.
Where possible, Netsody establishes direct encrypted peer-to-peer paths between endpoints. Where NAT behavior, firewalls, or local network restrictions block direct connectivity, relayed paths provide an alternate encrypted route. Central policy defines who may communicate; the encrypted transport provides the paths that make those decisions usable across the networks where the resources actually live.
Netsody is also designed for multi-domain scenarios. A device, service, or site can participate in multiple networks at the same time, even when different administrators or organizations manage those networks. This is useful when users, devices, services, or organizations belong to several administrative contexts at once.
In federated ZTNA networks, each organization can keep independent control over its own Netsody network and policies while allowing selected communication with other ZTNA networks at defined handover points. This kind of cross-organization access model was relevant in contexts such as RESCUE-MATE, a research project on dynamic situation pictures and information flows for rescue forces in complex crisis scenarios.
Users define access policy in the controller, while Netsody handles path selection, relaying, and encrypted transport underneath.
Shaped by research, built for real deployments
Although Netsody is launching now, it did not start from scratch. It builds on years of research, prototyping, and practical development at the University of Hamburg Computer Networks working group. Across these prototypes and research projects, the recurring challenge was not only how to connect distributed systems, but how to keep that connectivity manageable, scoped, and secure across organizational boundaries.
Those requirements are no longer limited to research settings. They now appear in distributed teams, cloud infrastructure, partner access, and self-hosted systems. At the same time, traditional perimeter-based access models have become harder to operate safely, especially when access depends on VPN gateways, firewall rules, jump hosts, and one-off tunnels.
Demanding research and application environments shaped the product requirements: connectivity must remain secure, manageable, and reliable despite NAT, firewalls, changing networks, restrictive environments, and organizational boundaries.
Those lessons now shape Netsody as a product beyond the research context: a dependable ZTNA platform for distributed IT environments. Our goal is to bring this work into real operational use, supported by a path from university research toward an independent product organization.
Early access
During early access, we are working with users to explore concrete private access scenarios, from internal dashboards and distributed sites to edge devices and partner connectivity. We are especially interested in real use cases, deployment constraints, operational feedback, and missing functionality.
The goal is not only to test the current product, but also to understand which private access needs matter most in real environments and which functions users need next.
If you want to try Netsody in the early phase, get in touch at oi.ydosten@olleh.