What Axiom Border Is

What Axiom Border is

Most edge monitoring works one way: a collector gathers data, ships it somewhere, and a platform decides what it means. Take the link away and the collector is a data recorder at best.

Axiom Border is built on the opposite premise. It is not an agent that reports to a cloud. It is an autonomous node that observes the network around it, decides what matters against rules it holds locally, and acts on that decision — on the machine, with no server in the loop. Centralising into OpenGate is something you switch on afterwards if a fleet-wide view is useful to you. It is never what makes the probe work.

That single decision is why the product looks the way it does:

• The decision engine is on the probe. Alarms are raised where the data is, not where the platform is.
• Everything it needs travels with it. The vulnerability database, the vendor registry, the MIB catalogue, the scan templates, the metrics store, the container runtime and the web console are all installed with the product. A probe in an isolated network is useful the moment it starts.
• Nothing is fetched at run time. There is no feed to update before a scan means anything, and no service to call before a finding can be interpreted. What exactly it carries, where each data set comes from and how to refresh it in the field is set out in Catalogs: vulnerabilities, OIDs, MIBs and more.

Why this matters in an industrial network

Isolated OT segments are isolated on purpose. A tool that needs to reach the internet to stay useful is a tool that is either useless there or a hole in the isolation. Axiom Border needs neither.

The specification, in one table

Deployment roles	central — the full node: probe, metrics store and the container runtime for the AI capability. monitoring — a remote node that reports into a central one
Installation path	A single supported path, the Keystone deployment agent, and it is 100 % offline. Roughly 5–8 minutes for a central node, 1–2 for a monitoring one
Footprint	About 141 MB for a central core package and 89 MB for a monitoring one, plus the bundled data packs, which are published once and reused across versions
Management surface	The embedded web console and a REST API, both served by the probe itself, both over HTTPS unconditionally — localhost included
Internet access	Not required, at install time or afterwards

HTTPS is not optional

There is no plaintext listener to fall back to. A probe reached over http:// refuses the connection, and that applies to localhost as much as to anything else. On first boot the probe issues its own certificate from a local authority, so it works with no PKI and no internet — see Security posture for replacing it with your own.

The two roles

A single probe covers a site on its own. The roles exist for when one site is not the whole picture.

flowchart LR
    M1["monitoring<br><i>remote node</i>"] --> C
    M2["monitoring<br><i>remote node</i>"] --> C["<b>central</b><br>probe · metrics store<br>console · AI"]
    C -.->|optional| OG["OpenGate"]:::ext
    classDef ext fill:#e9edfa,stroke:#486ac9,color:#101010

A central node is a complete Axiom Border: it watches its own network, holds the history, serves the console, and can additionally receive from monitoring nodes. A monitoring node is the light end of the fleet — it watches the machine it runs on and reports into the central one.

The dotted arrow is the point. OpenGate sits outside the boundary, it is optional, and it starts switched off.

How you work with it

Through the console. The probe serves its own web interface; point a browser at its address and log in. Everything on the pages that follow is described from that interface, because that is how the probe is meant to be operated.

A REST API exists underneath for integrating the probe with your own systems, and OpenGate drives the probe over it. It is not the operator’s path.

The console has six views, in the order the sidebar lists them:

View	What it is for	Where it is documented
Network status	Everything discovered on the network: assets, ports, vulnerabilities, and the passive inventory behind them	Security assessment
Hosts Status	The machines running a monitoring agent, one block per node	Metrics and monitoring
Alerts	Raised alarms, alarm history, and the rules behind them	Alarms and rules
Supervisions	The monitoring agents reporting in and what each last delivered	Metrics and monitoring
AI capabilities	Anomaly-detection models running on the probe	AI capabilities
Configuration	The probe’s own settings, edited and applied from the browser	Configuration

Network status is the landing view, which tells you where the product thinks the centre of gravity is: what is out there, and is it exposed.

Next: The full loop — the four stages a single observation travels through.