genusphere deployment: browser-based ZTAA without VPN clients
3 min read
genusphere is genua’s Zero Trust Application Access platform. It replaces broad VPN network access with browser-based, application-specific access control. No client software is required on the endpoint. Users authenticate through their identity provider and reach only the applications assigned to their role.
This guide covers the architecture, deployment model, and practical migration path for organizations moving from genua VPN to genusphere ZTAA.
Architecture overview
genusphere operates on a connector-based architecture running on Kubernetes. The three core components:
Control plane
The management layer handles policy enforcement, user authentication, and session orchestration. It integrates with Microsoft Entra ID or Keycloak for identity. All configuration and monitoring flows through a centralized dashboard with metrics and audit logs.
Data plane
The data plane processes encrypted traffic between users and applications. It runs in active-active mode for high availability and load balancing. All data traffic is encrypted end-to-end.
Connectors
Connectors are deployed near the target applications and create micro-perimeters around each one. Each connector group can be scaled independently based on demand and availability requirements. This is the core ZTAA mechanism: instead of granting network access, genusphere grants access to individual applications through their dedicated connectors.
Deployment model
Kubernetes-native
genusphere runs on Kubernetes, which means horizontal scaling, automated restarts, and infrastructure-as-code deployment. The control plane leverages Kubernetes capabilities for self-healing. Connector groups scale with demand.
On-premises sovereignty
Unlike cloud-delivered ZTAA solutions, genusphere is hosted and operated by the customer. Data never leaves the organization’s infrastructure. For German organizations with VS-NfD, KRITIS, or BSI compliance requirements, this is a decisive differentiator.
Integration with existing genua infrastructure
genusphere fits into the broader genua product family: - genugate continues as the perimeter firewall with EAL 4+ certification - genucenter provides unified management across genua products - genuscreen handles VPN traffic during the hybrid migration phase - genubox covers industrial remote maintenance scenarios under zero trust
Migration path: from VPN to ZTAA
Phase 1 — Assessment
Inventory all applications currently accessed through VPN. Classify them by access pattern: web applications, Windows legacy applications, admin interfaces, machine-to-machine communication. Identify which applications are candidates for browser-based ZTAA and which still require VPN-level network access.
Phase 2 — Pilot
Deploy genusphere alongside the existing genugate VPN. Start with a small group of web applications and a defined user group. Configure connector groups, set up identity provider integration, and validate the authentication flow. This phase proves the model without disrupting production.
Phase 3 — Staged rollout
Migrate application groups incrementally. Web applications move first, followed by legacy Windows applications through genusphere’s browser-based isolation. Monitor access logs, tune policies, and expand the user base. The genugate VPN continues to serve workloads that cannot yet move to ZTAA.
Phase 4 — Consolidation
Once the majority of applications run through genusphere, reduce the VPN footprint. Some environments may retain VPN for specific use cases (site-to-site, machine-to-machine). The hybrid phase ends when the remaining VPN scope is minimal and well-defined.
Key differentiators for technical decision makers
Clientless access. No endpoint agent. Users work through the browser. This simplifies BYOD, contractor access, and partner onboarding.
Micro-perimeter security. Each application gets its own connector boundary. Lateral movement between applications is architecturally prevented, not just policy-controlled.
German sovereignty. Developed and hosted in Germany. BSI-aligned. No data leaves the operator’s infrastructure.
Kubernetes-native scaling. Horizontal scaling through Kubernetes. No hardware bottlenecks. DevOps-compatible deployment and monitoring through Prometheus, Grafana, and Checkmk.
Legacy application support. Browser-based access to Windows applications through secure browser isolation. Legacy systems do not need to be rewritten to benefit from ZTAA.
When genusphere fits — and when it does not
genusphere is a strong fit for organizations that need application-level access control, operate in regulated environments, and want to keep infrastructure sovereignty. Hybrid workforces, contractor access, and partner access are core use cases.
It is not a replacement for all VPN use cases. Site-to-site tunnels, machine-to-machine communication, and some legacy protocols still require network-level connectivity. The practical answer is usually a hybrid deployment that combines genusphere ZTAA with a reduced genugate VPN footprint.
FAQ
Does genusphere require a VPN client on the endpoint?
No. genusphere uses browser-based access. Users connect to approved applications directly through the browser without installing a VPN client or agent.
Can genusphere run alongside an existing genugate VPN?
Yes. A hybrid deployment is the recommended migration path. genusphere handles application-level ZTAA while genugate continues to secure network-level VPN traffic during the transition.
What identity providers does genusphere support?
genusphere integrates with Microsoft Entra ID (formerly Azure AD) and Keycloak for SSO and multi-factor authentication. This covers most enterprise identity setups.