The ownership question comes first
Nearly every stalled industrial security programme has the same root cause: nobody agreed who owns it. The security team owns the mandate but cannot touch plant equipment. Operations owns the equipment but is measured on uptime and output, not on risk. Engineering owns the change process that both depend on and is usually the most resource-constrained of the three.
The arrangement that works in practice is joint: security sets the policy and owns the risk register, operations retains the veto on anything touching production, and engineering owns the change window through which all remediation flows. What fails is a security team issuing findings into operations with no shared definition of what warrants a change window.
Settle this before selecting tooling. A platform cannot resolve a disagreement about who is accountable, and an evaluation run without operations in the room will be repeated.
IT and OT do not disagree about security, they disagree about cost
The familiar framing is that IT cares about confidentiality and OT cares about availability. That is true but it obscures the real friction, which is that the two groups price downtime completely differently. An hour of degraded email is an inconvenience. An hour of stopped production has a number attached, and in continuous process industries a restart can take considerably longer than the outage that caused it.
Progress comes from putting that number into the risk model rather than arguing about priorities in the abstract. Once cost per hour offline sits on the asset record alongside the vulnerability count, the two teams are looking at the same scale and the argument becomes tractable.
Scoring risk when patching is not available
Conventional vulnerability management assumes remediation is possible. In an industrial estate it frequently is not: the vendor has not released a fix, the fix voids a certification, or the next change window is eight months away. A programme built on severity alone produces a backlog that only grows and that nobody believes in.
Signal scores every asset from zero to one hundred across five factors, with the breakdown visible rather than hidden behind a single number. Crucially, compensating controls subtract from the score, so a device behind strong segmentation with monitored access is rated on its defended posture rather than on raw severity.
- Vulnerability exposure, weighted by CVSS, EPSS and CISA KEV rather than CVSS alone
- Asset criticality, taken from the CMDB record including SIL rating where one applies
- Network exposure, from peer breadth, zone crossing and reachability
- Compensating controls, which subtract from the score rather than adding to it
- Recent anomalies, decayed over time so an old finding stops dominating
Compensating controls are the real remediation
When patching is unavailable, the programme's actual output is compensating controls: segmentation that limits reachability, monitored and time-boxed remote access, application allow-listing on workstations, and detection coverage over the assets that cannot be hardened.
The failure mode is that these get implemented and never recorded, so at audit there is no evidence that a decision was made rather than a deadline missed. Recording the control against the asset, with who approved it and when it is next reviewed, turns an eighteen-month patch delay from a finding into a documented risk acceptance.
What maturity actually looks like
Industrial security programmes tend to progress through a recognisable sequence, and skipping a stage rarely works because each one supplies the input the next depends on.
- Inventory. You know what is on the network, passively and continuously, rather than from a spreadsheet maintained by hand.
- Segmentation. Zones and conduits are defined, and you can tell whether observed traffic conforms to them.
- Detection. Something is watching the industrial traffic and raising findings a human reviews.
- Response. There is an agreed path from a finding to an action, including who can authorise one during production.
- Evidence. Compliance is produced continuously from operational data rather than assembled before an audit.
Converging without merging
IT and OT security convergence is often described as merging two teams into one. In practice the durable model keeps the operational separation and merges the visibility: one security operations view across both domains, with the OT specialists retaining authority over what happens on the plant floor.
That is the shape Spharaka is built to. Signal collects and analyses industrial telemetry with OT-specific decoding and OT-appropriate constraints, and passes findings into Spharaka Sphere where they correlate with enterprise telemetry. One picture, one team seeing it, and no requirement that a corporate SOC analyst make judgement calls about a turbine.
Frequently asked questions
Who should own industrial cybersecurity?
Jointly, with clear boundaries: security owns policy and the risk register, operations holds the veto on anything touching production, and engineering owns the change window through which remediation flows. Programmes fail most often when security issues findings into operations without a shared definition of what justifies a change window.
How do you manage risk on equipment that cannot be patched?
By scoring defended posture rather than raw severity. Signal weights vulnerability exposure, asset criticality, network exposure and recent anomalies, then subtracts for compensating controls, so a device behind strong segmentation with monitored access is not ranked alongside an equivalent device sitting exposed.
What is IT and OT convergence?
In practice it means unifying visibility rather than merging teams. One security operations picture spans both domains, while OT specialists keep authority over plant-floor decisions. Merging the teams outright tends to fail because the operational judgement required on the plant floor is not transferable.
How do we justify OT security spend to operations?
Put cost per hour offline onto the asset record alongside the security data. Once both teams are reading the same scale, the conversation moves from competing priorities to a shared number, and the case for a change window becomes arguable on operational terms rather than security ones.
Where should a programme with no OT visibility start?
With passive inventory. Every subsequent stage, segmentation, detection, response and evidence, depends on knowing what is actually on the network, and passive discovery is the only way to establish that in a production environment without a change window.
How do compensating controls hold up in an audit?
Well, provided they were recorded. A control implemented and documented against the asset, with the approver and a review date, evidences a deliberate risk acceptance. The same control implemented and never written down is indistinguishable from a missed deadline when an auditor asks.
Part of the cluster
OT Cybersecurity
The pillar page for operational technology security.