# Axiom Border

## Axiom Border

<div class="product-logo">
{{< staticImage "edge_products/axiom_border/axiom-border-logo.png" "Axiom Border logo" >}}
</div>

**Axiom Border** is a network and asset monitoring probe you install at the edge, close to the equipment
it watches. It works fully disconnected, and it does four jobs that normally take four separate tools:

```mermaid
flowchart TB
    A["Your network<br>servers · devices · PLCs"]:::ext --> P["<b>Axiom Border</b>"]
    P --> M["Metrics<br>and alarms"]
    P --> S["Security<br>assessment"]
    P --> C["Web console<br>and API"]
    M --> OG["OpenGate<br><i>optional</i>"]:::ext
    S --> OG

    classDef ext fill:#e9edfa,stroke:#486ac9,color:#101010
```

1. **Monitors** the hosts and devices around it, collecting metrics and keeping the history locally.
2. **Raises alarms** on its own, from rules you define, with no need to reach a server first.
3. **Assesses security** — discovers assets, scans ports and services, detects vulnerabilities, queries
   SNMP and observes traffic. Including **industrial OT/ICS protocols**, which is what sets it apart from
   a general-purpose scanner.
4. **Integrates** with OpenGate when you want a fleet-wide view, over HTTP or MQTT — and keeps working
   exactly the same when the link is down.

## Two fronts: the hosts and the network

Axiom Border watches on **two levels at once**, and the console gives each one its own view. This is what
lets a single probe cover an IT/OT boundary rather than just one side of it.

### The hosts it monitors — Current status

Every node running an **oda-lite** monitoring agent reports what happens *on* that machine: SSH
sessions, USB devices attached, the state of its physical network interfaces, and its reporting-health
heartbeat. **Current status** shows one block per node, with a status dot per monitor, the last event
each one delivered, and the alarms currently open against it.

{{< staticImage "edge_products/axiom_border/console-current-status.png" "Current status — per-node monitors and the alarms open against each node" >}}

The value of this view is that a problem is visible two ways at once. In the capture above the
**METRIC-Guard** dot is red on all three nodes, and the alarm table beside it reads *Node stopped
reporting* — the missing telemetry and the alarm it raised, side by side.

### The network it is plugged into — Network status

Point the probe at a network segment and it builds an inventory of what lives there: hosts discovered,
their open ports and services, the operating system it could fingerprint, and the vulnerabilities found
on each — industrial protocols included.

{{< staticImage "edge_products/axiom_border/console-network-status.png" "Network status — discovered assets with their ports, vulnerabilities and severity breakdown" >}}

The header names the last assessment and how it ended, the table lists every asset with per-host actions,
and the charts underneath break findings down by severity and hosts by state.

| Aspect | Current status | Network status |
| --- | --- | --- |
| Looks at | The machines running an agent | The network segment the probe sits on |
| Answers | What is happening on my hosts? | What is out there, and is it exposed? |
| Sees | SSH, USB, interfaces, reporting health | Hosts, ports, services, OS, vulnerabilities |
| Needs | An oda-lite agent installed on each host | Only the probe, pointed at a target range |
| Documented in | [Metrics and monitoring](metrics_ingestion/) | [Security assessment](security_probes/) |

Neither front is mandatory. A probe with no agents reporting is still a full network scanner, and a probe
that never scans is still a monitoring collector — most deployments end up using both.

{{% notice style="info" title="Documented version" %}}
This documentation describes Axiom Border as of **August 2026**. Where an example depends on a specific
field or option, check it against the version you have installed.
{{% /notice %}}

## Why it exists

Conventional monitoring assumes the collector can always reach the backend. Conventional vulnerability
scanning assumes it can always reach a feed of vulnerability definitions. Both assumptions break at the
edge — and they break hardest exactly where the equipment matters most, in industrial networks that are
isolated on purpose.

Axiom Border inverts that. Everything it needs to do its job is installed with it: the web console, the
industrial vulnerability checks, the SNMP definition catalogue, and the local storage for history. A
probe placed in an isolated network is useful immediately, with no feed to update and no service to call
out to.

### Where it fits

| Situation | What Axiom Border gives you |
| --- | --- |
| Industrial or OT segment | Asset discovery and vulnerability assessment over Modbus, IEC-104, DNP3, BACnet and OPC UA — read-only by default |
| Remote site on a poor link | Local metrics, local alarms, and reporting to OpenGate when the link allows |
| IT/OT boundary | Passive traffic observation plus active scanning, with a full record of every assessment run |
| A fleet of sites | One aggregating node collecting from several remote probes |

## How you interact with it

Two interfaces, covering the same capabilities:

- **The web console**, served by the probe itself. Point a browser at the probe's address and log in.
  This is the normal way to operate it.
- **The REST API**, for integrating with your own systems, scripting routine work, or driving the probe
  from OpenGate.

The console has six views, and they map onto the sections of this documentation:

| Console view | What it covers | Documented in |
| --- | --- | --- |
| **Current status** | The probe at a glance | This page |
| **Alerts** | Raised alarms and the rules behind them | [Alarms and rules](alarms_and_rules/) |
| **Network status** | Discovered assets, ports and vulnerabilities | [Security assessment](security_probes/) |
| **Supervisions** | The monitoring agents reporting in | [Metrics and monitoring](metrics_ingestion/) |
| **AI capabilities** | Anomaly-detection models | [AI capabilities](ai_capabilities/) |
| **Configuration** | The probe's settings, edited and applied from the browser | [Configuration](configuration/) |

Wherever a task can be done either way, the pages show both paths side by side.

## What it needs to run

Axiom Border installs from a **single self-contained package** that carries everything it depends on, so
the target machine needs no internet access and no manual preparation.

| Requirement | |
| --- | --- |
| Operating system | Ubuntu 22.04 or 24.04, Debian 12 or 13 — 64-bit |
| Machine | 2 CPU cores and 2 GB RAM minimum; 4 cores and 4 GB recommended |
| Disk | 4 GB free minimum, 20 GB recommended for history |
| Network | Access to the network you want to monitor |
| Internet | Not required |

Depending on how you deploy it, the package also installs the metrics database and the components for
the optional anomaly-detection feature. The deployment types differ in which of those they include.

## Where to go next

Once the probe is installed, [Configuration](configuration/) is where you adapt it to your environment.

Getting a running probe to do something useful:
[Metrics and monitoring](metrics_ingestion/) to bring data in,
[Security assessment](security_probes/) to examine what is around it, and
[Alarms and rules](alarms_and_rules/) to react automatically.

Integrating with other systems: [MQTT and OpenGate](mqtt_and_opengate/).

{{% notice style="warning" title="Before you scan industrial equipment" icon="triangle-exclamation" %}}
Axiom Border can perform checks that write to industrial devices. This is switched **off** by default and
needs two separate confirmations to enable — but the responsibility for authorising it is yours. Read
[OT/ICS vulnerability scanning](security_probes/ot_ics_scanning/) before enabling anything against a live
plant.
{{% /notice %}}

## Index

{{% children sort="weight" depth="100" %}}
