IEC 62443-2-3 Patch Management in the IACS Environment

ISA/IEC TR 62443-2-3 gives guidance for building a patch management programme in an Industrial Automation and Control System (IACS) environment. It sits in the series under Policies & Procedures and is aimed at anyone designing or running IACS patch processes — typically asset owners working with product suppliers and service providers.

Patch management here is the structured cycle of finding, evaluating, testing, approving, deploying and verifying software updates so known vulnerabilities shrink — without sacrificing safety, reliability or availability.

Why IACS patching is hard — and still essential

Plants often run continuous processes with infrequent outages, long equipment life, vendor-certified software stacks and safety-related systems. That leaves years of known weaknesses exposed if updates never land. Attackers weaponise newly published vulnerabilities quickly, and older malware still succeeds on unpatched hosts.

At the same time every patch is a change. Changes can affect safety, reliability, certification and performance. Deployment therefore belongs inside change and configuration management — not as an ad-hoc IT push.

Patching is resource-heavy: skilled people, representative test beds, careful documentation and scarce maintenance windows. Coordinated effort keeps systems secure and functional.

Patch management is not a spectator sport

No single party can secure an industrial system alone. Effective IACS patching is a shared responsibility — asset owners, integrators, maintainers and product suppliers (plus the service providers and IT/OT teams that support them) all have active roles.

Coordination is what makes patches tested properly, downtime limited, and the plant both secure and operable.

A business imperative (risk management, not only tech)

Reference: Themes from ISA-TR62443-2-3, Annex B

Build the business case — operational, financial and cybersecurity benefits of a managed patch programme.
Educate decision makers — executives and IT/OT leaders need to see why patching reduces exposure and protects integrity.
Treat patching as risk management — part of the organisation’s broader risk strategy, not a standalone technical chore.
Weigh risks versus benefits — structured assessment of whether security/reliability gains outweigh operational risk, cost and downtime.

Asset owner requirements — the five lifecycle stages

Reference: ISA-TR62443-2-3, Figure B.1 (as taught in patch-management training)

Asset-owner work spans five continuous stages. Under Information Gathering, owners also assess the existing environment, categorise and classify assets, maintain inventory, manage supplier relationships and understand supportability.

Stage	Typical activities
1. Information gathering	Assess the live environment; inventory assets; classify criticality; map suppliers and supportability.
2. Monitoring & evaluation	Monitor and identify patches; decide applicability; run risk assessment; make the install / defer / reject decision.
3. Patch testing	Confirm file authenticity; review change content; define install and removal procedures; qualify and verify behaviour; plan risk mitigation / compensating controls.
4. Patch deployment	Notify stakeholders; prepare systems; schedule windows; deploy via change control.
5. Verification & reporting	Verify success and side-effects; complete training and documentation.

Teaching point: Industrial patches should not go straight into production. Testing covers authenticity, impact review, install/rollback procedures and qualification that control, comms, HMI and safety behaviour remain acceptable. Where install must wait, compensate (segmentation, tighter filtering, monitoring, reduced attack surface).

Installation timeframes after vendor approval

Reference: ISA-TR62443-2-3, Figure B.5 (reference guidance)

Once the IACS vendor has approved a patch, organisations often use a risk-based target window. The table is a reference pattern for building plant-specific guidelines — not a universal SLA.

Priority	Example target after vendor approval
High	Within 1 week
Medium (default)	Within 3 months
Low	Within 2 years or the next available outage
None	Never install

Align deployment with internal change management — approval cycles can lengthen real calendars.
Prefer planned windows. Applying patches during an unplanned outage can add risk when the plant is already degraded.

Product supplier / service provider requirements

Reference: ISA-TR62443-2-3, Annex C themes

The product supplier should have a policy covering patch management for its own product and vulnerabilities in software the product depends on.

Discovery of vulnerabilities

Procedures covering discovery sources (for example penetration testing, automated tools, static code evaluation).
Defined frequency for discovery / identification work.
Analysis of exposure, end-user impact, root cause and change complexity.

Development, verification and validation

Create and validate a mitigation for each relevant vulnerability.
Provide compensating controls asset owners can use to shrink the attack surface when updates are slow or impractical.

Distribution of cybersecurity updates

Make updates available over a secure channel within a reasonable timeframe.
Point to patch sources for third-party software embedded in the product.
Account for enterprise update mechanisms (for example WSUS) and evolving OS vendor release patterns (traditional “Patch Tuesday” plus out-of-band releases).

Communication and outreach

Make the patch management policy available to the asset owner.
Address asset-owner communications in supplier patch documentation.
Provide timely technical assistance and clear paths to report suspected attacks or vulnerabilities.
Communicate lifecycle / support status to asset owners and system integrators.

Relationship within the 62443 series

Document	How it connects
TR 62443-2-3	Primary guidance for IACS patch management programmes.
62443-2-1	Asset-owner Security Program — patching supports ongoing SP / CSMS discipline.
62443-2-4	Service-provider security programme requirements for integration and maintenance work.
62443-4-1 / 4-2	Secure development and component capabilities that make quality updates possible.
62443-3-3	System requirements that often assume sustained vulnerability handling in operation.

OT patch decision factors and DMZ update pattern

Asset owners must decide whether the benefit of a patch outweighs cost and operational risk. Typical questions:

Is the vulnerable equipment actually present (requires an up-to-date inventory)?
Does the vulnerability apply to this deployment?
What is the outage, labour and regression-test cost?
Are compensating controls already in place (prevention and detection)?
Would replacement be safer than patching an end-of-life device?

A common Windows-update pattern places a patch server (for example WSUS) in a plant or enterprise DMZ: the server pulls from the enterprise / Internet side, then distributes approved updates to OT clients through the firewall. Installation may be automatic, scheduled or manual based on criticality. Dedicate OT-qualified people to validate patches in a representative test environment before production deployment.

Key takeaways

TR 62443-2-3 frames IACS patching as shared, lifecycle-based risk management.
Asset owners run five stages from inventory through verification; suppliers discover, fix, distribute and communicate.
Priority windows after vendor approval are a starting pattern — customise them, and respect MoC and planned outages.
Where patches cannot land soon, use compensating controls and document the risk decision.

Standards reference

ISA/IEC TR 62443-2-3 — Patch management in the IACS environment (primary).
Annex B — Asset-owner process themes (including Figure B.1 lifecycle and Figure B.5 timeframe guidance).
Annex C — Product supplier / service provider expectations.
ISA/IEC 62443-2-1 — Security Program requirements for asset owners.

Learning objectives