Your security architecture should outlive your security vendor

OT security runs on two clocks

The mature names in OT cybersecurity (Dragos, Claroty, Armis, Tenable OT Security) all live on the runtime clock. They sit on the plant network, watch traffic, discover assets, and tell you what is there and what is already wrong. That work is essential, and it is not the work Synapse does.

Synapse runs on the design clock. Before a cable is pulled, an integrator partitions a site into zones and conduits, assigns a target security level to each, and has to prove the architecture is defensible. The runtime tools answer “what do we have, and is it compromised?” The design clock answers a different question: “is what we are about to build correct in the first place?”

Two clocks means the relationship between Synapse and the incumbents is not competitive, it is complementary. And complementary tools need a way to exchange one thing above all: a shared, trustworthy inventory of what the site is made of.

Why we didn't start with a vendor API

The obvious move is to pick the market leader and build a connector to its API. We looked hard at exactly that, and the closer we looked the less sense a vendor-first integration made as a foundation.

• There is no shared contract: each platform models assets differently, and most gate the authoritative API spec behind a partner-program login. A connector to one buys you nothing for the next.
• The data flows one way: every incumbent exposes a read-oriented API to pull discovered inventory out. None offers a documented way to push an as-designed zone-and-conduit model in. So a design tool cannot “write its architecture” to them regardless.
• The de-facto normaliser is someone else's product: in practice, organisations reconcile multi-vendor OT inventory inside ServiceNow's CMDB, via a separate connector per vendor. Normalisation already happens, just not in an open format.
• Our user often doesn't run the console: the systems integrator producing 62443-3-2 deliverables is rarely the SOC analyst logged into the monitoring platform day to day.

Building the foundation on a single proprietary API would have locked us into chasing four or five changing endpoints to obtain data that has no common shape, on behalf of users who mostly work upstream of those tools. That is a fragile base for a product whose whole premise is durable, evidenced engineering.

A neutral interchange layer

So we inverted the order. The baseline is not a connector, it is a format: a vendor-neutral projection of the design that any counterparty can read, and that no single vendor owns. One export path serves many destinations, and the burden of speaking each proprietary dialect moves to a thin adapter at the edge rather than into the core of the product.

The principle is simple. Own the artifact that no standard yet provides, emit it in formats the wider ecosystem already consumes, and treat any live vendor API as a convenience layer added later, on a customer's request, not as the load-bearing foundation.

A 62443 design as a bill of materials

The carrier we chose is CycloneDX, the OWASP bill-of-materials standard now published as ECMA-424. Its hardware-BOM (HBOM) profile explicitly covers industrial control systems, and its property mechanism lets us annotate every component with the facts a flat inventory loses. From a checked Synapse model we emit each asset as a device, its firmware as a nested component, and its 62443 context (zone, Purdue level, target security level, criticality, addressing, the conduits it speaks through) as namespaced properties.

{
  "type": "device",
  "bom-ref": "a-grid-relay",
  "name": "Grid Protection Relay",
  "components": [
    { "type": "firmware", "bom-ref": "a-grid-relay/firmware",
      "name": "SEL-451 firmware", "version": "R320" }
  ],
  "properties": [
    { "name": "synapse:zone:kind",   "value": "ot-grid" },
    { "name": "synapse:purdueLevel", "value": "0" },
    { "name": "synapse:slT",         "value": "3" },
    { "name": "synapse:criticality", "value": "critical" },
    { "name": "synapse:ipAddress",   "value": "172.16.140.11" },
    { "name": "synapse:service",     "value": "DNP3/20000" },
    { "name": "synapse:conduit",     "value": "SCADA \u2194 Grid" }
  ]
}

The asset attributes themselves line up with the emerging consensus vocabulary (manufacturer, model, firmware, addressing, protocols, criticality, location), the same core fields national guidance now asks every OT asset inventory to carry. The 62443 layer on top is what makes it a security artifact rather than a parts list: a downstream system does not just learn that a relay exists, it learns which zone the relay belongs to, what security level that zone targets, and which declared conduit its traffic is permitted to cross.

Honest inventories: assumed means incomplete

Real designs are rarely fully confirmed. When an architecture is built up from a site walkdown, some assets are entered by an engineer and some are inferred and still awaiting confirmation. A bill of materials that hides that distinction is misleading, because it reads as certainty it does not have.

CycloneDX has a native concept for exactly this: compositions describe how complete an assembly is. So we map this distinction straight onto the standard. Confirmed assets land in a composition marked complete; walkdown-inferred, not-yet-confirmed assets land in one marked incomplete. A consumer that knows the format will treat the second group as provisional automatically, without us inventing a private flag, and the signal stays machine-readable rather than decorative.

As-designed versus as-built

This is where the two clocks finally meet, and where the neutral format pays for itself. Synapse holds the as-designed model: the intended zones, the conduits that should exist, the security levels that were targeted. The runtime platforms hold the as-built reality: what is actually on the wire, talking to what. The useful question is the gap between them: the segment that bridges two zones it never should, the flow no conduit ever authorised.

The one real precedent in the market frames this as intent versus observation, and tellingly it derives intent from configuration files, not from a design tool. A portable, machine-readable statement of design intent is the missing half of that comparison. Emit the design as a neutral inventory, line it up against the discovered inventory, and the drift becomes a report instead of an argument.

Where the vendors come in

None of this means the incumbents are an afterthought; it means they plug in cleanly. With the neutral model as the contract, each integration becomes a small adapter that translates to or from one platform's dialect, rather than a bespoke rewrite of the core.

When we build the first live adapter, it will most likely be Tenable OT Security. It is the one incumbent whose data model already speaks our language natively: Purdue level and criticality as first-class fields, a zone-and-conduit framing, and an openly documented API with a published SDK. Claroty is the natural fast-follow, because its asset records carry zone and criticality and it exposes communication baselines, which is precisely the raw material for comparing observed segmentation against a designed one. Dragos and Armis follow the same adapter pattern when a deployment calls for them.

The order matters more than the names. Build the portable artifact first, and every vendor becomes an adapter. Build the vendor connector first, and every vendor becomes a migration. We would rather your security architecture outlive any one tool we happen to integrate with this year, including ours.