Session CRT-20260720 — 20 July 2026

Let’s not start with “Russia means spend now.” That is too easy, and boards can smell reflexive security spending.

The decision is narrower: has the risk picture changed enough that a 2027 OT segmentation programme is no longer defensible, or can this operator carry the exposure into next year with strong interim controls?

The first questions I want the room to resolve are these:

• Alex: do Armored Likho’s reported intrusions and the FSB network-device warnings create a credible path from compromised perimeter or network devices into OT impact?
• Lena: is this a fresh campaign signal or a continuation of known Russian critical-infrastructure targeting?
• Elena: what is the geopolitical pressure behind this, but keep us honest — state interest alone does not prove imminent operational disruption.
• Pierre: what does acceleration actually buy the board in loss avoidance, outage risk, insurance, and capital trade-off terms?
• Sofia: if we hold the 2027 schedule and something happens before then, does that look defensible to regulators?
• James: you close us out with the practical answer — accelerate everything, accelerate only high-risk segmentation phases, or hold with compensating controls.

The board memo has to land on a recommendation, not a mood. By the end, I want one clear position and the evidence threshold that would make us change it by 1 October.

What sharpened here is that the board decision should not be framed as “new malware means accelerate everything.” The shared technical reading is much narrower and more actionable: the credible path to OT impact runs through stolen credentials, reverse tunneling, weak remote access, exposed network-device management, and a porous IT/OT boundary. Alex and Sara both pushed us away from a dramatic PLC-first scenario and toward the ordinary control-plane failures that let an attacker move from enterprise compromise into routers, VPNs, jump hosts, historians, firewall consoles, and the OT DMZ.

Lena’s confidence split matters. FSB Center 16 router targeting is high-confidence and long-running; it reinforces that router configuration theft, weak SNMP, Smart Install exposure, and management-plane abuse are not hypothetical. Armored Likho is the newer item for the board risk register, with moderate confidence as a distinct cluster and lower confidence on state sponsorship beyond the public Russian-speaking APT framing. So the new fact is not a transformed threat landscape; it is fresh reporting of energy-adjacent targeting using credential theft, RATs, and tunneling that maps uncomfortably well onto known weaknesses at many IT/OT boundaries.

Pierre’s economics landed in the same place as the defenders: Option 2 is the strongest board recommendation on the evidence we have. Pull forward the high-risk phases into H2 2026 — internet-facing exposure, IT/OT boundary controls, remote-access segmentation, and management-plane hardening — rather than dragging the entire 2027 capital programme forward or settling for monitoring-only. He also put a useful guardrail around the numbers: breach-cost and sector-loss figures support the seriousness of the risk, but they are not a precise ROI calculator for one operator, and there is no solid basis here to promise clean insurance savings.

The next turn is to test whether this technically sensible middle path is also defensible in the wider environment. We need geopolitical restraint so the board does not over-attribute Armored Likho, regulatory clarity on whether partial acceleration is enough to show due care, and a deeper look at identity and control-plane architecture because that is where today’s attack path keeps converging.

The important shift is that the risk case is now stronger, but still not a blank cheque for panic acceleration. Elena gave us a disciplined geopolitical frame: the Armored Likho reporting supports concern about access, persistence, credential theft, RATs, and reverse tunneling against electric-power-related targets, but not a verified destructive OT campaign. Separately, the FSB Center 16 warnings carry higher strategic weight because router exploitation, configuration-file collection, and critical-infrastructure targeting look like pre-positioning and contingency access. That means the board message should be elevated espionage and optionality risk — not “disruption before 2027 is the base case.”

Sofia’s regulatory lane tightens the governance point. A 2027-approved segmentation roadmap is not, by itself, a defensible answer if known adversary tradecraft is already exploiting the exact boundary, edge-device, and management-plane weaknesses that segmentation is meant to reduce. Holding the full schedule might still be defensible, but only with a clear risk-based exception file and compensating controls. Her NIS2 framing matters: the question is not whether the programme was once approved, but whether measures remain appropriate and proportionate after public allied warnings involving energy, network devices, and critical infrastructure.

Marcus then translated that into the identity and control-plane reality. The vulnerable path is not cinematic PLC exploitation; it is valid-looking access through shared accounts, vendor pathways, VPNs, jump hosts, IdPs, network-device consoles, and weak MFA assumptions. His emphasis on named human identities, removal of shared vendor/admin accounts, phishing-resistant MFA, privileged access management, monitored remote access, and tighter control over IT/OT administrative paths points to the phases that should move first if the operator does not accelerate everything.

So the room is converging on a middle option: do not re-baseline the entire 2027 OT segmentation programme just because new reporting exists, but do pull forward the high-risk boundary, remote-access, identity, and management-plane work into H2 2026. James should now close the technical decision: if we choose that selective acceleration path, what exactly belongs in the accelerated package, and what can safely remain on the original 2027 schedule without creating a false sense of control?

James has now put hard technical boundaries around the consensus. Option 2 is not simply “do a bit more segmentation sooner.” It only holds if the accelerated work is aimed at the actual near-term attack paths: OT boundary control, remote access, management-plane exposure, undocumented connectivity, and the ability to isolate safely under pressure.

The key caveat he added is important. If the environment still has direct vendor VPNs into OT, hidden routes, management systems that are protected only by the same controls they administer, or no tested isolation plan, then Option 2 is under-scoped. In that situation, the organization would be buying comfort rather than resilience, because an adversary could still move laterally or maintain command-and-control through exactly the pathways CISA and NCSC warn about. But James also gave us the opposite failure mode: if remote access is already centralized through a DMZ or gateway, OT links are outbound or brokered, management access is independently restricted, and the asset and connectivity record is trustworthy, then pulling forward the entire 2027 segmentation programme may be expensive theatre. It could consume outage windows, engineering time, and SOC attention without proportionate risk reduction.

So the room’s position is becoming more conditional and more defensible: accelerate the high-risk OT boundary, remote-access, and management-plane phases into H2 2026, but only after validating whether those specific weak paths exist. The recommendation is not “accelerate everything because the threat feels worse.” It is “accelerate what closes the plausible access paths, and do not spend scarce operational capacity on lower-yield segmentation until the evidence supports it.”

That sets up the next challenge well. We now need to test whether this defensible, outage-aware approach still underestimates the strategic signal from the threat reporting. In other words, does the renewed concern about Russian-linked targeting justify broader acceleration despite James’s engineering constraints, or is selective acceleration exactly the right balance between risk reduction and operational reality?

Pierre has narrowed the industry-impact argument in a useful way: this is not a claim that the whole threat environment has suddenly changed, or that OT disruption before 2027 should be treated as the default planning assumption. His point is more defensible and more conditional: if the operator has exposed OT paths — internet-facing assets, weak IT/OT boundaries, vendor remote access, or management-plane routes into sensitive environments — then deferring those controls until 2027 creates a board-level defensibility problem.

That matters because it keeps the room out of two bad extremes. On one side, we are not saying “accelerate everything because the sky is falling.” Lena and Elena’s caution still stands: current reporting does not prove a wholesale new threat condition that justifies pulling the entire segmentation programme forward. On the other side, Pierre is saying that known exposed pathways are not neutral backlog items. CISA guidance around removing OT from public exposure, hardening remote access, least privilege, and phishing-resistant MFA gives the board a clear benchmark for what reasonable near-term action looks like.

The regulatory point also sharpened. CIP-015-1, with NERC’s listed effective date of 1 October 2028, does not force a full H2 2026 segmentation sprint. But it does indicate where audit expectations are heading: better visibility into internal OT activity, anomalous behavior, and access pathways. So the case for Option 2 is not “regulation requires it now,” but “waiting on clearly exposed access paths may be hard to defend later.”

That sets up the next question cleanly. If Option 2 is the middle lane — accelerated, but targeted — then James needs to turn it into something a board can approve without ambiguity: what must happen in the first 30 days, what follows by day 60, what has to be in place by 1 October 2026, and what minimum monitoring is required so this is more than a segmentation label.

James has turned Option 2 from a vague “targeted acceleration” into an executable board lane: accelerate only the OT boundary, remote access, and management-plane controls, while leaving the broader 2027 segmentation programme on its original schedule unless predefined escalation triggers are met. That is an important narrowing. It gives the board something more practical than a binary choice between “do nothing until 2027” and “pull the entire programme forward into H2 2026.”

The first 30 days are framed as exposure control and visibility: freeze any new OT remote-access paths, sign off a complete inventory of ingress and egress routes, vendor connections, jump hosts, firewall rules, admin consoles, and privileged accounts, disable undocumented access, and require MFA plus named accounts for approved remote access. Then, by the 31–60 day mark, the lane moves into isolation and governance of administration paths: separate management planes from user networks, enforce jump-host and session recording for OT admin and vendor work, remove shared vendor credentials, log firewall and route changes, and validate rules against the inventory. James tied those moves back to established CISA and NCSC themes: reduce OT exposure, prefer brokered or DMZ-based external support, treat asset inventory as foundational, and recognize insecure remote access and weak segmentation as lateral-movement risks.

One caveat for the room: the response we have here clearly establishes the early implementation lane, but the action asked for the full path through 1 October, the minimum compensating monitoring while segmentation is underway, and the hard escalation triggers. The material we received appears to start that answer, but it does not fully expose all of those details in this packet. So we should treat the implementation lane as directionally strong, but not yet complete enough, by itself, to close the board memo.

That leads naturally to Sofia’s regulatory lens. If the technical recommendation is “targeted acceleration, not full programme acceleration,” the next question is what evidence, approvals, residual-risk wording, and trigger logic must be in the risk-acceptance file by 1 October so the board can defend the decision later.

Sofia has put a governance wrapper around the targeted-acceleration option: by 1 October, this cannot look like “we chose the cheaper delay.” It has to read as a documented, time-bounded risk decision with accountable owners, a defined accelerated scope, evidence for what is being left in 2027, and a sunset date on accepted residual risk.

The important shift is that regulatory defensibility is not just about citing NIS2 or saying the programme is proportionate. Sofia is saying the file needs to show the board actively understood the threat context — including the allied/FBI warning about FSB Center 16 targeting critical-infrastructure network devices — then made an explicit judgement about which OT pathways, remote-access routes, management-plane exposures, and network devices needed earlier treatment. That means current diagrams, crown-jewel pathways, internet-facing device inventory, SNMP exposure, end-of-life kit, VPNs, firewalls, jump hosts, vendor access, logging coverage, incident escalation, tabletop evidence, and insurance alignment all become part of the proof that this was reasoned governance rather than passive deferral.

There is still a caveat here: Sofia has not validated whether those artefacts currently exist, whether they are complete, or whether the compensating controls are operating effectively. She is defining the evidentiary standard the organisation would need to meet. If the inventory is partial, the diagrams are stale, or the monitoring is aspirational, then the same targeted option becomes much harder to defend.

That naturally takes us to the intelligence side of the 1 October review. If the board is going to accept residual risk for parts of OT segmentation until 2027, it needs pre-agreed triggers for reopening that decision. Lena’s next task is to define what new threat evidence would move this from “renewed known exposure plus a new actor cluster” into something that should force escalation beyond targeted acceleration.

Lena has turned the October review from a general “threat level” conversation into an evidence test for convergence. The key distinction she is drawing is this: more exposed routers, by itself, is not enough to justify pulling the whole 2027 segmentation programme forward. The threshold would be evidence that the router-compromise path and the Armored Likho or BusySnake-style endpoint path are starting to form one usable intrusion chain, or that the activity is moving toward operational disruption.

The strongest pull-forward triggers are therefore very specific. If the same victim environment shows both router compromise consistent with FSB Center 16 tradecraft and endpoint credential theft, RAT activity, or tunneling consistent with Armored Likho, that changes the picture. Likewise, if there is movement from enterprise IT into power operations, identity infrastructure, jump hosts, remote access platforms, or network management planes, the board would no longer be looking at parallel exposures; it would be looking at a credible bridge toward operational impact. Lena also highlighted geography and infrastructure reuse: repeated energy-sector targeting in our region, shared infrastructure, shared payloads, or common lure themes would matter far more than isolated cases elsewhere.

Just as important, she preserved the other side of the decision. If by 1 October the evidence still shows FSB Center 16 mainly exploiting older router weaknesses — weak or default SNMP, TFTP configuration theft, Smart Install or CVE-2018-0171 exposure — while Armored Likho remains a separate endpoint-focused concern, then the case for targeted acceleration remains defensible. That does not mean low risk. It means the available evidence would still support accelerating the highest-risk network-device, access, and monitoring controls rather than compressing the full segmentation programme.

The next question is the one boards often underweight: acceleration itself can create operational risk. Before the memo recommends pulling everything forward, we need Sara’s view from the ICS and OT side on whether forcing the full 2027 segmentation programme into H2 2026 could introduce safety, availability, testing, or change-control risks that are worse than a narrower acceleration path.

The safety point just got sharper: acceleration is not automatically risk reduction in OT. Sara’s warning is that pulling the entire 2027 segmentation programme into H2 2026 could create exactly the operational failures the board is trying to avoid if it is done as a broad, fast redesign of live Level 2 and Level 1 environments. In her framing, the danger is not abstract “change risk.” It is loss-of-view from a bad firewall rule, loss-of-control from a poorly sequenced cutover, or broken dependencies around HMI-to-controller traffic, historian feeds, relay engineering access, time sync, vendor support, and certified legacy configurations.

That gives us a more defensible middle position for the memo. We are not saying, “do nothing until 2027,” and we are not saying, “move the whole programme forward at once.” We are saying the acceleration should be threat-mapped and safety-bounded. The items Sara would pull forward are the ones that reduce the intrusion paths under discussion without disturbing live control loops: Level 4-to-3 or 3.5 boundary controls, OT DMZ hardening, remote-access and jump-host enforcement, network-device management-plane isolation, cleanup of exposed services like SNMP, TFTP, and Smart Install, and monitoring around Level 3-to-2 boundaries. That lines up with the two threat threads already on the table: credential/session theft and tunneling on the endpoint side, and exploitation of weak network-device exposure on the infrastructure side.

The caveat is important: we have not proven that every operator is facing a converged intrusion chain, and we have not validated any one site’s Purdue dependencies in this discussion. So the board recommendation should avoid a blanket “accelerate everything” instruction. It should instead define which controls can be safely advanced now, which require engineering validation before cutover, and which should remain governed by outage windows, vendor certification, and safety-case review.

That is why the next turn needs to be technical validation. Alex now needs to give us the 14-day evidence pack: the checks that tell a board whether its operator is actually in the high-risk group that should accelerate H2 2026 controls, rather than applying a rushed segmentation push everywhere.

What changed here is that “high-risk” is no longer just a label for the board to debate; Alex translated it into a two-week evidence-gathering exercise. His framing is useful: this should be a 14-day “prove we are not in the blast path” pack, not a generic risk review. The test is whether this operator has the exposed pathways, weak management services, suspicious device activity, or IT-to-OT routes that match the tradecraft being discussed.

The most concrete immediate work is at the edge and the IT/OT boundary. On edge routers, firewalls, VPNs, and switches, the CISO should commission an inventory of internet-facing and partner-facing devices, confirm Cisco Smart Install is disabled, move away from weak SNMP configurations, and look for signs such as SNMP Set-Requests, configuration-copy activity, unexpected TFTP transfers, web-management logins, local admin changes, and deviations from golden configurations. That matters because the cited advisory points to abuse of exactly those management-plane weaknesses, including default or weak SNMP, exposed web management, TFTP config theft, and older Cisco vulnerabilities.

On the boundary side, Alex’s point is that diagrams are not enough. The operator needs an actual route map from corporate IT, cloud, vendor networks, and remote-access zones into OT Level 3 and 3.5. That is the practical way to answer the board’s question: not “are we worried?”, but “can an intrusion path plausibly reach operational environments, and do we see evidence that someone has been trying?”

The caveat is important: these checks would not prove attribution, and the reporting on Armored Likho and FSB Center 16 activity does not automatically mean this specific operator is targeted. But it does give the CISO a defensible validation pack. If the checks show exposed management services, unexplained configuration changes, risky routes, or suspicious remote-access patterns, acceleration becomes much easier to justify. If they do not, the board can still act, but with a more measured risk basis as we move into final synthesis.