- Every SIEM, SOAR, and MDR platform tags a handful of alerts with a Zero Trust label after the event has already fired. That is a report, not an architecture.
- AUXO™ is built the other way around: the Protect Surface is the data schema itself, so every event, policy, and screen carries Zero Trust context from the start.
- Because events reach EventFlow already enriched with Protect Surface, data classification, location, and compliance scope, 69 raw events become 3 real analyst investigations, not through rule suppression but through context.
- AUXO measures three policy enforcement levels per Protect Surface. Only the third, deny-all with full Kipling Method verification, is actually Zero Trust.
- Access density is a single quantifiable score, lower is better, that proves microsegmentation is reducing attack surface rather than just looking configured.
Every SIEM, SOAR, and MDR platform on the market tags a handful of alerts with a Zero Trust label after the event has already fired. That is a report, not an architecture. AUXO™’s Protect Surface is not a label added at the end. It is the database schema itself, the reason 69 raw events become 3 real investigations instead of 69 alerts.
What is AUXO™?
AUXO is a Zero Trust-native security platform. Instead of tagging events with a Zero Trust label after they are processed, it uses the Protect Surface, a bounded segment of critical data, applications, and services, as its core data schema. Every event, policy, and screen in AUXO is built around Protect Surfaces from day one.
That is different from SIEM, SOAR, and MDR platforms, which are built around an event pipeline: ingest, rule, alert, and report Zero Trust posture as a separate layer on top.
Because AUXO enriches every event with Protect Surface context, data classification, and compliance scope before it reaches its processing engine, EventFlow, it can reduce 69 raw events to 3 real analyst investigations without relying on rule suppression. Retrofitting this onto an existing event-first database is not a feature update. It requires a rebuild from the ground up.
Two Ways to Build a Security Platform
Standard SIEM, SOAR, and MDR platforms were designed around the event pipeline: ingest telemetry, match rules, generate alerts, route to analysts. Zero Trust posture gets reported against separately, a dashboard that maps alerts to ZT pillars after the fact. The event is the primary object. Everything else is context bolted on afterward.
AUXO was designed around the Protect Surface instead. Every event arrives already enriched with Protect Surface identity, data classification, compliance scope, and Zero Trust policy context. The Protect Surface is the primary object. Events are processed within that context, not labelled with it after the fact.
| Every other platform | AUXO™ |
|---|---|
| Event-first architecture. Zero Trust is reported on top, as a separate layer. | Protect Surface-first architecture. Zero Trust is native to the schema. |
| Rules and alerts run against raw event metadata and source IP. | Rules and alerts run against events already carrying Protect Surface context. |
| Processing chain: Event → Rule → Alert → Human. | Processing chain: Protect Surface → Event with ZT context → EventFlow → Human, only if needed. |
In Brief
What makes an architecture Zero Trust-native
A Zero Trust-native platform is one where the Protect Surface model is the data schema, not a reporting layer applied to a generic event database. In AUXO, every screen, event, policy, and advisory is organized around Protect Surfaces. The five-step Zero Trust methodology is embedded in the interface itself. You cannot use AUXO without operating the model. That is by design.
Why no other platform has done this
SIEM, SOAR, and MDR platforms were built to process events and route alerts. That is their purpose, and they are well optimized for it. Retrofitting a Protect Surface model onto an event-first database is not a feature update. AUXO was built from the Protect Surface up, which is only possible if Zero Trust is the design principle from day one, not a layer added to an existing product.
EventFlow, the agentic SOC engine
EventFlow™ is AUXO’s Zero Trust-optimized event processing engine. Because every event carries Protect Surface context, data classification, location, and compliance scope before it enters EventFlow, the automation rate is structurally higher than a generic SIEM or SOAR can reach. 69 raw events reduced to 3 analyst investigations, not through rule suppression, but through context-informed automated evaluation.
The prevention-first philosophy
Most MDR vendors deliver one thing: receive events, generate alerts, return them to the client. ON2IT’s philosophy is structurally different. The goal is fewer alerts, because fewer alerts means better prevention. AUXO measures and manages the effectiveness of security controls per Protect Surface continuously, not just the events those controls fail to stop.
“For most MDR vendors, monitor and maintain is the only thing they do: receive events, fire alerts. For ON2IT, it is the end of a continuous cycle. Effective protection means fewer alerts, and fewer alerts means the controls are working. That is what AUXO is built to measure.”
- Lieuwe Jan Koning, CTO and Co-founder ON2IT
I. Five Steps Built Into the Interface, Not Reported Against
The proof of a Zero Trust-native architecture is not a marketing claim. It is the interface. Every screen in AUXO is organized around Protect Surfaces and the five-step Zero Trust model that the UK National Cyber Security Centre explicitly names and recommends. AUXO follows it literally, in its interface, its methods, and its available tools.
Define: the dashboard sorts by relevance, not alert volume
The AUXO home screen is not an alert queue. It is a Protect Surface overview, sorted by relevance score, a six-dimension criticality rating that determines what protection level each surface requires. A client environment may have 28 Protect Surfaces, each unique, each sorted by importance. No event queue, no alert count. Protection posture first.
Map: transaction flows show access density, not a network diagram
The transaction flow screen shows which Protect Surfaces can communicate with which others, and whether that communication is justified. A flat network where everything connects to everything scores 100 on the Access Density Score. Zero Trust-enforced environments drive that score toward the minimum necessary connections. This screen only exists because Protect Surfaces are first-class objects, not IP ranges or VLANs.
Build: controls per Protect Surface, with evidence status
For each Protect Surface, AUXO shows technical measures in four states: active with evidence, active but not yet confirmed in traffic, desired but not yet active (accepted risk), or not applicable. An exposure map highlights Protect Surfaces with high importance and a large gap between current and target protection, the prioritization view architects and SOC engineers need. MITRE ATT&CK mapping is available per Protect Surface for clients that require it.
Policy: Kipling requests in plain language
Access policy changes are requested using the Kipling Method in plain language: who needs access, to what, when, from where, why, and how. The SOC translates that request into Layer 7 technical policy. AUXO enforces three policy levels (see Section III). Every change request is logged to a shared client-SOC timeline with a full audit trail, indistinguishable from an incident response record.
Monitor: EventFlow processes events inside Zero Trust context
EventFlow is where this architecture produces its most measurable result. Because every event already carries Zero Trust context before reaching EventFlow, automated evaluation reduces 69 raw events to 3 analyst investigations. Rules of Engagement, pre-agreed with each client, define automated responses the platform executes on its own. Human analysts see only what genuinely requires human judgment.
Signal
The five-step model is not a methodology AUXO reports against. It is the navigation structure of the platform. You move through the five steps inside the interface. That is only possible if the Protect Surface is a native database object, not a tag.
II. EventFlow: the Zero Trust-Optimized SOC Engine
EventFlow combines the strengths of SIEM and SOAR with agentic AI, optimized for Zero Trust as a Service. The difference from a generic SIEM or SOAR is not the automation rate on its own. It is why that rate is achievable: every event arrives pre-enriched with Zero Trust context that no generic platform can produce.
Four layers of Zero Trust context arrive with every event, before EventFlow evaluates it:
With that context, EventFlow makes autonomous decisions a generic SIEM, working only with event metadata and source IP, cannot. The result is a structurally higher automation rate with a structurally lower false-positive rate. A typical processing cycle looks like this:
| Stage | Count | What happens |
|---|---|---|
| Raw events received | 69 | Telemetry from client infrastructure, Fortinet and Palo Alto Networks firewalls, cloud security products, endpoint sensors. Every event is tagged with Protect Surface identity before it enters EventFlow. |
| Investigations surfaced to analysts | 3 | EventFlow evaluates, correlates, and aggregates using Zero Trust context. 66 events are resolved autonomously, via automated Rules of Engagement or confirmed as noise within policy. |
| Confirmed false positive | 1 | Closed by the analyst. Zero Trust context made the call fast: the event pattern did not match the Protect Surface’s expected traffic profile. |
| Actioned and closed | 1 | Required analyst action: a case raised, the client notified over the shared timeline, the response documented. 69 events in, one genuine incident, zero analyst time spent on the other 68. |
The evaluation cycle does not stop at the event. EventFlow also validates firewall and cloud security product policies against the expected Kipling policy for each Protect Surface, generating a regular stream of client-specific security advisories with concrete improvement recommendations. That is what closes the loop between Step 5 (Monitor) and Steps 3 and 4 (Controls and Policy).
Signal
EventFlow is not AI applied to a generic event stream. It is AI applied to a Zero Trust context-enriched event stream. That context is what makes the automation rate possible. Without the Protect Surface model underneath it, the same AI produces generic anomaly detection.
III. Three Policy Levels. Only One Is Zero Trust.
AUXO measures the policy enforcement level of every Protect Surface against three defined states. Most security platforms would call the middle level “fully secure.” AUXO calls it “Best Practice,” because Best Practice is not Zero Trust. The distinction matters.
Level 01 · Minimal
Minimal
The measure is active at the minimum acceptable level. No Zero Trust policy enforcement. The control exists and blocks known threats, but access is not governed by identity, application, time, location, or purpose.
Level 02 · Best Practice
Best Practice
Limited use of Layer 7 policy: some user, application, and device conditions applied. Most organizations consider this mature security. It is not Zero Trust. Implicit trust still exists in the policy structure.
Level 03 · Full Zero Trust
Zero Trust
Deny-all by default. Layer 7 policy fully applied via the Kipling Method: Who, What, When, Where, Why, How. Only explicitly authorized traffic transits the microperimeter, and every deviation triggers evaluation.
The exposure map on the Controls screen plots every Protect Surface by importance against current enforcement level. High-importance surfaces with low enforcement are immediately visible, the prioritization view architects and SOC leads use to drive remediation. The goal is not 100% Zero Trust enforcement everywhere at once. It is risk-ordered progression: the highest-risk surfaces reach Level 03 first.
Signal
The difference between Level 02 and Level 03 is not technical sophistication. It is the elimination of implicit trust. Any system that lets some traffic pass without explicit Kipling-structured verification is not at Zero Trust, regardless of how many Layer 7 features it uses.
IV. Access Density: Proof That Microsegmentation Is Working
Every security platform claims microsegmentation support. AUXO measures whether it is actually reducing attack surface, with a single quantifiable score per Protect Surface and across the environment.
| Flat network, worst case | Zero Trust-enforced network |
|---|---|
| Every Protect Surface can reach every other. Access Density Score: 100. | Score driven toward the minimum necessary connections only, golf scoring: lower is better. |
| An attacker with a foothold anywhere can reach everything. | An attacker with a foothold reaches only what a Kipling policy explicitly allows. |
| Connections exist because they were never removed, not because they were justified. | Every connection is either justified by policy or flagged as unexplained. |
| Visibility limited to a network diagram of VLANs or IP ranges. | Visibility maps Protect Surface to Protect Surface, compared against the policy that should govern it. |
No other platform produces this metric, because it requires Protect Surfaces as a native data structure. A network diagram can show connections between VLANs or IP ranges. Only a Zero Trust-native platform can show connections between Protect Surfaces and compare them against the policy that should govern them.
Signal
Access density is proof that segmentation is operational, not just configured. A firewall rule allows or denies. Access density shows whether the sum of all firewall rules produces a segmented environment, or just the appearance of one.
The Numbers Behind the Architecture
AUXO · EventFlow
NCSC · Kindervag · AUXO
AUXO · EventFlow architecture
AUXO · Policy framework
AUXO · Transaction flows
ON2IT analysis
The Architectural Gap a Feature Release Cannot Close
SIEM, SOAR, and MDR platforms have improved for two decades: more events processed faster, better correlation engines, better AI models, better visualizations. What none of them have done, what none of them can do without a rebuild, is make the Protect Surface their native data schema.
That gap cannot be closed by a product update. It is an architectural commitment. Every SIEM or SOAR ever built was designed to answer one question: what events are happening in my environment? AUXO was designed to answer a different one: how well protected are my Protect Surfaces, and what is the evidence? Different questions, different answers, different architectures.
EventFlow’s automation rate is a symptom of that difference, not the cause. The cause is that events in AUXO carry Zero Trust context before they are evaluated. Rules of Engagement work because they are defined against Protect Surface policy, not generic event signatures. Security advisories are client-specific because they are derived from the gap between a Protect Surface’s current enforcement level and its target. The agentic AI operates on a Zero Trust-structured world, not a generic one.
Zero Trust as a Service requires a platform that was built for Zero Trust as a Service.
Final signal
Zero Trust is not a label you attach to a dashboard. It is the schema underneath it. AUXO is the platform built that way from the first line of code.
Get in touch
See what a Protect Surface-native platform looks like on your environment.
Send us a description of your current SIEM, SOAR, or MDR setup. In a short conversation we will show you exactly where a Protect Surface-native architecture would change your event volume and your policy enforcement level.
Talk to ON2ITSources
- Kindervag, J. Zero Trust Protect Surface and Kipling Method framework.
- UK National Cyber Security Centre (NCSC). Zero Trust architecture design principles, five-step implementation model.
- AUXO™ platform architecture. ON2IT, 2026.
FAQ
What makes AUXO different from a SIEM, SOAR, or MDR platform?
Most platforms treat Zero Trust as a reporting layer added after events are processed. AUXO builds the Protect Surface into its data schema itself, so every event, policy, and screen carries Zero Trust context from the moment it exists, not after the fact.
How does EventFlow reduce 69 raw events to 3 investigations?
Every event already carries Protect Surface identity, data classification, location, and compliance scope before EventFlow evaluates it. That context lets the engine resolve most events autonomously through pre-agreed Rules of Engagement instead of suppressing them with generic rules, so only genuine investigations reach human analysts.
What are AUXO’s three policy enforcement levels?
Minimal, perimeter-level protection with no Zero Trust policy enforcement. Best Practice, limited Layer 7 policy that still allows implicit trust. Zero Trust, deny-all by default with full Kipling Method verification. Only the third level meets the actual definition of Zero Trust.
What is Access Density, and why does it matter?
Access Density is a quantifiable score showing how many Protect Surfaces can reach each other. A flat, unsegmented network scores 100. Zero Trust enforcement drives that score toward the minimum necessary connections, giving measurable proof that microsegmentation is actually reducing attack surface, not just configured.
Is AUXO’s five-step model the same as the NCSC’s Zero Trust guidance?
Yes. AUXO’s interface follows the five-step Zero Trust implementation model the UK National Cyber Security Centre recommends (Define, Map, Build, Policy, Monitor) directly in its navigation, rather than reporting against it after the fact.
Lieuwe Jan Koning is Co-Founder and CTO of ON2IT and creator of its AUXO™ Zero Trust platform. A Zero Trust Innovator since 2010, he was one of the first to introduce the strategy in Europe alongside John Kindervag, Palo Alto Networks, and VMware.