Security architecture

Security architecture and OT security consulting

We help companies control who, and what, can touch their systems.

Identity, zero trust and the boundary between your business network and the plant floor, designed by someone who has run both sides of it.

How we approach it

Most of the incidents we've seen up close didn't need a clever exploit. They used an account that had more access than its owner remembered, or a path between networks that someone opened for a project and never closed. Security architecture is mostly the unglamorous work of knowing who can reach what, and making sure the answer is short.

Identity comes first. One directory, one place to turn someone off, MFA everywhere it can go, privileged access kept apart from daily accounts, and Conditional Access that challenges when the signals warrant it instead of on every click. A user who approves twelve prompts a day has been trained to approve the thirteenth without reading it. Fewer, better prompts are a security control.

Zero trust follows from that. Being on the network shouldn't grant anything by itself. Each request is checked against who is asking, from what device, for what. In practice: segmentation, scoped remote access instead of a flat VPN, and logs somebody reads.

Industrial environments add the network nobody has mapped: controllers, historians, HMIs and vendor remote-access boxes that predate the security team, often on networks that were never meant to reach the internet and now do, indirectly. On live plants our rule is read-allow, write-deny. Telemetry flows out to the business through a controlled boundary, and nothing on the enterprise side can write to a controller. Operations still gets its data. An attacker on the office network doesn't get a path to the plant floor.

We design those boundaries with operations in the room, because a control that stops the plant will be bypassed by Friday.

What you get

What a first engagement looks like

  1. 1

    Discovery

    A fixed-scope review of identity and of every path between your business network and your operational systems.

  2. 2

    Fixed price

    You know the price before we start. We set it from the size and scope of the discovery, so it fits your organization rather than a one-size package. If we find something that would change the scope, we tell you first, and nothing extra happens without your OK.

  3. 3

    Written read-out

    A written document: what we found, what we'd do, what it costs, and what we'd leave alone.

  4. 4

    You decide, in writing

    Nothing moves to a build until you say yes in writing. Taking the read-out and doing the work yourselves is a fine outcome too.

Every engagement is led by a senior architect, and we bring in specialists from our bench when the work calls for them. After the first job, some clients keep us on as a fractional CIO or CTO for the decisions that keep coming.

Questions CIOs ask

Where do we start if we've never mapped our OT network?

With the paths, not the devices. Find every way traffic gets between the business network and the plant, including vendor remote access and the laptop that gets plugged in for maintenance. Closing an unknown path is worth more than cataloguing one more PLC.

Can we see plant data from the business side without exposing the controllers?

Yes. Telemetry crosses a controlled boundary in one direction, usually through a historian or a protocol-aware firewall that allows reads and denies writes. Operations keeps its dashboards, and the controllers stay unreachable from the office.

Is zero trust a product we buy?

No. It's a design principle you put in place with tools you mostly own already. In a Microsoft environment, Entra ID, Conditional Access, Intune and Defender cover a lot of it before you buy anything new.

How do we tighten security without our users revolting?

Fewer prompts, not more. Risk-based Conditional Access and passkeys let people sign in faster while the controls get stronger. Constant re-authentication trains people to click yes.

Do we have to replace legacy controllers to be secure?

Rarely as a first step. A controller that can't be patched can still be isolated, with the paths in and out controlled and watched. Replacement belongs in the capital plan, not the emergency plan.

An example

Prior experience

IT/OT separation for a distributed power-generation fleet

In an in-house leadership role at a power-generation operator, our founder built a standalone enterprise infrastructure and IT/OT separation roadmap: identity, network segmentation, cybersecurity, remote access, monitoring and documentation, brought together into an operating model the team could support.

It carried plant-to-enterprise data across SCADA, Modbus TCP/IP telemetry and PI historian pathways.

See the portfolio   Read the power-generation case study

Where this applies

Find the paths before someone else does.

A 1-hour architecture consultation on Microsoft Teams, times in ET.

Book a discovery call