Zero Trust is not a product. It's a different way of designing trust.
When I designed Anubis ZTNA, the question wasn't:
"How can I add another security control?"
The question was far more complex:
"How can I allow access to resources without turning the resources themselves into a target?"
Because in traditional architectures there is a contradiction:
More accessibility often means more exposure.
More security often means more complexity.
More centralization often means creating a single point of failure.
The solution was to separate what is normally concentrated.
🔹 100% On-Premise: where trust resides
Anubis was built on a precise principle:
Security must remain under the organization's control.
The architecture can be installed entirely within the customer's infrastructure.
Identity, policies, operational PKI, mTLS certificates, and access enforcement all remain under the control of the protected environment.
No mandatory dependency on a cloud control plane.
For critical infrastructure, OT, and regulated environments, the question isn't just:
"How do we protect the data?"
but also:
"Where does the trust that decides who can access reside?"
🔹 Anubis Core: autonomous on-premise security
Each Anubis Gateway can operate autonomously directly within the customer's infrastructure.
The Gateway maintains locally:
Cryptographic identities
Operational PKI
mTLS certificates
Secure channels
Policy enforcement
Local resource protection
With an extremely small footprint, Anubis is designed to be lightweight, portable, and deployable close to the resources it protects.
Security stays close to the resource that needs to be protected.
🔹 GT_MANAGER: Enterprise on-premise orchestration
For organizations that require multi-Gateway and multi-tenant management, GT_MANAGER introduces a higher level of administration.
It does not replace the Gateway.
It coordinates it.
It manages:
Users
Tenants
PBAC policies
Configuration distribution
Authorization synchronization
Each user is evaluated individually through their own attribute- and context-based policy.
Not static groups.
Not inherited permissions.
Each identity has its own access rule.
🔹 Centralized Policy. Distributed Enforcement.
GT_MANAGER governs policy distribution.
Anubis Gateways enforce the rules locally.
Cryptographic trust remains distributed across the Gateways, where mTLS, operational PKI, and secure channels are managed directly.
But the most important point about Zero Trust is this:
Authentication must not be the moment when permanent trust is born.
A session authorized today can become unauthorized tomorrow.
A certificate can be revoked.
A policy can change.
A time window can expire.
A user can lose access rights while still connected.
For this reason, Anubis applies continuous context verification.
During a session, the following are re-evaluated:
Identity
Certificate status
Time constraints
PBAC policies
If authorization conditions are no longer met, access is revoked without waiting for the session to close naturally.
🔹 Controlled Application Exposure
Anubis does not directly expose protected services.
The exposed ports belong exclusively to the Anubis layer.
The Gateway manages:
Multi-host TLS endpoints
System-generated HTTPS certificates
Hostnames via internal DNS
Controlled application publishing
The real service remains isolated.
The resource is not exposed.
Only the control point is exposed.
🔹 Overlay Native Architecture
Anubis operates within a private overlay network.
The overlay provides connectivity.
Anubis provides:
Identity
Policy
Control
Enforcement
This separation makes it possible to protect even environments where modifying existing systems is complex or impossible:
Legacy servers
OT infrastructure
PLCs
Industrial machinery
Critical systems
Zero Trust doesn't mean building more walls.
It means designing systems where trust is never granted permanently.
Trust is not granted. Trust is continuously verified.
#CyberSecurity #ZeroTrust #ZTNA #OTSecurity #NIS2 #PKI #mTLS #CriticalInfrastructure #IndustrialCybersecurity #NetworkSecurity #AnubisZTNA