Ixiea is a layered control plane: identities authenticate once, privileged sessions terminate at protocol connectors, and evidence is captured before traffic reaches targets.
Access
IdP + clients
Gateway
Choke point
Control
API + tasks
Data
Metadata + replay
Targets
Unchanged infra
Sessions flow through the gateway. Evidence persists in the data layer.
Traditional PAM stacks scatter enforcement across agents, vault checkouts, and network ACLs. Ixiea centralizes brokering, MFA, recording, and audit at a single choke point. Operators do not receive standing network paths to production. They receive session grants bound to identity, permissions, and optional time windows.
Without gateway
Agents · vault checkout · network ACLs
Gateway choke point
Session grants · MFA · recording · audit
Access
IdP · web UI · clients
Gateway
Protocol connectors
Control plane
Core API · Celery
Data
PostgreSQL · replay store
Targets
SSH · RDP · DB · K8s
The access layer connects your IdP and client tools (web UI, native SSH/RDP clients). The gateway layer brokers protocols and captures sessions inline. The control plane, Ixiea core API plus background workers, schedules approvals, asset sync, and connector health. The data layer persists session metadata, command logs, and replay artifacts. Targets stay unchanged: SSH daemons, RDP hosts, databases, and Kubernetes APIs see brokered connections, not standing operator credentials.
The platform core owns organizations, users, assets, permissions, command filters, and audit. Protocol connectors register with core and execute sessions: an SSH and Kubernetes connector for terminal and exec paths; a graphical connector for browser RDP and VNC; a web SQL client for database sessions; plus optional TCP-level database and RDP proxy connectors where deployed. RBAC, login ACLs, and command filters evaluate at connect time. PostgreSQL holds structured metadata; Redis backs sessions and tasks; object storage (S3, Azure, OBS, OSS) holds replay files.
Core + Celery
Auth · RBAC · assets · audit · approvals
Pilot
1 core · 1 connector
HA
Active / standby core
Scale out
LB + connector fleet
Multi-region
Connectors near targets
Start with a single core instance and one connector deployment for a pilot estate. Scale horizontally by adding connector pods behind a load balancer, sessions are stateful at the connector but permissions and audit remain centralized in core. Active/standby and multi-region patterns place connectors close to targets while keeping one authoritative policy store. See the deployment models guide for scenario-specific topologies.
Operational docs
Related guides
Standalone, active/standby, horizontal scale, and multi-region gateway, when each fits.
Fifteen-minute path from install to a brokered, recorded, identity-bound session.
How users, targets, accounts, protocols, and time windows combine into enforceable grants.
Graduated enforcement for commands and connections, permit, block, approve, mask, or alert at the gateway.
Ready to evaluate?
Walk through gateway brokering, recording, and audit exports in a working session — or browse the illustrated product flow first.
