Security and trust: every node proving what it is before it joins, keys held apart. The loop, step by step: 1. Every device and site proves who it is. 2. The chain from source to console stands ready. 3. A station presents its device identity. 4. Each reading is stamped with time and place. 5. The security module signs the claim. 6. The attestation crosses the radio link. 7. Relays carry the packets without reading them. 8. Signatures are checked before any model runs. 9. The verifier checks it against policy. 10. The edge releases confirmed results only. 11. The edge accepts the station into the grid. 12. The console shows the evidence with the alert. 13. Its readings are trusted from this moment. 14. Sensors check that the response worked. 15. The whole chain is archived for audit. 16. Everything settles back to idle.

01 / 16

Every device and site proves who it is

Nexus Observatory

Security and trust

Every node proves what it is.

Hardware-rooted identity and attestation at every join, PKI, secure boot and signed updates, segmentation between nodes, tenants and sites, operational-technology and wireless security, monitoring and response, and the move to post-quantum keys, planned before it is forced.

Plan with usReference architectureThe open protocol

At a glance

Every node proves what it is

Security and trust delivers hardware-rooted identity and attestation at every join, PKI, secure boot and signed updates, segmentation between nodes, tenants and sites, OT and wireless security, monitoring and response, and a planned move to post-quantum keys. Security is part of how the system works, not a product added afterwards, and it is visible in every record.

Die probleem

Every unattended node is an entry point

Field devices sit in public places, run for years and join networks that also carry control traffic. A single unverified node or unsigned update can reach far beyond the sensor it came with. Security has to be built into how every node joins, updates and reports, because nobody can guard unattended sites in person.

Key facts

Praktyk: IEC 62443 zones and conduits · zero trust
Roots of trust: TPM 2.0 · secure boot · measured boot

Components

Pole-mounted edge gateway node
Fixed gas detectors on a drift wall
Particulate monitoring station and sensor node
Overhead line sensor on a distribution span
Private LTE mast on a solar skid
“AI tower in a box”
Hardware security module, 1U, in an edge rack
Data hall row pair with cold-aisle containment

Interfaces

Instrumente: SDI-12 · RS-485 / Modbus RTU · 4–20 mA
Radio: Ethernet · LTE-M / NB-IoT · LoRaWAN
Time and position: GNSS 1PPS
Security: TPM 2.0
Publishing: MQTT

Where it works

Least privilege between zones

In the story below

The system, part by part
Assembly
Installation
Deployment
Connections
Operation
Failure and recovery
Scale and federation
What you get

Scenes · 18

Next steps

Plan a deployment Read our security approach Talk to sales See OT and wireless security

Die probleem
Every unattended node is an entry point
Field devices sit in public places, run for years and join networks that also carry control traffic. A single unverified node or unsigned update can reach far beyond the sensor it came with. Security has to be built into how every node joins, updates and reports, because nobody can guard unattended sites in person.
What it does
Every node proves what it is
Security and trust delivers hardware-rooted identity and attestation at every join, PKI, secure boot and signed updates, segmentation between nodes, tenants and sites, OT and wireless security, monitoring and response, and a planned move to post-quantum keys. Security is part of how the system works, not a product added afterwards, and it is visible in every record.
Keys and PKI
Issuance, rotation and post-quantum migration
Keys are issued and held in hardware security modules, rotated on schedule and revoked on evidence. Migration to post-quantum algorithms is planned inventory first, so it is not forced in a hurry. Key events are recorded and auditable, and keys never leave the hardware that protects them.
See Keys and PKI
The system
One station, part by part
Before anything is installed, the station is laid out as its parts: instrument, logger and edge compute, secure element, GNSS timing, radio, power, enclosure, wiring, earthing, mast and foundation.
Assembly
Built and tested before it ships
Each part is fitted to the pole and the enclosure, wired through surge protection to one earth, powered and bench-tested until it signs its first reading.
Installation
Installed on site
The crew arrives with the tested kit: foundation, mast raised and guyed, instruments mounted, cables run in conduit, the enclosure fitted out and the site commissioned.
Deployment
Site after site, one design
The same station goes in at every site on the plan, each commissioned against the same checklist, until the field is covered.
Wiring
Signal, power and time, wired
Inside one site the instrument’s signal pair runs to the logger, solar charges the battery that feeds the load, GNSS time reaches the clock and the logger hands its records to the radio.
Segmentation
Least privilege between zones
Observing networks and control systems are separate zones joined by defined conduits, following IEC 62443. Data crosses one way, read-only by default, through a gateway and a firewall with every rule recorded. Rules are written down, reviewed and tested, and every change to them is recorded with who approved it.
Praktyk
IEC 62443 zones and conduits · zero trust

See Segmentation and zero trust
Connections
Backhaul, time and power
The relay carries every site to the edge over a point-to-point link, the grandmaster’s time reaches every clock, and each site keeps its power through the night.
Identity and attestation
Quotes checked at every join
Each node holds a key in a hardware root of trust. When it joins, it sends a signed quote of its boot chain and software; the network admits it only if the quote matches an approved state. A node whose quote does not match is quarantined and its keys withheld until it is restored to an approved state.
Roots of trust
TPM 2.0 · secure boot · measured boot

See Identity and attestation
Bewyse
Proof an auditor can check
Admissions, key events, updates and incidents are kept as signed records. An auditor can verify them independently against published keys and the threat model. Evidence is designed to stand on its own, so trust in the system does not depend on trust in its operator.
Operations
Security monitoring for observing sites
A security view sits beside the fleet view: attestation state, certificate expiry, failed joins and rule changes, each with its record. Expiring certificates and failed joins are acted on before they become outages or openings for an attacker. Every alert links to the node, the event and the evidence.
Monitoring and response
Detect, contain, recover
Anomalies in behaviour, traffic or attestation raise an alert; the affected node is isolated, restored to a known state and readmitted only after attestation, with the evidence kept. Response playbooks are rehearsed, and every incident leaves a timeline that can be reviewed afterwards.
See Monitoring and response
Supply chain
Signed updates, known contents
Every release is signed and ships with a software bill of materials; nodes refuse unsigned code and report what they run, so a vulnerability can be matched to exactly the nodes that carry it. When a new vulnerability is published, the affected nodes are known within minutes, not after a manual survey.
See OT and wireless security
How it scales
The same proof at every scale
Attestation, keys and segmentation work the same for one site or thousands: policy is defined once and enforced at every join, every update and every boundary. New sites inherit the policy on day one, so growth never opens a gap in the defences.
What you get
Assurance, monitoring and key operations
The threat model for observing sites and the attestation profile in the protocol are open. Operational-technology assurance, security monitoring and key and PKI operations are contracted. Pricing follows the sites, the keys and the monitoring you choose, and the threat model stays yours.
Read our security approach Talk to sales
Next step
Review your attack surface
Tell us the sites, the networks and the systems they touch. We start with a threat model and an inventory of keys. The review ends with a prioritised list of fixes, the evidence behind each one and an owner for every action.
Plan a deployment Read our security approach

See it from every side.

Each opens as a full-screen presentation: deeper pages on the same subject, explainers, stories, guided tours of the places, network scenes and the observatories that came before.

All presentations