Skip to content
Skip to contentNexus Observatory

Keys and PKI: a certificate authority in its vault issuing to the fleet, keys in hardware. The loop, step by step: 1. A root key sleeps in a two-module vault. 2. The chain from source to console stands ready. 3. A node asks for a new certificate. 4. The request reaches the issuing authority. 5. Relays carry the packets without reading them. 6. The authority’s module signs the certificate. 7. The certificate returns to the node. 8. The console shows the evidence with the alert. 9. Signatures are checked before any model runs. 10. Old keys rotate on a fixed schedule. 11. The edge releases confirmed results only. 12. Revoked keys are listed for every verifier. 13. Instruments confirm the response took effect. 14. The whole chain is archived for audit. 15. Everything settles back to idle.

01 / 15

A root key sleeps in a two-module vault

Nexus Observatory

/

Security and trust

/

Keys and PKI
Issuance, rotation and post-quantum migration.

Keys and PKI, inside Security and trust: key management lifecycle, hardware security modules, ML-KEM key encapsulation, ML-DSA and SLH-DSA signatures and more. Every item is traced to its specification, from NIST SP 800-57 Part 1 Rev. 5 to FIPS 140-3, and runs on the open Observatory Protocol.

Plan with usArchitectureThe protocol
Technologies
8
At the frontier
3
Protocol functions
4 of 12
Industries served
5

At a glance

Key management lifecycle

Generation, distribution, rotation, backup and destruction of keys. In keys and PKI, part of Security and trust, the keys, cryptography and post-quantum migration layer holds key management lifecycle, drawn against NIST SP 800-57 Part 1 Rev. 5 and used beside revocation and status checking on the same sites.

Inkinga

Issuance, rotation and post-quantum migration

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

Specification
NIST SP 800-57 Part 1 Rev. 5
Specification
NIST FIPS 203 (ML-KEM)
Specification
FIPS 140-3 · ISO/IEC 19790
Specification
IETF RFC 7030 (EST) · IETF RFC 8555 (ACME)
Specification
IETF RFC 5280

Components

  • Rugged shock-isolated 7U transit rack case, lids off
  • 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

Radio
Ethernet
Time and position
PTP (IEEE 1588)

Where it works

  • ML-KEM key encapsulation
  • Automated certificate enrolment

In the story below

  1. The system, part by part
  2. Assembly
  3. Installation
  4. Deployment
  5. Connections
  6. Operation
  7. Failure and recovery
  8. Scale and federation
  9. What you get

Scenes · 13

Next steps

Plan a deploymentOpen the Field Deployment StudioSee Security and trustRead our security approach

  1. Security and trust · Keys and PKI

    Issuance, rotation and post-quantum migration

    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.

  2. What it does

    Key management lifecycle

    Generation, distribution, rotation, backup and destruction of keys. In keys and PKI, part of Security and trust, the keys, cryptography and post-quantum migration layer holds key management lifecycle, drawn against NIST SP 800-57 Part 1 Rev. 5 and used beside revocation and status checking on the same sites.

    Specification
    NIST SP 800-57 Part 1 Rev. 5

  3. Keys

    ML-KEM key encapsulation

    Lattice-based key establishment that resists quantum attack. In keys and PKI, part of Security and trust, the keys, cryptography and post-quantum migration layer holds ML-KEM key encapsulation, drawn against NIST FIPS 203. We build it into every site for keys and PKI against that standard, and keep its version and its test results on the site’s record.

    Specification
    NIST FIPS 203 (ML-KEM)

  4. Keys

    Hardware security modules

    Validated modules that hold root and signing keys. In keys and PKI, part of Security and trust, the keys, cryptography and post-quantum migration layer holds hardware security modules, drawn against FIPS 140-3 and ISO/IEC 19790 and used beside hybrid key exchange on the same sites.

    Specification
    FIPS 140-3 · ISO/IEC 19790

  5. PKI, secure boot and updates

    Automated certificate enrolment

    Issuing and renewing device and service certificates without manual steps. In keys and PKI, part of Security and trust, the PKI, secure boot and updates layer holds automated certificate enrolment, drawn against IETF RFC 7030 and IETF RFC 8555. We build it into every site for keys and PKI against that standard, and keep its version and its test results on the site’s record.

    Specification
    IETF RFC 7030 (EST) · IETF RFC 8555 (ACME)

  6. PKI, secure boot and updates

    Certificate profiles

    X.509 certificate and revocation list profiles used across devices and services. In keys and PKI, part of Security and trust, the PKI, secure boot and updates layer holds certificate profiles, drawn against IETF RFC 5280 and used beside ML-DSA and SLH-DSA signatures on the same sites.

    Specification
    IETF RFC 5280

  7. Ubufakazi

    Traced to its specifications

    We trace each part of keys and PKI to its specification: NIST SP 800-57 Part 1 Rev. 5, IETF RFC 5280 and FIPS 140-3. We keep the versions, configurations and test results of keys and PKI as signed records, so a buyer or an auditor can check what was delivered against what was specified.

    Amazinga
    NIST SP 800-57 Part 1 Rev. 5 · IETF RFC 5280 · FIPS 140-3 · ISO/IEC 19790

  8. Operations

    Every node watched, every incident closed

    The operations console shows every node of a network for keys and PKI with its state, its plan and its evidence. An alert arrives with its data and a runbook, acknowledging it opens a work order, and an incident for keys and PKI closes only when the operator records the cause and verifies the fix.

  9. Failure and recovery

    When a node fails, the fleet knows first

    When a node for keys and PKI goes silent or a sensor drifts, the node buffers its data and fails over to a second link where the site has one. The alert carries the evidence a responder needs, and the record for keys and PKI loses nothing and counts nothing twice.

  10. Izibuyekezo

    Updates in rings, with rollback

    Software and configuration reach a fleet for keys and PKI in rings: one canary site first, then a few, then all, each ring gated on health and data completeness. A failed gate stops the wave, and each node for keys and PKI returns to its last good release without a site visit.

  11. How it scales

    One base unit, repeated

    A network for keys and PKI starts with one base node and the instruments it reads. A station adds power and radio, a site adds a relay and a fleet repeats the proven site, so capacity for keys and PKI grows by adding units, never by replacing what works.

  12. 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 approachTalk to sales

  13. Next step

    Keys and PKI, planned with you

    Tell us the sites, the systems keys and PKI must work with and the outcome you need, with a map or a list of addresses if you have one. An engineer replies with a survey proposal, a design and a scope for keys and PKI, and the plan grows from one site to the network you need.

    Plan a deploymentOpen the Field Deployment StudioSee Security and trust

More presentations

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

In depth

Use case Utility grid-edge private LTE and wildfire weatherISIC section · ISIC B Mining and quarryingSector IndustrialISIC section · ISIC F Construction

Explainers

Explainer · Industrial IndustrialBlast vibration at the pit, fire weather at the grid edge, methane at the fenceline and tailings movement from GNSS.Inkundla Security and trustEvery unattended node is an entry pointInkundla Sensors & instrumentsA number without its story

Stories

Story · Private 5G and AI-RAN Private 5G with the inference in the radioA private cellular network gives a site its own coverage, its own security and its own priorities. AI-RAN adds a second idea: the accelerators that run the…Story · Post-quantum cryptography Cryptography that outlasts the quantum computerData signed today may need to be trusted in 2040. Post-quantum standards were first published in August 2024, and governments have set dates for leaving…Story · Timing and PNT Time as infrastructureA 5G cell must hold its phase within 3 µs of its neighbours, ±1.5 µs of a common reference; a synchrophasor’s one per cent vector error leaves room for only…

Places and networks

Guided tour · Guided 3D tour Transmission corridorLattice towers carry a line across open country; conductor sensors report temperature and sag, and the substation edge brings them into the grid operator’s systems.Guided tour · Guided 3D tour Open-pit mineGNSS slope monitors on the benches, a blast seismograph at the boundary and a private cell for the fleet, around a benched pit cut into the ground.Network scene · Private 5G · Mining Private 5G in an open-pit mineA private network for haul trucks, drills and slope radar: a mast on the rim, a cell in the pit, the core at the plant, and coverage computed over the benches themselves.

Heritage observatories

Heritage observatory · Global network of about 150 stations; USGS and EarthScope (formerly IRIS) partnership · 1984 Global Seismographic NetworkAbout 150 digital broadband seismic stations in some 80 countries, sending data to open archives within minutes.Heritage observatory · Italy (historic building on the slopes of Vesuvius) · 1841 Vesuvius ObservatoryFounded in 1841 on the slope of Vesuvius, this is the oldest volcano observatory in the world.

Interactive tools

Interactive tool · Plan a site Field Deployment StudioTerrain, devices, coverage, viewshed, power and the best spot for a station, then a deployment request with the plan attached.

01Yini

Keys, cryptography and post-quantum migration.

How every node proves what it is and what it runs, how links and keys are protected, how software is traced to its source, how personal data is minimised, and how incidents are found and handled. Each technology below carries what it is, what we do with it, and the standard it is drawn against.

Security, identity and trust

Key management lifecycle

Generation, distribution, rotation, backup and destruction of keys.

We design, integrate and operate.

NIST SP 800-57 Part 1 Rev. 5

Security, identity and trust

Hardware security modules

Validated modules that hold root and signing keys.

We design, integrate and operate.

FIPS 140-3 · ISO/IEC 19790

Frontier · Security, identity and trust

ML-KEM key encapsulation

Lattice-based key establishment that resists quantum attack.

We design and integrate.

NIST FIPS 203 (ML-KEM)

Frontier · Security, identity and trust

ML-DSA and SLH-DSA signatures

Post-quantum signatures for firmware, plans and certificates.

We design and integrate.

NIST FIPS 204 (ML-DSA) · NIST FIPS 205 (SLH-DSA)

Frontier · Security, identity and trust

Hybrid key exchange

Combining classical and post-quantum key exchange during transition.

We design and integrate.

IETF TLS hybrid key exchange design (Internet-Draft)

Security, identity and trust

Certificate profiles

X.509 certificate and revocation list profiles used across devices and services.

We design.

IETF RFC 5280

Security, identity and trust

Automated certificate enrolment

Issuing and renewing device and service certificates without manual steps.

We design, integrate and operate.

IETF RFC 7030 (EST) · IETF RFC 8555 (ACME) · IETF RFC 9483 (lightweight CMP profile)

Security, identity and trust

Revocation and status checking

Withdrawing trust in a lost or compromised device quickly.

We design and operate.

IETF RFC 6960 (OCSP) · IETF RFC 5280 (CRLs)

02Architecture

Where it sits, and what it speaks.

Keys and PKI draws on the spectrum below; the highlighted layers carry this area, and the protocol functions it speaks are marked.

Device identity and attestation

8

PKI, secure boot and updates

7

Zero trust and network security

7

5G and wireless security

6

OT security and software supply chain

9

Privacy and data protection

7

Keys, cryptography and post-quantum migration

9

Monitoring, incident response and governance

8

01Joyina Identity, attestation quote, signed policy.

02Admit Admitted for a stated scope, nothing wider.

03Chaza What, where, how and by whom, with calibration.

04Time One clock across the grid, with its error bound.

05Observe Every value with quality and provenance.

06Qualify Tested against the specification, state on record.

07Federate Signed exchange across grids and trust domains.

08Orchestrate Software and configuration by signed plan.

09Correct A correction marks what depends on it and publishes a new version.

10Exchange Products reach people and applications through versioned interfaces.

11Prove Signed proof receipts that an independent verifier can check.

12Exit and decommission An open exit path, and a record that closes.

03On the grid

Every site joins one observing grid.

The open networks on the grid today, over real relief and the geodesic cells we count them into. A site built here enrols into the same grid.

The observing grid

  1. Open instruments on the observing grid.

04In the field

Where this runs, sector by sector.

Deployment scenarios from the sector research that rely on keys and PKI.

Defence-adjacent (civil dual-use)

Critical-infrastructure resilience sensing

Utility and pipeline monitoring under grid-security rules.Government and public safety

National GBON surface and upper-air network

WMO-grade stations reporting through WIS 2.0, funded through the systematic-observations financing pathway.Government and public safety

Wildfire camera network and fire-weather stations

Camera towers with edge inference and co-located fire-weather stations, utility- or agency-funded.Government and public safety

Urban street-flood sensor network

Open-hardware depth sensors with open data and alerts to emergency management.Government and public safety

Alerting integration with the Common Alerting Protocol and cell broadcast

Software-heavy: sensor triggers feed an alert origination tool; the alert authority keeps every decision.Government and public safety

Deployable communications and sensing for incident command

A cell on wheels with satellite backhaul, mesh telemetry and environment nodes at the incident base.

05Open and enterprise

Open by default. Enterprise by contract.

The open counterpart lives on the main site for anyone to read and run. The enterprise service is designed, deployed and operated with you, under contract.

Open, on the main site

  • Threat model for observing sites
  • Attestation profile in the protocol

Enterprise, on this site

  • Operational-technology assurance
  • Security monitoring for observing sites
  • Key and PKI operations

06The rest of the line

Security and trust, area by area.

Security and trust

Identity and attestation

Hardware roots of trust, quotes checked at every join.Security and trust

Segmentation and zero trust

Least privilege between nodes, tenants and sites.Security and trust

OT and wireless security

Field networks, 5G and the software supply chain.Security and trust

Monitoring and response

Detect, contain, recover, with the evidence kept.

Bring us the site.

Survey, design, deployment and operation for keys and PKI. The form names who receives your details.

Talk to usAsk for a quote
Skip to content

Issuance, rotation and post-quantum migration.

Keys and PKI, inside Security and trust: key management lifecycle, hardware security modules, ML-KEM key encapsulation, ML-DSA and SLH-DSA signatures and more. Every item is traced to its specification, from NIST SP 800-57 Part 1 Rev. 5 to FIPS 140-3, and runs on the open Observatory Protocol.

01Yini

02Architecture

Where it sits, and what it speaks.

03On the grid

04In the field

Where this runs, sector by sector.

05Open and enterprise

Open by default. Enterprise by contract.

The open counterpart lives on the main site for anyone to read and run. The enterprise service is designed, deployed and operated with you, under contract.

Open, on the main site
    Enterprise, on this site
      06The rest of the line

      Bring us the site.

      Talk to us