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

/

/

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.

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.

The problem

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

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. Evidence

   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.

   Standards

   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. Updates

    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.

In depth

Explainers

Stories

Places and networks

Heritage observatories

Interactive tools

01What it is

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.

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

01Join Identity, attestation quote, signed policy.

02Admit Admitted for a stated scope, nothing wider.

03Describe 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.

04In the field

Where this runs, sector by sector.

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

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.

Bring us the site.

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