The unit of scope

A conduit is one network path
between two defined endpoints.

Plain language: a conduit is a single, named link between a computer and the physical equipment it can command — for example, the path between one building-management server and one chiller controller. That single path is what we scope, what we assess, and what we price: one conduit, fixed price after scope confirmation.

The assessment is fully passive. We read a copy of that path's traffic — SPAN, tap or PCAP you provide — and never sit in the packet path.

The unit of sale, defined

One conduit = one scoped path, two named endpoints.

Before any work starts we write down, on paper, which two endpoints the conduit runs between. Everything outside those endpoints is out of scope for that engagement.

What a conduit includes

One path, end to end

The traffic between the two endpoints we name in the scope document — typically a supervisory or management server on one side and one controller, gateway or device family on the other. From the traffic copy you provide, we decode the write-capable operations visible in that capture, resolve each to the logical point it targets, and map it to physical effect and worst-case consequence. The output is a register-consequence map your biomedical or plant engineer red-lines — corrections welcome, and expected. Their corrections are what make it real.
What a conduit is not

Not a site, not a subnet, not a product

A conduit is not your whole hospital, your whole VLAN, or every device of a given type. It is not software you install and run — there is nothing to deploy, license or keep alive. It is not monitoring, enforcement, penetration testing, safety certification or regulatory certification. Additional paths are separate conduits, scoped and quoted separately.
The design boundary

We never sit in the conduit we assess.

The one thing an OT engineer needs to hear first: we do not insert any element into your control path. We supply nothing that blocks, filters or forwards traffic. We work from a copy.

No new failure point

The assessment observes a traffic copy and nothing else. We never originate a control command and never transmit into the control network.

Nothing of ours to fail

Your traffic flows exactly as it did before, during and after the assessment. There is no Wardhelm element in the path whose failure could affect it.

And the blind spots, stated

A passive copy only shows what crosses that path: a mirror port can't see a serial leg, a local HMI cable, or an engineer at the panel. Those gaps are named in the report rather than papered over.

Evidence, not assertion

Findings are labelled by how we know them — observed · customer-provided · derived · not established — and bound to capture hashes and a hash-chained, Wardhelm-signed report.
How one conduit is assessed

Scope it, copy it, read it, hand it back.

Scope the conduit

Both endpoints named in writing, with you.

SPAN / TAP / PCAP

You provide an approved copy of that path's traffic.

Engineering context

Your engineer supplies and red-lines what the points mean.

Signed evidence package

A PDF your team owns and can verify without Wardhelm software.

Start with one conduit. See the exposure first.