Questions, answered.

Telovix gives telecom operators a local control plane for Sensor trust, pack assignment, runtime visibility, and controlled enforcement. Console coordinates the fleet, Sensor stays on the node boundary, and operator-visible state remains clear across trust, runtime, and enforcement.

No. Telovix is a telecom runtime security platform with a clear Console and Sensor boundary. It is not trying to replace existing SIEM, NMS, or observability investments. It focuses on node trust, runtime scope, policy control, and controlled enforcement.

The best fit is telecom security, platform, and infrastructure teams that operate O-DU, O-CU, and O-Cloud environments and need a disciplined runtime security layer with visible trust workflow and reversible enforcement.

Telovix supports simulated, compatibility, and live runtime modes. Simulated and compatibility modes help operators validate lifecycle and policy flow safely, while live mode enables real runtime convergence and the first narrow enforcement path where supported.

The bootstrap token is only used for first enrollment. The Sensor generates its private key locally, receives an issued certificate from Console, and then uses mutual TLS for post-enrollment control-plane traffic. Renewal, overlap, revocation, and manual renew-now all happen within that issued trust model.

Operators assign Telovix-owned packs from Console. Packs remain the source of truth for what the product is doing, while the Sensor controller compiles and stages the runtime-specific artifacts internally. The operator sees pack identity, pack state, runtime state, and enforcement state in Telovix vocabulary only.

The default state is always observe. Enforcement is intentionally narrow in the current slice and only available for supported packs in supported runtime modes. Operators move explicitly from observe to enforce_ready and then to enforced, with rollback back to observe available.

The current pack family is aligned to O-DU, O-CU, and O-Cloud. The first enforcement-capable variant is intentionally narrow and focused on O-Cloud integrity-oriented scope.

The Sensor private key stays local. Runtime activation and local event spooling stay on the node. Console is designed as a local control plane, and the product supports offline license verification so core operator flows do not depend on permanent vendor connectivity.

Console stores a per-Sensor manual renewal request. The trusted Sensor controller notices that request during normal control-plane sync, performs renewal over the existing mTLS path with local key rotation, and reports the result back to Console. There is no bootstrap-token reuse and no separate push channel.

Telovix currently exposes high-signal operator alerts such as renewal recommended, renewal due, renewal failure, recent trust failure, and trust revoked. These alerts are surfaced in fleet triage so trust problems become visible before they turn into outages.

Revocation blocks future control-plane requests for both the current certificate and any overlap certificate that still existed during renewal. Revocation is treated as a trust-state change, not just a UI label.

No. The bootstrap token is bootstrap-only. Once the Sensor receives its issued trust identity, post-enrollment traffic uses mutual TLS. Renewal and manual renewal also stay inside the issued trust path.

Book a demo when your team wants guided qualification, deployment review, and a product walkthrough. Request a trial when you already know you want hands-on evaluation and can describe the operator use case you want to validate.

The public pricing tiers represent increasing operational scope, trust workflow depth, and support level for teams adopting the Console + Sensor model. They are meant to reflect rollout maturity and procurement fit, not anonymous self-serve commodity usage.

Telovix supports two deployment models: self-hosted, where your team operates Console, and Telovix-provisioned, where we deploy and operate it for you. The right path depends on your operating model, compliance requirements, and how much infrastructure work you want Telovix to own.

The Sensor uses the Linux eBPF subsystem built into the mainline kernel since version 5.4. eBPF programs run inside the kernel in a sandboxed virtual machine and are verified before execution. No kernel patches, no kernel modules, and no reboots are required. If the Sensor process is stopped, all hooks are automatically removed.

No. The Sensor captures event metadata only. For network flows: source and destination IP, port, protocol, and byte count. For 5G protocols: procedure codes, session identifiers, and interface state. What is explicitly not captured: encrypted NAS PDU payloads inside NGAP messages, GTP-U encapsulated user plane IP packets, TLS-encrypted SBI call bodies, SIP call content, and DNS query resolution results. The PCAPNG snapshot included in heartbeats is bounded to a maximum of 100 SCTP/NGAP control-plane frames and 64 KB, with no user-plane traffic.

The Sensor captures raw protocol frames from the network interface using a zero-copy ring buffer, then decodes procedure codes, session identifiers, and interface state for each protocol. For encrypted service calls, it uses application-layer probes on TLS library entry points to observe request metadata after decryption inside the process. In all cases, only metadata is captured: subscriber payloads, encrypted content, and inner tunnel packets are never inspected. Full protocol coverage details are on the How It Works page.

Minimum supported kernel is 5.4. Kernel 5.15 or later is recommended for full BTF support, which enables portable eBPF programs across kernel versions. On Kubernetes, the Sensor runs as a DaemonSet and requires three capabilities on the pod: CAP_SYS_ADMIN for kprobe installation, CAP_NET_RAW for SCTP packet capture, and CAP_PERFMON for loading eBPF programs (available on kernels 5.8 and later; CAP_SYS_ADMIN covers it on earlier kernels). LSM BPF hooks require kernel 5.8 and the kernel compiled with CONFIG_BPF_LSM. They are optional and not required for baseline coverage.

The Sensor communicates only with the Console URL configured at enrollment time. All outbound traffic is a single HTTPS POST to the heartbeat endpoint, authenticated with the mTLS client certificate issued during enrollment. There is no DNS-based redirection, no secondary callback channel, and no update mechanism that pulls from a third-party source. The Console URL is set at enrollment and enforced by the mTLS server certificate verification. A compromised Sensor can report false events to Console or stop reporting, but its only network egress path is that one authenticated HTTPS endpoint inside the operator environment.

Console holds the mTLS certificate authority, enrollment token hashes, policy pack assignments, and the event database. A Console compromise means an attacker could enroll rogue Sensors using a stolen or forged enrollment token, issue replacement certificates to impersonate existing Sensors, read the event history, and modify enforcement state. It does not give direct access to node-level process execution or the ability to inject kernel-level actions on Sensors that have not already been enrolled. Sensor private keys are generated on-node and never transmitted, so they cannot be stolen from Console. The recommended mitigation is restricting Console network access to operator management networks only and enabling MFA on all Console user accounts.

Yes, in principle. A misconfigured policy that matches a critical process could terminate it. Telovix mitigates this through explicit gates: enforcement requires an operator transition from Enforce-Ready to Enforced, and Enforce-Ready requires healthy trust state and observed activity. Rollback to Observe is always available from Console without reinstalling the Sensor. Telovix recommends running in Observe mode for a full baseline period before advancing.

The license bundle is a JSON file signed with an Ed25519 private key held by Telovix. The Console binary contains the corresponding Ed25519 public key embedded at build time. On startup and on each enrollment attempt, Console deserializes the license payload, verifies the Ed25519 signature locally against the embedded public key, and checks the validity window. No network call is made. No Telovix server is contacted. An operator can import a license on an air-gapped Console and it will verify correctly as long as the signature is valid and the current date is within the license window. The license encodes the maximum number of protected Sensors; Console enforces this limit at enrollment time by counting active Sensors in the local database.

The Sensor runs a kernel guard that establishes a baseline count of loaded kprobe entries by reading /sys/kernel/debug/tracing/kprobe_events five minutes after startup (allowing the kernel to stabilize). Every 30 seconds it re-reads that count and the BPF filesystem mount at /sys/fs/bpf. If the kprobe count decreases it generates a high-severity alert indicating that hooks may have been disabled. It also monitors /proc/modules for unexpected increases in loaded kernel modules that could indicate rootkit installation. These checks run independently of the main event pipeline so they fire even if the primary eBPF event stream is disrupted.

Yes. The Sensor deploys as a DaemonSet on Kubernetes and as a systemd service on bare-metal nodes. The enrollment, mTLS, pack assignment, and heartbeat flows are identical in both cases. On Kubernetes, each Sensor captures pod inventory, image digests, and namespace context automatically from the node, and attaches per-container events back to the pod and namespace. The same Console manages both bare-metal Sensors and Kubernetes Sensors in the same fleet view. There is no separate agent or separate policy system for Kubernetes workloads.

Yes. Console supports Syslog/CEF forwarding for real-time event output to external SIEM systems. It also supports Parquet export to S3-compatible object storage for batch ingestion into data lake or SIEM pipelines. The event schema includes sensor_id, event_kind, severity, process_executable, pod and namespace context for Kubernetes, and a telecom_context field with protocol-specific metadata for 5G events. Telovix is not a SIEM replacement, but it is designed to feed high-fidelity telecom-specific events into the SIEM tooling operators already operate.