Operational technology in the ISMS, without a second inventory
A controller is not a server, and the question "what security level does our production have" has no single-digit answer. IEC 62443 requires zones with a shared protection need, conduits as the only permitted paths between them, and per zone a security level that is a vector across seven foundational requirements: target and achieved, per FR 1 to FR 7. The module keeps exactly that, and it creates no second inventory for it: every OT device remains an IT system of the existing inventory with its networks, rooms, vulnerabilities and risks, and gains an OT profile with device type, Purdue level, firmware version, vendor support and safety relevance. Risk assessment, catalogue, remote access register, patch decisions and sensor alerts build on that.
A zone’s security level is shown as a vector, "SL 2 {3 2 2 1 2 1 2}", target and achieved kept apart. The gap is computed per foundational requirement and turns red as soon as it is greater than zero anywhere. If the zone has no achieved level, the minimum of the device capabilities applies, and without either there is no gap, only a notice.
2
The controller was not on the vulnerability list
IT systems carry no firmware version, so CSAF matching came up empty for controllers. The OT profile feeds vendor, product and firmware to the matching as candidates, and every hit becomes a patch decision with a deadline by severity. If the profile requires vendor approval, no change and no rollout target can be created without it.
3
A conduit without enforcement is an intention
Whatever runs between two zones and is in no conduit is a violation. Sensor alerts from Claroty, Nozomi or Dragos are placed into the zone model via the SIEM, observed traffic is held against the conduits in the communication matrix, and conduits with enforcement "none" are counted separately by the cockpit.
Capabilities
All capabilities at a glance
OT profile on the IT system: device type, Purdue level, zone, vendor, product, firmware, vendor support, safety and SIL, protocols, SL-C
Zones with zone type, Purdue level, hierarchy, network ranges and security level vector (SL-T, SL-A, gap per FR)
Conduits with direction, protocols and ports, enforcement means and conditions, mirrored into the firewall zone matrix
Cockpit and printable Purdue view across all levels
Risk assessment under IEC 62443-3-2 in five steps with target SL proposal, threat scenarios per ATT&CK for ICS and approval
IEC 62443-3-3 as an OSCAL catalogue: 7 FR, 108 requirements with minimum SL, mapped to ISO 27001, IND and NIS2
Evidence checks from the inventory with population and violations, adoption into the implementation statement
Remote access register under IND.3.2 with lifecycle, review interval and reconciliation against sessions of the remote support module
Patch decisions from CSAF hits: vendor approval, maintenance window, ITSM change or rollout target, compensation or acceptance
Sensor alerts via syslog, CEF, LEEF and JSON through the SIEM, placed into the zone model, conduit violations detected
Asset import from sensor CSV with presets for Claroty, Nozomi and Dragos
Communication matrix: observed traffic against the conduits, adoption with one click
Passive discovery by the agent via SNMP device profiles, active probing of OT ports only as an opt-in with a warning
Decoys for Modbus, S7 and OPC UA in the deception module
Zones attached to KRITIS installations, OT check keys in the NIS2 and B3S hospital catalogues
SL gap report across all zones, read-only AI tools for zones, assessments, grants and patch decisions
Result
Operational technology sits in the same ISMS as IT, with a security level that is evidenced per zone and foundational requirement rather than a single number on a slide.
Experience OT security live
Schedule a no-obligation demo – we will show you the module with your own use cases.