Protoxol ingests endpoint, network, email, identity and cloud telemetry into one schema, correlates it by asset and user, and lets the team investigate and respond from a single console. This page explains how it's built, what it integrates with, what you need to deploy it, and what it doesn't do.
The Protoxol platform includes ten modules that write to one data model and are operated from one console: EDR, NDR, SIEM and search, threat intelligence, email protection, vulnerability management, asset inventory, credential exposure, response automation and reporting. Modules are activated independently and priced per protected endpoint by plan. The platform runs as EU-hosted SaaS or self-hosted on the customer's infrastructure, ingests from Wazuh, Splunk, Elastic, Suricata, Microsoft 365 and Okta, and exports through webhooks, REST and OTEL.
Endpoint, network, identity, email and cloud events are normalized into the same schema, with two join keys: asset and actor. Adding a module two years later isn't an integration project: it writes into the same schema.
Signals that share an asset, an actor or a behavior chain within a time window are grouped into one incident. Example: an execution caught by EDR and a beacon caught by NDR on the same host, within five minutes, reach the queue as a single incident.
Each finding is scored on exposure × exploitability × blast radius, computed from the asset inventory and threat intelligence. A critical CVE on an isolated box drops down the queue; a medium one on an internet-facing server moves up.
Playbooks propose the action, queue it and explain it. An analyst approves before any external action runs. Every step is logged, can be undone, and is exported to the audit trail.
In from Splunk, Elastic, Wazuh, Suricata, Zeek, Microsoft 365 and Okta. Out through webhooks, REST and OTEL. Protoxol can replace your current SIEM or feed it; there's no lock-in clause forcing a migration.
Buy one module or all ten. Pricing follows the endpoints and mailboxes you protect, not user count or ingest volume. A module that's off costs nothing and doesn't show in the console.
Managed service in an EU region, or installed on your own infrastructure when data policy requires it. Either way the console, API and playbooks are the same.
Keyboard shortcuts for frequent actions, one-click pivots from alert to asset, actor and host, and every action traceable. It's built for whoever is on shift at 3 a.m., not for a slide deck.
Many teams combine a SIEM, an EDR and sometimes an XDR: three tools, three pricing models and three integration projects. The table compares structural criteria, not performance. Where a specialist tool is the better fit, we say so.
Endpoint, network, email, identity and cloud in the same schema, with the same join keys.
One login and one query syntax across every module.
Keep your current SIEM as the system of record, or migrate whenever you decide.
| Capability | Protoxol | Traditional SIEM | Standalone EDR | Enterprise XDR |
|---|---|---|---|---|
| Unified data model across endpoint + network + email | ✓ | × | × | ~ |
| Correlation across endpoint, network and email before it reaches the analyst | ✓ | × | ~ | ~ |
| Risk-based prioritization (exposure × exploitability) | ✓ | × | × | ~ |
| Supervised, traceable automation | ✓ | ~ | ~ | ~ |
| SaaS + on-prem with same product surface | ✓ | ✓ | ~ | × |
| Per-endpoint pricing, no ingest tiers | ✓ | × | ✓ | × |
| Open output (webhooks, REST, OTEL) to another SIEM | ✓ | × | ✓ | × |
| Multi-tenant for MSPs without a separate product | ✓ | ~ | ~ | ~ |
Where a specialist tool fits better: when you need one function only (just endpoint, just SIEM) and consolidation isn't planned. Where Protoxol makes sense: when the team already runs two or more tools that don't share context and wants to investigate from one place.
Modules share the same data model and event bus. Add a module and every existing detection, query and playbook benefits — no glue code, no re-ingestion.
Protoxol sits alongside your current tools from day one. You migrate in phases, or not at all.
Managed service with data hosted in the European Union. No infrastructure for you to run.
Run the identical console, API and playbooks on your own infrastructure when SaaS isn't an option.
Wazuh, Suricata, Zeek, Splunk, Elastic, M365 and Okta connect directly — no rip-and-replace required.
Webhooks, REST and OTEL stream out. Keep your existing SIEM as the system of record if that's the plan.
No. Protoxol ingests from tools you already run — Wazuh, Splunk, Elastic, Suricata and more — so you can pilot a module alongside your current stack before deciding what, if anything, to retire.
It depends on how many sources you connect and how much the rules need tuning against your environment's noise. A single module can be generating detections within days, because the data model and correlation already exist and there's no schema mapping to do. The plan for the first weeks is set during the initial assessment.
Yes. Modules activate independently and share the same data model, so adding EDR after starting with SIEM doesn't require re-ingesting data or rebuilding detections — existing rules benefit from the new signal automatically.
Most teams start with SaaS for speed. If data residency or infrastructure policy requires it, self-hosted runs the same console, API and playbooks. What changes is where it runs, not the product.
Your IT or security team, or the MSP that manages it for you. Protoxol doesn't include its own analysts watching your alerts; it includes the console, the maintained rules and the support to configure it.
A 30-minute session with an engineer. Bring your list of sources; leave knowing what connects on day one, which modules you need and which you don't.