Find out what is really there, then prove where it breaks.
Before anyone draws a zone or writes a recommendation, we find out what is actually on the network and how an attacker would move across it: the identity stack, the firewalls, the remote-access paths, the servers and the cloud tenant. Where there is a control network, we listen to it for long enough to know what talks to what, and on a live process that means a mirror port and patience, not a scanner. What you get back is a map, a list of where it breaks, and the cost of fixing each one.
Why it matters
Most organisations already have segmentation and an access model on paper. The question a buyer actually has is which of it the firewalls, the directory and the cloud tenant agree with, and what the rest would cost to make real. A generic PDF of CVEs does not answer that, and it is what a lot of assessments hand over.
Many of the paths that matter run through identity: a reused password, an over-privileged service account, a certificate template nobody reviewed, a remote-access path with no MFA. We follow those paths the way an attacker would, and we say which of them reach something you cannot afford to lose.
The office network can be patched on a Tuesday. A control network often cannot. Where a site has both, we assess both, and we do not pretend they tolerate the same things. IT and OT sit in the same report, on different rules.
What it covers
- Asset and exposure inventory
- What is actually on the network and what faces the internet: servers, endpoints, network devices and cloud workloads, and on a control network the SCADA servers, HMIs, PLCs and gateways found passively from a SPAN or TAP. Including the parts we could not see, and why.
- Identity and access
- Active Directory and Entra ID, privileged and service accounts, AD CS certificate templates, MFA and conditional access, and how remote users, administrators and vendors actually get in.
- Segmentation, zones and conduits
- Firewall and VLAN segmentation reviewed against what the traffic shows. On a control network, zone and conduit design to IEC 62443-3-2 with security levels and an industrial DMZ, each conduit expressed as a firewall rule set with a reason per rule.
- Detection and recovery readiness
- Whether the logs you would need during an incident are collected and kept, whether endpoint and network monitoring would see the attack paths we found, and whether the backups survive a domain compromise.
- Consequence-driven risk
- A risk register scored by what the failure actually costs the organisation or the process, not by a generic CVSS number in isolation.
How it runs
Listen
Configuration exports, a directory and tenant review, and passive collection on the network, long enough to see the conversations that only happen at month end, at shift change or overnight. On a live process, collection is passive only.
Map
The estate as it really is: trust boundaries, identity paths and data flows. Reference models such as Purdue are a vocabulary, not a description of your network, so the drawing is of yours.
Assess
Gaps against a framework you choose, each traced back to something we found in a config, in the directory or on the wire rather than to a checklist item. IEC 62443 and NIST CSF give us the vocabulary, and we use them as a design language, not as a certificate to sell you.
Cost and hand over
A prioritised, costed roadmap, an executive summary for the person who signs the budget, and the drawings and register underneath it. What now, what next window, what can wait.
A page of what you are handed
ARTA CYBER
Representative deliverable — site and figures redacted.
Asset inventory, as-found — excerpt
| Host | Role | Zone | Firmware | Observed talking to | How found / not seen |
|---|---|---|---|---|---|
| 10.20.3.11 | Historian (primary) | L3 | 2019 build, unpatched | HMI-01/02 (OPC UA), enterprise reporting (SQL) | SPAN on core; confirmed by name in OPC handshake. |
| 10.20.2.41 | PLC, filter bank A | L1 | v3.2 (Modbus) | HMI-01 (Modbus TCP, 2s poll) | Passive only. Not scanned: live process. |
| 10.20.2.42 | PLC, filter bank B | L1 | unknown | silent during capture | No traffic in the 6-day window. Flagged for a walk-down, not assumed absent. |
| 10.20.3.5 | Engineering workstation | L3 | Windows, domain-joined | All PLCs (programming), enterprise AD | Dual-homed. This is the OT/IT bridge; raised as a critical finding. |
What you are left holding
- Asset inventory: device, role, zone, exposure, observed conversations and how it was found, including the parts we could not see and why.
- Identity and attack-path summary: the routes from an ordinary account to the assets that matter.
- Network and data-flow drawings as-found.
- Segmentation model, and on a control network, zones and conduits with security levels.
- Gap assessment against a named framework, each gap traced to a finding.
- Risk register scored by consequence.
- Prioritised, costed remediation roadmap.
- Executive summary written for the budget holder.
Worked to
- IEC 62443-2-1
- IEC 62443-3-2
- IEC 62443-3-3
- NIST CSF 2.0
- NIST SP 800-82r3
- CIS Controls v8.1
Where an assessment calls for an active check, we rehearse it first against virtual Modbus TCP and DNP3 devices in our OT Asset Simulator, so the version that runs near your live plant is one we have already watched behave.
OT Asset SimulatorQuestions we are asked first
Will the assessment disrupt production or a live process?
No. Directory and configuration review is read-only, network collection is passive, and on a live control process we use a mirror port, not a scanner. Anything active waits for a bench or a booked window, and we agree the out-of-bounds list with you before we start.
Do we get a generic list of CVEs?
No. Every gap is traced to something we saw on your wire, and every recommendation carries the cost of doing it and the consequence of not. A risk register you can take to the budget meeting is the point of the exercise.
Do you cover the corporate side and the control side, or just one?
Both, and we keep them separate on purpose. The report says which findings are IT-side, which are OT-side, and which live on the boundary between them, because they do not tolerate the same fixes.
We are an Ontario electricity distributor. Can you map to the OEB standard?
Yes. The Ontario Cyber Security Standard and the framework under it are one of the references we can assess against, alongside IEC 62443 and NIST CSF 2.0. We map to whichever one you report against.
Related work
Tell us what is bothering you.
An email is enough to start with. A scoping call is free and there is nothing to commit to, and where we are not the right people we will say so and point you at someone who is.
A first call about one site. No charge, and nothing to commit to.
Our named next step: we come to one site and hand you an assessment you can act on.