TroutTrout

ICS Security Advisories Read for the plant floor, not the patch queue.

CISA ICSA bulletins, analysed for operators

CISA publishes ICS advisories most weeks, and almost none of them arrive with a fix you can deploy this quarter. This is the archive of the ones we have taken apart, plus what contains a flaw you cannot patch.

Last updated:

The short version

An ICS advisory is CISA's public notice that a vulnerability has been found in industrial equipment: a PLC, an HMI, a SCADA server, an engineering tool. It carries an ICSA identifier, the affected products and versions, a CVSS score, and the vendor's recommended action. The gap between that document and a safer plant is the part nobody writes down. Industrial equipment is patched on maintenance windows measured in quarters, sometimes years, and some of it will never receive a fix at all. So the operational question is almost never when do we patch. It is what stops someone reaching this device in the meantime.

The archive

Advisories we have analysed

Each entry takes one CISA bulletin and answers the same three questions: what the flaw actually allows, whether it is reachable in a normal plant network, and what contains it when the vendor fix is not available to you yet.

How to read one

What an ICSA number tells you before you open it

The identifier is structured, so a feed of them can be triaged without reading every bulletin end to end.

Part
ICSA
What it is
The advisory class
Why it matters
ICSA is a standard industrial control systems advisory. ICSMA covers medical devices. An ICS-ALERT is faster and less complete, used when something is being exploited right now.
Part
26
What it is
The year
Why it matters
Two digits. ICSA-26-225-01 was published in 2026.
Part
225
What it is
The day of the year
Why it matters
Day 225 is mid-August. This is why advisory numbers arrive in clusters: CISA publishes in batches, most often on Tuesdays and Thursdays.
Part
01
What it is
The sequence that day
Why it matters
ICSA-26-225-01 and ICSA-26-225-06 came out together. A high sequence number means a busy release day, not a more serious flaw.

Severity lives in the CVSS score inside the bulletin, never in the identifier. A CVSS 9.8 and a CVSS 4.3 look identical from the outside.

Triage

Five questions that decide whether an advisory is urgent for you

Most advisories that land in an operator's inbox are not urgent and a few are. These separate them faster than the CVSS score does.

  1. 01Do you actually run the affected version?

    Vendors list affected firmware precisely, and operators rarely hold an inventory precise enough to answer. If checking takes longer than a day, that inventory gap is the real finding, not the advisory.

  2. 02Is the device reachable from anywhere a person could stand?

    A flaw in an HMI that only answers inside an isolated cell is a different problem from the same flaw on an HMI a vendor dials into. Reachability, not severity, is what makes a bulletin urgent.

  3. 03Does exploitation need credentials, and who holds them?

    Many ICS advisories require an authenticated session. That turns the question into who has accounts on this device, which is usually a longer list than anyone expects and often includes a shared integrator login.

  4. 04Is there a fix you can actually deploy?

    A patch that requires a controller restart in a continuous process is not available to you this quarter. Treat it as absent and plan the compensating control instead of waiting.

  5. 05If it were exploited, would you know?

    For most OT estates the honest answer is no. That answer, rather than the advisory itself, is what should drive the next budget conversation.

The usual answer

Containing a flaw in a device you cannot patch

When the fix is months away or never coming, the remaining move is to change who can reach the device and what they are allowed to do once they get there. Enforcement in front of an asset does not require touching the asset.

  • Put an identity check in front of the device, so reaching it needs an authenticated, MFA-backed session even though the device itself supports neither.
  • Constrain the protocol rather than the port. Most of these advisories are exploited through a legitimate protocol doing something a normal operator never does, which is visible at the application layer and invisible at the firewall.
  • Scope every remote session to one asset, one task, one time window, so a compromised vendor laptop reaches one machine instead of a subnet.
  • Record the sessions. If the flaw is exploited through an authorised path, a replay is the only evidence that will exist afterwards.
  • Segment down to the asset rather than the level, so the blast radius of an unpatched controller stops at that controller.
How to read one

Advisory questions

10

Advisories analysed here in depth, out of the several hundred CISA publishes each year.

It is a public bulletin from the US Cybersecurity and Infrastructure Security Agency describing a vulnerability in industrial control equipment. It names the vendor and the affected versions, gives a CVSS score, describes the attack scenario, lists the affected critical infrastructure sectors, and states the vendor's recommended mitigations. Advisories carry an ICSA identifier, for example ICSA-26-225-01, and are published in batches most weeks.

Most weeks, usually in batches on Tuesdays and Thursdays, running to several hundred a year. The batching is why advisory numbers arrive in clusters: ICSA-26-225-01 through ICSA-26-225-06 were all published on the same day. A busy release day says nothing about how serious any individual bulletin is.

No, and they nest. A CVE is the identifier for one specific vulnerability, assigned centrally. An ICS advisory is CISA's operator-facing write-up, and it usually covers several CVEs in one product at once, adds the industrial context a raw CVE record lacks, and names the sectors affected. One ICSA number commonly carries three or four CVEs.

Assume that is the normal case rather than the exception, and change the reachability of the device instead of its firmware. Put an authenticated, protocol-aware checkpoint in front of it so reaching the flaw requires an identity you control, restrict which protocol commands are allowed through, time-box and record every remote session, and segment so an unpatched controller cannot become a route to anything else. None of that depends on the vendor shipping anything.

Not on its own. CVSS scores the flaw, not your plant. A CVSS 9.8 on a device behind an authenticated proxy, with no route from anywhere a person could stand, is a lower operational risk than a CVSS 6.5 on an HMI a vendor dials into with a shared credential. Reachability and who holds the credentials decide urgency; the score only sets the ceiling.