PLC Logic Changes During Live Production: An OT Pressure Test

A supplier declares an automotive ECU not affected by a vulnerability identified in a software component. What evidence should the manufacturer request before relying on that assessment?This Friday episode explores a hypothetical supplier-assurance scenario involving closed-source firmware, a safety-related ECU and production constraints. The discussion contrasts component absence with code reachability, examines build-specific evidence and considers the trade-offs between accepting an assessment, requesting further investigation, applying containment and updating software.Editorial clarification: this is not a documented vehicle incident. A VEX statement does not by itself determine a TARA risk rating or authorize risk retention. Binary analysis findings remain bounded by their method and coverage. The evidence package discussed is an assurance proposal, not a universal VEX requirement; regulatory and safety consequences require case-specific assessment.More analysis: https://cybersecurityunderpressure.com

What if a PLC program change is flagged while a factory remains in production and process indicators appear normal? This Wednesday episode uses a hypothetical engineering scenario to examine the gap between apparent process stability and confidence in controller logic.We compare possible change paths, engineering access, network visibility, controller state and the safety consequences of an unverified response. An online edit, a compromised engineering workstation and manipulation of operator views are hypotheses discussed in the dialogue, not established findings from a documented intrusion. The episode also examines the limits of live verification, the need for a trustworthy baseline and plant-safe recovery decisions.This is an analytical scenario, not a report of a confirmed attack. Specific mechanisms and outcomes depend on the PLC model, configuration, tooling and evidence available at a real site.

A production line is stopped, and a supplier needs an engineering connection to diagnose the fault. In this explicitly hypothetical CUP scenario, the same legacy session can also download a PLC program. The question is who can constrain and end its authority when recovery is urgent.We trace the path from supplier identity through remote access, a plant-controlled workstation, the engineering tool and the controller. A broker disconnect, account disable and controller-side termination do not necessarily have the same effect; none can undo a program already downloaded. MFA, recording and a jump host add control points, but do not make a change-capable tool read-only.We discuss named access, expiry, local supervision, alternative routes, surviving sessions and a bounded non-production acceptance exercise. This is an engineering analysis, not a reported incident, product vulnerability or completed experiment. NIST SP 800-82 Rev. 3 provides context; the revocation sequence and acceptance checks are CUP recommendations.Read the companion analysis: https://cybersecurityunderpressure.com/analysis-supplier-session-revocation-legacy-ot

What happens when a trusted note-taking workflow becomes a route into an industrial control environment? This episode examines an Evernote-to-SCADA attack path and the boundary between ordinary collaboration tools and operational access.We consider how attackers can use familiar cloud content, links or shared documents to influence users and systems that support industrial operations. The practical questions are where trust is established, what privilege is needed to reach an engineering workstation or SCADA component, and which actions the available evidence actually supports. A suspicious document alone does not prove process manipulation.For OT teams, the response starts with controlled access paths, isolation between corporate and plant networks, application and identity telemetry, and verification of changes at the engineering and control layers. Detection and containment must respect plant safety and availability. The lesson is to test the complete route from external content to privileged industrial action, not merely the first click.

An SBOM is only as useful as the components and relationships it captures. This episode examines how incomplete software bills of materials can hide critical vulnerabilities when transitive dependencies, embedded packages, firmware or build artifacts are missed.We discuss the difference between generating an SBOM and accepting it as evidence: checking scope against the delivered build, reconciling package and version identifiers, testing dependency depth and validating the tool configuration. A clean vulnerability scan cannot establish absence of risk if the underlying inventory is incomplete.For automotive and industrial systems, OEMs, suppliers and operators must trace findings to the exact delivered baseline, assess exploitability in context and maintain that evidence as products change. An SBOM supports this work; it does not replace product-level security analysis.

Application edit rights and operating-system administration are not the same security boundary. This CUP Micro Brief shows how an over-privileged video-management service can turn a limited application role into control of the underlying server. Related CUP episodes:Siemens Siveillance: When Edit Access Enables Code ExecutionJohnson Controls Airwall: The Risk Behind a Hardcoded KeyIndustrial Identity Security: The Risk in Software-Defined Factories

Can a connected vehicle reject a forged emergency-braking warning without suppressing a legitimate safety message?This episode examines false emergency electronic brake light warnings in connected-car and V2X environments. We break down the trust boundary between a valid sender credential, a plausible road event and the vehicle response that follows. Cryptographic validity can authenticate a source, but it does not automatically prove that the reported event is true.The discussion covers message authentication, plausibility checks, certificate and credential revocation, duplicate and anomalous-event detection, safe degradation, incident response and the operational limits of automated blocking. It also separates prevention, detection and containment, because each control proves something different.Key lessons:• Bind message acceptance to authenticated and authorized senders• Correlate warnings with vehicle, sensor and situational context• Design revocation and trust updates for real driving conditions• Avoid fail-open and fail-silent responses• Validate the complete path from received warning to vehicle actionThe episode does not assume that every V2X deployment is vulnerable or that a forged warning necessarily causes braking. Impact depends on the protocol, implementation, vehicle state and the control path exposed by the receiving system.You can also listen to Cybersecurity Under Pressure on PlayPodcast.net.

Planned downtime concentrates contractors, temporary access, firmware changes and disabled alerts in the same period. This CUP Focus explains why maintenance windows require tighter monitoring and evidence, not relaxed controls.Format: CUP Focus, a self-contained section from the Cybersecurity Under Pressure archive.Related CUP episodes:Kinetic AI and Critical Infrastructure: Connecting Cyber and Physical RiskOT Remote Access: Closing the Path When the Work EndsOT Session Hijacking: Revoking Trusted Engineering AccessLegacy VPNs in OT: Remote Access and the Cost of Disruption

Editorial context: The February 2021 Oldsmar incident was initially reported as an unauthorized remote-access attempt to alter water-treatment dosing. In 2023, the FBI said it could not confirm that a targeted cyber intrusion had initiated the incident. Treat the reported attack sequence discussed in this episode as an account with unresolved evidentiary limits, rather than a proven intrusion. Authorities reported no significant effect on treated water and no danger to the public.Revisit the Oldsmar case through the operational questions it raises for water utilities: who can reach an operator workstation, what authority a remote session carries, how process changes are detected, and what evidence supports a response decision.The practical focus is remote-access governance, independent process safeguards, operator visibility and incident evidence. Lessons derived from the reported scenario do not establish what actually caused the Oldsmar event.Sources and further reading:Original Pinellas County Sheriff report: https://www.pinellassheriff.gov/21-015-detectives-investigate-computer-software-intrusion-at-oldsmar-s-water-treatment-plantFBI investigation records: https://vault.fbi.gov/attempted-hacking-of-oldsmar-water-treatment-plant-on-february-5-2021WUSF, April 2023 follow-up: https://www.wusf.org/local-state/2023-04-13/official-hack-oldsmar-city-water-treatment-plant-2021CISA advisory AA21-042A: https://www.cisa.gov/news-events/cybersecurity-advisories/aa21-042aCybersecurity Under Pressure. Real Attacks, Real Lessons.

A railway diagnostic platform may not execute the safety function, but it can expose topology, privileged sessions and a pivot path toward operational assets. This CUP Micro Brief explains why monitoring systems still belong inside the security boundary. Related CUP episodes:Frauscher FDS102: Securing Railway Diagnostic AccessLegacy Railway Security: Patching and Validation ConstraintsRailway OT Segmentation: Protecting the Certified CoreRailway Cybersecurity: Service Risk Beyond the SIL Boundary