IEC 62443-2-3 (Patch management in the IACS environment), explained

IEC TR 62443-2-3:2015, "Security for industrial automation and control systems — Part 2-3: Patch management in the IACS environment," is the part of the IEC 62443 series that addresses one of the hardest operational problems in OT security: how an asset owner and an IACS product supplier actually exchange, test, approve and track patches without breaking a running plant. Published in 2015 as a Technical Report rather than a normative International Standard, it describes a patch lifecycle model, recommended requirements for both sides of the relationship, and a structured data-exchange format — filling a gap that sits between IEC 62443-2-1's asset-owner security program and the vulnerability-handling expectations referenced across the rest of the series.

Why patching an IACS is a different problem than patching IT

The Introduction frames the issue directly: many organizations already run well-established information security management systems under ISO/IEC 27001 and ISO/IEC 27002, but applying that IT-style cyber security strategy to an IACS "without understanding the consequences" can cause harm — "successful attacks against industrial systems may lead to health, safety and environmental (HSE) consequences" that a pure IT patching program never has to weigh.

Clause 4.1 catalogs the practical obstacles: preparing an IACS to be patched "can require a tremendous amount of work," since each patch for each product means gathering and analyzing patch information, installing and verifying on a test system, backing up before and after, retesting, and documenting the change. Because of that overhead, most organizations schedule patching around existing maintenance outages — sometimes quarterly, yearly, or less often — and "some extremely critical systems may not have outage windows available and can therefore not be patched if a system outage is required to do so." The report is explicit that applying a patch is a risk-management decision: "if the cost of applying patches is greater than the risk evaluated cost, then the patch may be delayed," particularly where other compensating controls already mitigate the risk.

Clause 4.2 states the consequence of getting this wrong plainly: poor IACS patch management increases "the risk of loss or compromise of an IACS system," and unlike office systems, that compromise "may impact system safety, the physical safety of operational personnel, the quality of produced products, the safety of produced products and the usability of produced products." Clause 4.3 adds a second, longer-running problem: IACS equipment often stays in production "for decades," so asset owners regularly face patches that no longer exist for obsolete, unsupported hardware and need other mitigations when patching simply isn't an option.

The patch lifecycle: eleven states, two owners

Clause 4.4 and Table 1 define the lifecycle every patch moves through, split by who manages each state:

Patch state	Definition (per Table 1)	Managed by
Available	Provided by a third party or IACS supplier but not yet tested	Asset owner / Product supplier
In Test	Being tested by the IACS supplier	Product supplier
Not Approved	Failed supplier testing; not to be used unless later Approved	Product supplier
Not Applicable	Tested and found not relevant to IACS use	Product supplier
Approved	Passed supplier testing	Product supplier
Released	Released for use by the supplier or third party, or directly applicable to internally developed systems	Asset owner / Product supplier
In Internal Test	Being tested by the asset owner's own testing team	Asset owner
Not Authorized	Failed internal testing, or found not applicable	Asset owner
Authorized	Released by the asset owner and meets internal standards (or didn't need testing)	Asset owner
Effective	Posted by the asset owner for use	Asset owner
Installed	Installed on the system	Asset owner

Figure 1 draws this as a state-transition diagram: the IACS product supplier's states sit in the dark-gray left half (Available → In Test → Approved/Not Approved/Not Applicable), feeding into the asset owner's light-gray right half (Released → In Internal Test → Authorized/Not Authorized → Effective → Installed). Knowing which state every patch for every device currently sits in — not just whether it has been "installed" — is the document's core operational idea.

What asset owners and suppliers are each asked to do

Clause 5 sets out what it calls an "implied obligation to uphold the safety, reliability, operability, security and quality" of operations, translated into recommended practice. IACS asset owners should, verbatim:

1. Maintain an inventory of every device that can be updated — modified in functionality, configuration, operation, software, firmware or operating code — referred to as "updatable" devices.
2. Record the installed version currently running on each device.
3. Determine, on a regular schedule, the latest version available for each device.
4. Determine the released versions the IACS product supplier has identified as compatible and that meet the asset owner's own standards.
5. Test patch installation in a way that "accurately reflects the production environment," so reliability and operability aren't harmed once the patch reaches the real system — patches that pass become "authorized."
6. Schedule authorized, effective patches for installation "at the next available opportunity," respecting system-design constraints (redundancy, fault tolerance, safety) and operational ones (planned or unplanned outage windows, on-process operation).
7. Update records at least quarterly, covering installed, authorized, effective and released versions for every updatable device.

Clause 6 mirrors this with a shorter set of recommended requirements for the IACS product supplier side of the relationship, and Clause 7 defines how the two sides exchange patch information in the first place (see below). The source preview used for this guide covers the full scope, lifecycle model and Clause 5 asset-owner text verbatim; Clause 6's supplier-side list, Clause 7's exchange-format detail and the Annex B/C step-by-step implementation guidance (asset-owner guidance runs to roughly 30 pages; supplier/service-provider guidance to several more) sit in the purchased IEC text — see the webstore link below.

The VPC exchange format

Clause 7 and Annex A specify "Vendor Patch Compatibility" (VPC): a defined XML/XSD-based file format and filename convention so a supplier can tell an asset owner, in a machine-readable way, which patches apply to which of the supplier's products. Table 2 through Table 5 of the standard define the PatchData, PatchVendor, Patch and VendorProduct file elements that make up a VPC file. This is the most dated part of the document: published in 2015, it predates the CSAF/VEX-based machine-readable advisory formats that have since become the more common way vendors publish patch-applicability data across the broader security industry — see CSAF/VEX for device makers. IEC has not withdrawn or revised 2-3 to reconcile the two formats, so a shop choosing an exchange format today should weigh VPC as one historical option rather than assume it is current best practice.

Where it sits in the IEC 62443 series

62443-2-3 is a Technical Report in the series' "Policies and procedures" (2-x) group, alongside 2-1 (asset owner security program), 2-2 (implementation guidance for an IACS security management system — itself still under development) and 2-4 (requirements for IACS suppliers and service providers). Its two normative references are IEC TS 62443-1-1 (terminology, concepts and models) and IEC 62443-2-1 (the asset owner's security program, which 2-3's patch management activities feed into as one of its supporting processes). 2-3 deliberately stays out of vulnerability-disclosure ethics and process — that ground is covered by ISO/IEC 29147 and 30111 (see the CVD process explained) and by each asset owner's own IACS security management system.

A workable starting point

1. Build the updatable-device inventory first — Clause 5's installed/latest/released/authorized tracking is impossible without a baseline list of every device that can receive a patch; this is also the foundation IEC 62443-3-2's risk assessment and zone/conduit partitioning need.
2. Separate "authorized" from "installed" — a patch that has passed your internal test and met your standards (authorized) is not yet deployed (installed); conflating the two states hides how much of your fleet is actually current.
3. Plan around outage windows explicitly, don't default to "later" — Clause 4.1's observation that some critical systems have no outage window at all means the mitigation-when-patching-isn't-possible question (Clause 4.3, and Annexes B.4.5/B.4.6/B.8.5) has to be answered up front, not improvised after a vulnerability is disclosed.
4. Don't expect 2-3 to cover vulnerability disclosure or the gap period — Notes 1 and 2 to its own scope clause explicitly exclude both; pair this document with your CVD process and your IACS security management system for that part of the problem.
5. Treat VPC as one option, not the default — if you're choosing a patch-applicability exchange format today, compare the 2015 VPC schema against current CSAF/VEX practice rather than assuming 2-3 reflects the current state of the art.

SoftWSP's OT Snapshot builds the passive asset inventory that IEC 62443-2-3's "updatable device" tracking in Clause 5 depends on, and helps triage which discovered CVEs map to patches actually worth prioritizing against your outage windows: see OT Snapshot.

This guide quotes IEC's own published preview text of IEC TR 62443-2-3:2015 (foreword, introduction, scope, definitions, Clause 4 and Clause 5) and the IEC webstore's catalogue record; it is not a substitute for the purchased standard, where Clause 6, Clause 7's full detail and the Annex B/C implementation guidance should be confirmed, and does not constitute compliance or legal advice.