Articles
Engineering·7 min read

What is design-time cyber engineering?

Most OT security tools answer the same question: what do we have, and what is wrong with it today? Design-time cyber engineering asks a different one: is this architecture defensible before we build it?

A definition

Design-time cyber engineering is the practice of designing, validating and proving the cyber-resilience of an industrial system as part of the engineering phase, before it is built, procured or commissioned, rather than assessing it after it is already running.

It treats the security architecture (zones and conduits, security levels, data flows, the threat model, residual risk) as structured engineering data that can be authored, checked against IEC 62443 and NIS2, simulated, and handed to acceptance testing as a reference model. The output is not an alert; it is a defensible design and the evidence that supports it.

Runtime asks a different question

The mature, well-funded part of the OT security market operates in the operate phase. Asset-visibility platforms discover what is on the network. Vulnerability tools report which of those assets are exposed. Detection systems watch the traffic for the signature of an attack in progress. All of it is essential, and all of it begins after the system already exists. By then the architecture is fixed: the zones are drawn, the conduits are cabled, the flat network is live.

The engineering lifecycle

Design

zones, conduits, security levels

Build

integration, addressing, cabling

Commission

FAT / SAT, acceptance

Operate

monitoring, detection, response

Nearly all OT security software acts in the final phase. Design-time cyber engineering acts in the first three, where the architecture is still a decision, not a constraint.

Where runtime security asks what do we have, and what is wrong with it today?, design-time cyber engineering asks is this architecture defensible before we pour the foundations? The two are not competitors. They are different phases of the same lifecycle, and one of them has had little dedicated tooling.

A discipline, not a document

Security has always been considered at design time, in a sense. A consultant runs a workshop, marks up a Visio diagram, writes a zone-and- conduit assessment, and delivers a PDF. The thinking is sound; the form is the problem. A document cannot be queried, cannot be re-checked when the design changes, and drifts out of sync with the as-built record the day after it is signed. The design intent and the real system diverge, and the rigour is lost.

What turns design-time work into engineering is the model. When the architecture is structured, queryable data rather than a picture, the same artefact the engineer draws is the artefact that gets checked: automatically, repeatably, and the moment a decision is made. A flat network spanning two zones, a missing DMZ between enterprise and OT, a conduit that permits everything, a zone with no assigned security level: these become deterministic findings on a canvas rather than opinions raised in a room.

What it produces

The discipline is defined by its deliverables. A design-time cyber engineering pass should hand the project, before anything is built:

  • A checked zone-and-conduit architecture: partitioned per IEC 62443, with a target security level on every zone and conduit.
  • A threat model: mapped to STRIDE and ATT&CK for ICS, tied to the assets and flows it actually threatens.
  • A prioritised risk register: inherent and residual risk, the controls in place, an owner and a treatment decision, ranked and signed off where residual risk is accepted.
  • Compliance evidence: the design mapped to IEC 62443 and NIS2 obligations, generated rather than assembled by hand.
  • A reference model to commission against: so FAT and SAT verify the system that was actually designed, not a memory of it.

None of these is a report about the past. Each is an input to a system that does not yet exist.

Why it matters now

Two forces are moving the emphasis to design time. The first is regulatory: under NIS2, operators of essential services are expected to manage cyber risk by design and to evidence that they did, not to discover the gaps at an audit after go-live. Design-time is where that evidence is cheapest to produce and most credible to present.

The second is the nature of the asset. Industrial systems live for fifteen to twenty years, vendor-locked and change-controlled. You cannot patch a protection relay mid-season or re-segment a live substation on a whim. The decisions taken on the design canvas are, in practice, the decisions you keep. That is also why the economics of fixing a flaw at design time are so asymmetric, a point we cover separately in the economics of secure-by-design OT.

Design-time cyber engineering reframes a question the industry has often asked the wrong way round. The goal was never only to watch critical infrastructure more closely once it was built. It was to build it defensible in the first place, and to be able to prove it.

See design-time cyber engineering in practice

Open the 20-asset wind-farm reference and watch the zone, conduit and security-level checks build on the canvas, along with the prioritised risk register.

Launch Synapse Studio