OT & ICS Security in Regulated Manufacturing
Operational technology is the layer of computerised systems that senses and moves physical things: the PLCs holding an interlock closed, the DCS sequencing a batch, the SCADA screen an operator acts on, the historian the batch record is reconstructed from. Securing it is not a smaller version of securing IT. The priorities invert, the equipment outlives several generations of the software it runs, and every protective action collides with GMP change control. ISA/IEC 62443 is the engineering series written for exactly this problem, and it maps onto the qualification lifecycle a regulated site already runs.
What an explainer is not
A topic explainer is SPEQ’s synthesis of what a practice involves, cited to the standards that govern it. It does not reproduce their text, and it does not determine which of them apply to your product or process.
[ POSITION IN THE FRAMEWORK ]
7 DIMENSIONS · 23 LINKSOperational technology inverts the IT priorities: availability and integrity outrank confidentiality, patching windows are production decisions, and the device that cannot be taken offline is usually the one running the process.
06 · QUALITY MATURITY — OT & ICS SECURITY IN REGULATED MANUFACTURING, REACTIVE TO ADAPTIVE
Plant systems are on the corporate network because that is how they were installed. Nobody can list what is on the process network.
Segmentation exists as a drawing, and there are firewalls at the boundary — but engineering laptops, vendor connections and USB media cross it routinely.
Zones and conduits are defined from what the process needs, crossings are enumerated and controlled, and remote vendor access is brokered rather than standing.
The process network is monitored for what it should never see, and a change in traffic is investigated with the same seriousness as a change in a parameter.
Security is a property of the control system design: compromise of any one zone cannot move the process out of control, and that claim has been tested rather than argued.
SPEQ’s shared five-stage progression, labelled synthesis — not the FDA QMM rating scale. Where does your organization sit? Score your quality system →
07 · REGULATORY & EVIDENCE
GOVERNING STANDARDS · 5
Derived from the 5 standards SPEQ maps to this subject, across 4 regulatory bodies: FDA, EMA, ISO, IEC.
RECORDS & OBJECTIVE EVIDENCE
- An inventory of everything on the process network, including engineering workstations and instruments
- The zone and conduit model, with every approved crossing enumerated
- Remote access arrangements for vendors, including how sessions are brokered and recorded
- Removable-media controls, and evidence of their enforcement
- Monitoring records for the process network, with what constitutes an anomaly defined
COMMON INSPECTION FINDINGS
- Process control systems reachable from the corporate network without a controlled crossing
- Standing vendor remote access that is always on and unattributable to an individual
- Unmanaged engineering laptops moving between the process network and the internet
- No inventory, so the site cannot state what would be affected by a given vulnerability
- Segmentation asserted from a network drawing that predates several system additions
OT is not IT, and the difference is the whole problem
In an enterprise IT environment the usual ordering of security objectives is confidentiality, then integrity, then availability. In a control system it inverts: a loss of availability stops production or, worse, removes the operator’s view of a process that is still running, and a loss of integrity means the process is being controlled against values that are wrong. Confidentiality matters least — the setpoint of a lyophiliser is not a secret. Security controls designed on the IT ordering, applied unchanged to OT, routinely make things worse: an endpoint agent that quarantines a driver, a scanner that resets a PLC, an automatic reboot in the middle of a cycle.
The second difference is time. A packaging line commissioned with a control system in 2010 is expected to run into the 2030s, and the operating system underneath its HMI is part of a qualified configuration. Sites therefore run software that vendors stopped supporting years ago, not through neglect but because the supported replacement does not exist, or exists only as a control-system upgrade with its own qualification burden. Security work in OT is mostly the work of protecting things that cannot be fixed.
Zones, conduits, and security levels
The ISA/IEC 62443 series answers the exposure problem with segmentation. Assets that share a security requirement are grouped into a zone; every permitted path between zones is a conduit, defined explicitly, with everything else denied. A risk assessment assigns each zone a target security level, and IEC 62443-3-3 then states what a system must be capable of at that level, organised around seven foundational requirements: identification and authentication control, use control, system integrity, data confidentiality, restricted data flow, timely response to events, and resource availability. Security levels run 1 to 4 by the capability and motivation of the adversary assumed.
The common failure is not a missing firewall but a flat network. When the historian, the HMIs, the site business network and a vendor’s remote-support laptop all sit in one broadcast domain, a compromise anywhere reaches the controllers directly, and no amount of endpoint tooling recovers the containment that segmentation would have given for free. The value of the zone-and-conduit model is that it makes the reachable set of a control system an explicit, reviewable design decision rather than an accident of how cables were run.
Security requirements belong in the URS
IEC 62443-3-3 states its requirements so they can be verified rather than asserted, which is what makes it useful to a regulated site: a target security level for a zone can be written into the user requirement specification for a new automation system, flow through design review, and be tested at factory and site acceptance alongside functional requirements. Security that arrives after qualification is a change; security that is specified as a requirement is qualified once, with the rest of the system.
IEC 62443-2-1 covers the other half — the security programme the asset owner operates for a system already in service. It is the part a manufacturer owns directly: asset inventory, risk assessment, access control including remote and third-party access, patch and backup arrangements, monitoring, and incident response. Its supplier-facing counterparts sit elsewhere in the series, which is worth knowing when a vendor offers a certificate: a product certification says something about what the supplier built, not about how the site runs it.
Patching under change control
Every security patch on a GxP control system is a change to a validated system and enters change control with an impact assessment. Two anti-patterns follow. The first is treating that as a reason not to patch at all, which converts an assessable risk into an accumulating one. The second is treating each patch as a full revalidation, which makes the cadence so slow that the queue never clears. The defensible position is a risk-based patch policy agreed in advance: a standing assessment of which patch classes are low-impact and re-verified by a defined regression set, which require targeted requalification, and which are deferred with a documented compensating control such as tighter segmentation or removal of a service.
The GMP hooks are already there. EU GMP Annex 11 requires physical or logical controls restricting access to authorised persons, backups whose restore capability is checked during validation and monitored periodically, and continuity provisions for systems supporting critical processes. 21 CFR 211.68(b) requires controls assuring that changes to master production and control records or other records are made only by authorised personnel. Neither text prescribes a network architecture — which is why the engineering series is the practical answer to a requirement the GMP rules state as an outcome.
SPEQ interpretation — the asset inventory is the control that unlocks the rest
Segmentation, patching, monitoring, and validation scoping all presuppose a complete list of what is installed, how it connects, and what it is for. In practice the inventory is where OT security programmes stall, because the interesting assets are the ones nobody owns: a serial converter behind a panel, a vendor-supplied balance with an embedded PC, an engineering laptop that is the only machine with the programming software on it.
SPEQ’s view is that this register should be the same one Annex 11 already expects. A regulated site maintains an inventory of computerised systems with a GxP impact assessment; an OT security programme maintains an asset inventory with a criticality assessment. Where these are kept as two lists, they diverge, and the divergence is discovered during an incident. Maintaining one register with both attributes costs less than reconciling two, and it means the GxP criticality of an asset is visible at the moment a security decision is being made about it.
FREQUENTLY ASKED
Is ISA/IEC 62443 required by GMP regulators?
No. No GMP regulation cites it. EU GMP Annex 11 and 21 CFR 211.68 state security and access-control outcomes without prescribing how they are achieved, and 62443 is the engineering series practitioners use to achieve them. Certification against it is a commercial and assurance decision, not a regulatory expectation — though the 2025 draft revision of Annex 11 treats cybersecurity as a core GMP requirement more explicitly than the 2011 text does.
What is the difference between IEC 62443-2-1 and 62443-3-3?
62443-2-1 sets out the security programme an asset owner operates for a control system in service — governance, asset inventory, access control, patching, monitoring, incident response. 62443-3-3 sets out what the system itself must be capable of, expressed against seven foundational requirements and assigned a security level. One is how you run it; the other is what you buy or build.
Does a security patch require revalidation?
It requires change control with a risk-based impact assessment, which is not the same as full revalidation. The proportionate approach is a patch policy agreed in advance that classifies patch types by impact and defines the verification each class needs, so that routine patches clear through a defined regression set and only changes touching GxP-relevant function trigger targeted requalification.
Does ISO/IEC 27001 cover operational technology?
It can, but it does not supply control-system engineering requirements. ISO/IEC 27001 is a management-system standard: it governs how an organisation assesses risk and selects controls, and its scope statement decides whether OT is inside or outside the certified boundary. Many sites certify an ISMS scoped to corporate IT and then discover the manufacturing network was explicitly excluded. 62443 supplies what the ISMS does not.
Why can OT systems not simply be kept patched like IT systems?
Because the software is part of a qualified configuration on equipment with a service life measured in decades, the vendor’s supported version may only exist as a control-system upgrade, and patching windows are limited to planned shutdowns. The result is that risk is managed by containment — segmentation, restricted data flow, controlled remote access — as much as by remediation.