Cybersecurity Under Pressure. Real Attacks, Real Lessons

Odcinki

• 
  An Automotive Alert Is Not an Incident Response | CUP Focus 03.10.2026 3min

  Detection creates a signal, not a decision. This CUP Focus separates the responsibilities of the VSOC and PSIRT, from initial fleet triage and first-mile forensics to root-cause analysis and long-term remediation.Format: CUP Focus, a self-contained section from the Cybersecurity Under Pressure archive.Listen to the full episode: https://podcasters.spotify.com/pod/show/toni-gonzalez-burgueo/episodes/An-IDPS-Alert-Is-Not-an-Incident-Response-Capability-e3knv4g
• 
  When Digital Actions Create Physical Impact | CUP Micro Brief 03.10.2026 2min

  In OT, a digital action can move machinery, interrupt fabrication or weaken detection without obvious warning. This CUP Micro Brief links active scanning risk, IEC 62443 segmentation and AI model drift to physical resilience.Listen to the full episode:https://podcasters.spotify.com/pod/show/toni-gonzalez-burgueo/episodes/The-Threat-Has-a-Body-Defending-Critical-Infrastructure-Against-Kinetic-AI-e3lv01v
• 
  Schneider Electric’s CVE-2026-77120: The Dangerous Assumption Behind Authenticated Access 02.10.2026 1godz 20min

  An authenticated user is not necessarily a trusted user. CVE-2026-77120 in Schneider Electric PowerLogic T300 shows how an account with SSH access can cross a weak privilege boundary and reach root-level control through OS command injection.This episode examines the vulnerability as an operational security problem, not just a patching task. We break down the technical path, the assumptions that make exploitation possible, and the decisions asset owners must take when an RTU supports critical electricity distribution.We discuss:• why authentication does not prove authorization or trustworthiness• how SSH exposure, account governance and privilege separation change the real attack path• why segmentation must restrict both access to the RTU and the actions possible after login• what to log and monitor when legitimate credentials may be abused• how to balance firmware remediation, service continuity and compensating controls in long-lived OT environmentsAffected scope: PowerLogic T300 versions 2.9.8-5620 and earlier. Check the latest Schneider Electric guidance before making operational changes.Chapters:00:00 Context and central question15:33 The Technical Breakdown33:15 The Operational Decisions48:11 The Pressure Test01:00:16 The Key TakeawaysMore analysis: https://cybersecurityunderpressure.com/
• 
  When EV Charging Becomes a Cyber-Kinetic Risk | CUP Micro Brief 01.10.2026 1min

  An EV charging cable initiates a cloud-connected transaction with physical consequences. This CUP Micro Brief follows the path from complex connectivity, through unsafe input validation, to cyber-kinetic manipulation of electrical limits.Listen to the full episode:https://podcasters.spotify.com/pod/show/toni-gonzalez-burgueo/episodes/How-EV-Chargers-Could-Crash-the-Grid-The-Cyber-Risk-Behind-Mass-Electrification-e3lkh8c
• 
  A Clean Backup Does Not Prove a Safe Restart | CUP Focus 01.10.2026 4min

  Restoring files is not the same as restoring operational confidence. This CUP Focus explains why an OT restart requires trusted control logic, known-good engineering baselines and a defensible go/no-go decision before physical production resumes.Format: CUP Focus, a self-contained section from the Cybersecurity Under Pressure archive.Listen to the full episode: https://podcasters.spotify.com/pod/show/toni-gonzalez-burgueo/episodes/The-Restart-Bottleneck-Is-Not-the-Backup--It-Is-the-Evidence-e3knunc
• 
  Detecting the Attack Is Not Proving Safety: IAM4RAIL and Railway Cybersecurity 30.09.2026 1godz 20min

  n a railway system, detecting malicious activity and understanding its safety consequence are two different engineering problems.In this episode of Cybersecurity Under Pressure: Real Attacks, Real Lessons, we use work developed within Europe’s Rail FP3-IAM4RAIL as a case study in one of the most important distinctions in railway cybersecurity: cybersecurity monitoring can tell us that something suspicious is happening, but it does not automatically tell us what authority the attacker has gained, which operational functions are affected or whether train safety has actually been compromised.IAM4RAIL includes an onboard cybersecurity monitoring and threat-detection capability for rolling stock. A secure edge device integrated into onboard networks continuously observes communications, telemetry and operational behaviour and can generate alerts when it identifies anomalous or suspicious activity. This provides a valuable new layer of visibility in railway environments that historically have had limited technical cybersecurity monitoring.The Technical Breakdown examines what must happen after an alert. A cyber event has to be mapped through the real architecture: from the initial entry point to the affected component, across network and system boundaries, toward the functions that carry operational authority. Detecting anomalous traffic near a critical railway subsystem is important evidence, but proximity is not the same as control. The engineering question is which boundaries the attacker can actually cross and what the compromised component is technically capable of influencing.The Operational Decisions become harder in legacy railway environments. Systems may have long service lives, strict availability requirements and safety constraints that limit how aggressively cybersecurity teams can patch, isolate or reconfigure equipment. Monitoring, segmentation and compensating controls therefore have to reduce cyber risk without creating new operational or safety hazards. Cybersecurity cannot be applied in isolation from the engineering context in which the railway must continue to operate.In The Pressure Test, you are responsible for a fleet containing legacy cyber-physical systems. Monitoring detects suspicious activity inside the onboard environment, but the evidence does not yet establish whether the attacker can reach train-control functions. Isolating everything immediately may affect availability or operational procedures. Doing nothing leaves an unresolved attack path. The decision has to be based on architecture, authority, containment and evidence — not simply on the presence of an alert.The key lesson is that detection, cybersecurity impact and safety consequence are related, but they are not interchangeable. Effective railway cybersecurity requires visibility into the attack, understanding of the affected architecture and evidence connecting cyber compromise to the physical functions that matter.An alert tells us that something may be wrong.The architecture tells us what the attacker can reach.The safety analysis tells us what that actually means for the railway.Thanks for listening to Cybersecurity Under Pressure. Follow the show for more real attacks, technical breakdowns and practical lessons for cybersecurity leaders.Explore all episodes and resources:https://cybersecurityunderpressure.com/episodes
• 
  What Actually Starts the CRA 24-Hour Clock? | CUP Micro Brief 29.09.2026 1min

  Not every vulnerability starts the Cyber Resilience Act reporting clock. This CUP Micro Brief explains the two triggers, why reachability and VEX matter, and how CRA product obligations differ from NIS2 operator duties.Listen to the full episode:https://podcasters.spotify.com/pod/show/toni-gonzalez-burgueo/episodes/The-24-Hour-Trap-Defensible-Decisions-Under-the-Cyber-Resilience-Act-e3lumm0
• 
  Secure Boot Is Not a Checkbox: Espressif AR2026-006 and the Limits of Firmware Trust 28.09.2026 1godz 30min

  Secure Boot is often represented as a simple security property: enabled or disabled. But a configuration flag does not tell us whether the complete chain used to establish trust at boot actually behaves as intended.In this episode of Cybersecurity Under Pressure: Real Attacks, Real Lessons, we examine Espressif security advisory AR2026-006, affecting ECDSA-based Secure Boot on specific revisions of the ESP32-H2, ESP32-C5, ESP32-C61, ESP32-P4 and ESP32-S31. The issue sits inside ROM-based ECDSA signature verification, where invalid signatures can under certain conditions be accepted as valid.The Technical Breakdown looks at what that actually means. The affected verification workflow does not sufficiently validate whether the ECDSA signature components fall within their required range. ESP32-C5 also contains an initialization issue affecting the ECDSA peripheral during the ROM verification process. If an attacker can replace the signed firmware image and manipulate its signature in external flash, the device can accept attacker-controlled firmware during boot.But the vulnerability does not eliminate the attack preconditions. Exploitation requires a path to modify external flash. That can mean supply-chain access or physical access combined with flash-write capability. Packaging, Secure UART configuration, disabled download paths and Flash Encryption can therefore materially change attack feasibility even though they do not repair the underlying ROM defect.The Operational Decisions become especially difficult because this is not simply a software patching problem. The affected behaviour exists in immutable ROM on currently affected devices. Product teams therefore need to know the exact SoC and hardware revision deployed, which Secure Boot scheme is configured, how flash is protected, which programming and service interfaces remain available, and which additional security controls surround the boot process. For new production, Espressif recommends RSA-based Secure Boot where supported. Migration of already-deployed devices depends on their existing eFuse configuration and available Secure Boot digest blocks.Another important distinction is scope. The advisory states that application-layer ECDSA verification is not affected, and the ECDSA verification path used for OTA updates is therefore separate from the vulnerable ROM-based boot verification. That distinction matters because “ECDSA is vulnerable” would be a much broader claim than the evidence supports.In The Pressure Test, imagine managing a global population of connected devices built across different hardware revisions and configurations. A Secure Boot vulnerability is disclosed, but there is no universal software fix for the affected ROM. Some devices have Flash Encryption and tightly controlled programming interfaces. Others may have different manufacturing or service paths. The decision is no longer simply whether Secure Boot is enabled. It is which deployed configurations actually expose a viable attack chain and what evidence proves that the remaining barriers still hold.The key lesson is that a security feature is not an assurance argument. Secure Boot depends on the verification implementation, key and eFuse configuration, flash integrity, programming interfaces, hardware revision and the lifecycle processes surrounding the device.“Secure Boot enabled” is configuration data.Knowing whether the complete boot chain can still be trusted is security evidence.Thanks for listening to Cybersecurity Under Pressure. Follow the show for more real attacks, technical breakdowns and practical lessons for cybersecurity leaders.Explore all episodes and resources:https://cybersecurityunderpressure.com/episodes
• 
  When a License Plate Becomes a Password | CUP Micro Brief 27.09.2026 1min

  A public vehicle identifier became the starting point for a remote attack chain. This CUP Micro Brief connects the Kia API flaw, the disappearance of the traditional vehicle perimeter and the need for blind exploit validation.Listen to the full episode:https://podcasters.spotify.com/pod/show/toni-gonzalez-burgueo/episodes/Your-License-Plate-Is-the-Password-What-the-Kia-API-Hack-Revealed-e3lumpt
• 
  A Supplier List Is Not a Trust Chain: NIST IR 8536 and Verifiable Supply-Chain Traceability 25.09.2026 1godz 2min

  Knowing who your suppliers are is useful. Collecting SBOMs is useful. Neither, by itself, proves where a component came from, what happened to it during its lifecycle or whether the evidence describing it can still be trusted.In this episode of Cybersecurity Under Pressure: Real Attacks, Real Lessons, we examine NIST IR 8536, Supply Chain Traceability: Manufacturing Meta-Framework, and the problem it is trying to solve: how organizations can build verifiable provenance across increasingly complex, multi-tier supply chains without forcing every participant into the same internal system.The Technical Breakdown explores the difference between having supply-chain data and having an actual traceability chain. A supplier register, an SBOM, a certificate or a component record may each contain valuable information, but isolated artifacts do not automatically establish provenance. Traceability requires those records to be connected into a temporally ordered history in which products, components, events and transformations can be related to one another and independently verified.NIST IR 8536 approaches this through interoperable structures, linked traceability events and cryptographically verifiable relationships. The objective is not to create one enormous centralized database containing every supplier’s proprietary information. The framework supports selective disclosure, allowing organizations to provide the evidence necessary to establish provenance and integrity while protecting sensitive manufacturing and commercial data.The Operational Decisions examine what this means for organizations already collecting SBOMs, supplier declarations, certificates, manufacturing records and cybersecurity evidence. The challenge is no longer simply obtaining more documents. Teams need to determine which artifacts belong to which product configuration, which supplier or sub-tier produced them, when they were valid, what changed afterwards and whether the relationships between those records can still be demonstrated.In The Pressure Test, a critical component has passed through several suppliers, software and hardware revisions and manufacturing stages before reaching the final product. A security issue appears months later. You have supplier records, SBOMs and individual pieces of assurance evidence, but no reliable way to reconstruct the complete provenance chain. The question becomes whether you can identify the affected population, determine which evidence remains valid and prove which products actually contain the affected component or configuration.The key lesson is that supply-chain assurance depends on relationships, not inventories. A list tells you who participated. An SBOM tells you what components were declared. Traceability connects those facts to provenance, chronology, configuration and evidence throughout the lifecycle.Because a folder full of evidence is not yet a trust chain.The value appears when you can prove how the evidence connects.Thanks for listening to Cybersecurity Under Pressure. Follow the show for more real attacks, technical breakdowns and practical lessons for cybersecurity leaders.Explore all episodes and resources:https://cybersecurityunderpressure.com/episodes
• 
  Local Does Not Mean Low Impact: CVE-2026-24083 and Automotive Attack Feasibility 23.09.2026 1godz 3min

  A vulnerability with a local attack vector can have serious consequences. But “local” does not automatically mean remote vehicle compromise, and it certainly does not prove that an attacker can reach safety-relevant vehicle functions.In this episode of Cybersecurity Under Pressure: Real Attacks, Real Lessons, we examine CVE-2026-24083, a memory-corruption vulnerability affecting Qualcomm Snapdragon Auto platforms including QAM8295P, QCA6696 and SA8295P. The vulnerability occurs while processing IOCTL device-driver requests with invalid arguments and carries a CVSS 3.1 score of 7.8, with a local attack vector, low privileges required and no user interaction.The Technical Breakdown focuses on what “local” actually tells us. It describes where exploitation begins, not how the attacker reached that position. The initial foothold could result from physical access, a compromised application, another vulnerability, a maintenance interface or an already-established execution context. Those paths have very different levels of attack feasibility and should not be collapsed into a single vulnerability score.The next question is privilege propagation. Successful exploitation of the vulnerable component does not automatically imply control of the vehicle. The relevant engineering question is what authority that component provides and which security boundaries remain between it and vehicle-relevant assets. Can an attacker reach a more privileged service? Escape an application or virtualization boundary? Cross a hypervisor? Reach a gateway? Move toward Ethernet or CAN? Or influence an asset whose compromise could affect vehicle behaviour?The Operational Decisions translate that reasoning into automotive vulnerability management. Identifying “Snapdragon Auto” in a vehicle is not enough. The vulnerable SoC has to be mapped to the actual BSP or firmware baseline, ECU implementation, vehicle architecture and deployed population. The vulnerability then becomes an input to the ISO/SAE 21434 TARA, where each step in the attack path must be supported by explicit preconditions, controls and evidence.In The Pressure Test, the security team must decide what to do when a high-severity local vulnerability exists inside a complex vehicle architecture but the complete path to a vehicle-relevant consequence has not been demonstrated. Treating the CVSS score as proof of vehicle compromise exaggerates the evidence. Treating “local” as automatically low risk can underestimate it. The defensible decision depends on the actual attack chain and the containment mechanisms implemented in the deployed system.The key lesson is that vulnerability management cannot stop at the CVE entry. Automotive cybersecurity has to connect the initial foothold, privilege transition, architectural boundaries and vehicle consequences into one evidence-based attack path.Because “local” tells us where exploitation starts.The vehicle architecture determines how far the attacker can go.Thanks for listening to Cybersecurity Under Pressure. Follow the show for more real attacks, technical breakdowns and practical lessons for cybersecurity leaders.Explore all episodes and resources:https://cybersecurityunderpressure.com/episodes
• 
  One PLC, Multiple Security Lifecycles: The SIMATIC S7-1500 Linux Subsystem Problem 21.09.2026 1godz 15min

  An industrial asset may appear as a single box in an inventory, but that does not mean everything inside it follows the same cybersecurity lifecycle.In this episode of Cybersecurity Under Pressure: Real Attacks, Real Lessons, we examine vulnerabilities affecting the additional GNU/Linux subsystem of the Siemens SIMATIC S7-1500 CPU 1518(F)-4 PN/DP MFP and use them to challenge one of the most persistent simplifications in OT asset management: the assumption that one physical device represents one software stack, one vulnerability profile and one maintenance lifecycle.The Technical Breakdown explores what changes when a traditional PLC platform also contains a general-purpose Linux environment. The control functionality and the Linux subsystem may coexist inside the same industrial device, but their security characteristics are very different. Linux brings its own kernel, libraries, packages and vulnerability stream, creating dependencies and remediation requirements that may evolve independently from the automation functions operators normally associate with the PLC.The Operational Decisions examine why this matters in a real plant. An asset inventory may tell you that a particular S7-1500 is installed, while still failing to identify the version and exposure of the subsystem running inside it. Vulnerability management therefore has to move beyond device-level identification toward component-level understanding. Teams need to know which software environments are present, who owns their maintenance, which updates apply to each layer and whether remediation can be performed without affecting deterministic control, validated configurations or production availability.In The Pressure Test, you are responsible for securing a factory where PLCs control high-consequence physical processes. A vulnerability disclosure affects the Linux environment inside devices that production teams regard simply as PLCs. Stopping the process is expensive, patching introduces operational uncertainty and leaving the subsystem untouched preserves known exposure. You must determine which lifecycle takes precedence, how to validate the update and what evidence is necessary before returning the system to normal operation.The key lesson is that modern industrial assets increasingly contain several security domains inside the same physical product. Firmware, operating systems, applications, containers and control logic may each evolve at different speeds and may require different vulnerability monitoring, patching and support strategies. Asset management therefore has to represent not only what the device is, but also what is running inside it and how each component is maintained throughout its life.Because in modern OT, one asset no longer necessarily means one cybersecurity lifecycle.Thanks for listening to Cybersecurity Under Pressure. Follow the show for more real attacks, technical breakdowns and practical lessons for cybersecurity leaders.Explore all episodes and resources:https://cybersecurityunderpressure.com/episodes
• 
  Security Sign-Off for Silicon: Why Chip Security Must Become a Design Gate 18.09.2026 1godz 13min

  Semiconductor development already has formal gates for functionality, timing, power and physical implementation. Security is increasingly becoming another condition that must be demonstrated before a design can be considered ready.In this episode of Cybersecurity Under Pressure: Real Attacks, Real Lessons, we examine the emerging concept of security sign-off in semiconductor development and what it means for an industry building increasingly complex, heterogeneous and software-dependent hardware. The challenge is no longer simply to add security features to a chip. It is to establish evidence that the architecture, implementation and surrounding system preserve the intended security properties before the design reaches production.The Technical Breakdown explores why conventional software and IT security checks cannot provide that assurance alone. An application can pass vulnerability scanning, firmware can be tightly controlled and traditional network protections can operate correctly while weaknesses remain inside the hardware architecture itself. Security therefore has to move earlier into specification, RTL, verification and physical implementation, where issues such as unauthorized data paths, information leakage, fault behavior, roots of trust and implementation weaknesses can still be identified before they become expensive silicon.The Operational Decisions examine what happens when this principle reaches real engineering programmes. Security verification cannot simply become an unlimited additional checklist imposed at the end of development. Teams need explicit security requirements, measurable coverage, clear ownership between architecture, hardware, firmware and system engineering, and acceptance criteria that fit into existing development gates without making delivery impossible.In The Pressure Test, you are operating in a high-consequence cyber-physical environment built around heavy industrial robotics and complex embedded electronics. A component may satisfy its functional requirements while uncertainty remains about the security assumptions embedded below the software layer. You must decide what evidence is sufficient, whether production can proceed and where the boundary should be drawn between acceptable residual risk and a security issue serious enough to stop deployment.The key lesson is that semiconductor security cannot remain an informal confidence statement. If security properties matter to the system, they need requirements, verification evidence and an explicit decision point before release. That does not mean one universal test can certify every chip. It means security must become part of the same engineering discipline already used to prove that the rest of the design is ready.Because a chip should not be considered finished simply because it works. Increasingly, it will also have to demonstrate why it can be trusted.Thanks for listening to Cybersecurity Under Pressure. Follow the show for more real attacks, technical breakdowns and practical lessons for cybersecurity leaders.Explore all episodes and resources:https://cybersecurityunderpressure.com/episodes
• 
  One Hardcoded Key, Many Systems at Risk: The Johnson Controls Airwall Lesson 16.09.2026 1godz 19min

  A hardcoded cryptographic key can look like a relatively simple implementation mistake. In an embedded or industrial system, however, that single decision can undermine an entire security architecture.In this episode of Cybersecurity Under Pressure: Real Attacks, Real Lessons, we examine CVE-2026-64887 affecting Johnson Controls Airwall and use it to explore a broader problem in embedded cybersecurity: what happens when a secret intended to establish trust is permanently built into the product itself. Airwall versions before 4.1 contain a hardcoded cryptographic key that can enable a cryptanalytic attack, exposing a weakness in a platform designed to provide identity-based, zero-trust protection for connected operational assets.The Technical Breakdown looks beyond the vulnerability label to examine why hardcoded secrets are fundamentally different from ordinary credentials. A password can be changed and a certificate can be replaced, but a cryptographic key embedded across deployed products may be shared by many installations and deeply coupled to firmware, configuration data or authentication mechanisms. Once that secret is discovered, the problem is no longer confined to a single device. The trust model built around it must be reassessed.The Operational Decisions explore what remediation really means in an industrial environment. Updating software may remove the vulnerable implementation, but organisations still need to determine where affected versions are deployed, what information may have been exposed, whether the same secret existed across multiple installations and whether systems that previously relied on that key can still be trusted. Asset visibility, supplier coordination, maintenance windows and operational continuity quickly become part of what initially looked like a cryptographic problem.In The Pressure Test, you are responsible for cybersecurity in a large automotive manufacturing environment where embedded systems support high-speed robotic processes. A hardcoded-key vulnerability is disclosed in technology connected to the operational environment, but production cannot simply stop while every dependency is investigated. You must decide what to isolate, what can continue operating, how to establish the affected population and what evidence is necessary before declaring the environment trustworthy again.The key lesson is that cryptographic strength means very little if key management is weak. Secure algorithms cannot compensate for secrets that are identical across deployments, impossible to rotate or permanently embedded in software. Effective product and OT cybersecurity therefore requires unique secrets, protected provisioning, controlled key lifecycle management, revocation and rotation mechanisms, and clear evidence that compromise of one device cannot automatically undermine every other deployment.Because the most sophisticated security architecture can still depend on one very simple question: who else knows the key?Thanks for listening to Cybersecurity Under Pressure. Follow the show for more real attacks, technical breakdowns and practical lessons for cybersecurity leaders.Explore all episodes and resources:https://cybersecurityunderpressure.com/episodes
• 
  Beyond Software Supply Chains: NSA ASIC Assurance and the Problem of Trusting Silicon 14.09.2026 1godz 34min

  When cybersecurity teams discuss supply-chain risk, the conversation usually starts with software. But some of the most consequential trust decisions are made much deeper in the stack — inside the hardware itself.In this episode of Cybersecurity Under Pressure: Real Attacks, Real Lessons, we examine the NSA’s latest guidance for Application Specific Integrated Circuits, or ASICs, and what its Level of Assurance 1 framework tells us about securing custom microelectronics throughout design and manufacturing. An organisation may spend years and billions of dollars engineering a critical chip, yet still depend on external design tools, third-party intellectual property, manufacturing facilities and suppliers that sit outside its direct security boundary.The Technical Breakdown explores why hardware assurance is fundamentally different from conventional vulnerability management. The objective is not simply to find a known flaw after deployment, but to establish evidence-supported confidence that the component has not acquired unexpected characteristics or unintended behaviour somewhere along its lifecycle. That requires looking beyond the finished silicon to the engineering environments, EDA tooling, third-party IP, design data, manufacturing processes and organisations involved in producing it.The Operational Decisions translate that problem into risk, procurement and governance. Not every component requires the same degree of assurance, and maximum assurance is neither practical nor economically sustainable for every product. The challenge is determining how critical a component is to the system, what the consequence of subversion would be, which parts of the supply chain can actually be trusted and what evidence is sufficient to justify that trust.In The Pressure Test, the problem becomes immediate: you are responsible for a high-value hardware design destined for a critical system, but fabrication and parts of the engineering chain depend on external organisations. You must decide what information suppliers genuinely need, which controls reduce exposure without making production impossible, and how much residual uncertainty the programme can accept before the chip becomes part of the final system.The key lesson is that hardware supply-chain security cannot be reduced to choosing a trusted supplier. Assurance must be engineered across the lifecycle and supported by evidence proportional to the consequence of failure or malicious modification. The deeper a component sits inside a critical system, the harder it may be to replace — and the more important it becomes to understand exactly why it deserves to be trusted.Thanks for listening to Cybersecurity Under Pressure. Follow the show for more real attacks, technical breakdowns and practical lessons for cybersecurity leaders.Explore all episodes and resources:https://cybersecurityunderpressure.com/episodes
• 
  Secure at the Factory, Exposed at the Dealership: The BLE Theft Auto Problem 11.09.2026 1godz 33min

  A vehicle can leave the factory with a carefully designed cybersecurity architecture and acquire a new attack surface before the owner even drives it home.In this episode of Cybersecurity Under Pressure: Real Attacks, Real Lessons, we examine the BLE Theft Auto research into aftermarket Bluetooth Low Energy remote-control and anti-theft systems. Installed by dealerships or vehicle owners, these products can connect smartphone applications to door locks, alarms, lights, immobilizers, ignition systems and other sensitive vehicle functions. Their installation changes the vehicle’s security baseline outside the original development and release process of the manufacturer.The Technical Breakdown explores how proprietary application-layer protocols, weak pairing mechanisms and inadequate key management can turn a security product into an access path. Vulnerable devices may broadcast identifiers that can be detected locally or located through crowdsourced Bluetooth databases, allowing an attacker to identify and target specific vehicles. Depending on the affected system, unauthorised access may enable doors to be unlocked, alarms to be disabled, engines to be immobilised or remote-control functions to be activated.The Operational Decisions examine the fragmented responsibility behind the problem. The OEM may not have designed or approved the device, the dealership may have installed it, the aftermarket supplier controls the firmware and application, and the owner may be expected to perform the update. For dealerships and fleet operators, the immediate challenge is determining which vehicles contain the component, whether the firmware has been updated and what compensating controls are possible when removing the device requires invasive work on the vehicle wiring.In The Pressure Test, you are responsible for product security across a dealership network or vehicle fleet. A serious vulnerability has been disclosed, affected vehicles are already in customer hands and the installed-device inventory is incomplete. You must decide how to identify exposed vehicles, notify customers, verify remediation and manage the residual risk while ownership remains distributed across manufacturers, dealers, suppliers and drivers.The key lesson is that automotive cybersecurity cannot stop at factory release. The vehicle security baseline must account for dealer-installed equipment, aftermarket modifications, software updates, resale and decommissioning. Effective lifecycle governance requires configuration visibility, explicit supplier responsibilities, secure update mechanisms and evidence that every component connected to sensitive vehicle functions remains authorised and supportable.Because a secure vehicle can become vulnerable when someone adds a component that was never part of its original cybersecurity architecture.Thanks for listening to Cybersecurity Under Pressure. Follow the show for more real attacks, technical breakdowns and practical lessons for cybersecurity leaders.Explore all episodes and resources:https://cybersecurityunderpressure.com/episodes
• 
  When the Security Router Becomes the Attack Path: Weidmüller and the Fragility of Industrial Segmentation 09.09.2026 1godz 36min

  An industrial security router is supposed to protect the factory floor. But when that router is vulnerable, the security boundary itself can become the attacker’s path into production.In this episode of Cybersecurity Under Pressure: Real Attacks, Real Lessons, we examine vulnerabilities affecting Weidmüller industrial security routers and the wider operational problem they expose. These devices may provide firewalling, network segmentation, VPN connectivity and remote access between industrial machines, production cells and external support environments. That defensive role also gives them a privileged position within the architecture.The Technical Breakdown explores what happens when vulnerabilities affect the device responsible for enforcing trust between networks. A compromised router may expose its configuration, interfere with communications or provide a pivot point toward systems that were assumed to be protected behind it. The risk is therefore larger than the individual vulnerability: placing extensive trust in one security appliance also creates a concentration of operational risk.In The Pressure Test, you are responsible for a large, high-speed factory floor built around industrial robotics. The routers protecting the production networks are vulnerable, but taking them offline could interrupt operations, remote maintenance and critical communications. You must decide whether to patch, isolate, replace or continue operating under compensating controls while production, safety and recovery requirements leave little room for error.The Operational Decisions examine the practical constraints behind that choice, including incomplete asset inventories, restricted maintenance windows, legacy dependencies, supplier access and the challenge of proving that segmentation still works after the device enforcing it can no longer be fully trusted.The key lesson is that a security control must also be managed as a potentially vulnerable operational asset. Industrial resilience requires verified firmware baselines, restricted management access, independent monitoring, tested recovery procedures and an architecture that does not place unlimited trust in a single protective device.Because when the security boundary becomes the attack path, everything behind it must be reassessed.Thanks for listening to Cybersecurity Under Pressure. Follow the show for more real attacks, technical breakdowns and practical lessons for cybersecurity leaders.Explore all episodes and resources:https://cybersecurityunderpressure.com/episodes
• 
  Frauscher FDS102: Why Railway Diagnostics Belong Inside the Security Boundary 07.09.2026 1godz 17min

  A diagnostic system does not have to control the safety function to become operationally critical.In this episode of Cybersecurity Under Pressure: Real Attacks, Real Lessons, we examine the vulnerabilities affecting the Frauscher FDS102 diagnostic environment and the broader lesson they reveal about railway cybersecurity.The disclosures do not demonstrate compromise of the FAdC axle-counting safety logic itself. But that distinction does not make the diagnostic tier insignificant.Diagnostic environments can contain railway signalling information, track layouts, configuration data, privileged functions, backups and the tools required to support preventive and corrective maintenance.The Technical Breakdown traces this diagnostic trust chain from identity and system access to engineering data, administrative capabilities, maintenance workflows and connected railway assets.The central question is not only whether an attacker can reach the safety function directly. It is what becomes possible when a compromised diagnostic environment exposes sensitive engineering knowledge, disrupts maintenance capability or creates a trusted path toward other operational systems.The Operational Decisions explore the difficult choices that follow. Isolating the environment may reduce exposure, but it can also remove visibility and delay troubleshooting. Applying an update may close known vulnerabilities, but it does not automatically restore confidence in the system, its data or the access paths that existed while it was exposed.In The Pressure Test, you are the railway operator in the control room. The clock is running, the diagnostic environment may no longer be trustworthy and continued operations still depend on the capabilities it provides. You must decide what to isolate, what can remain available and what evidence is required before the environment can safely return to service.The key lesson is that “diagnostic” describes a function. It should not define the cybersecurity consequence.Railway resilience therefore requires more than patching. Recovery objectives, backup responsibilities, restoration times and supplier obligations must be explicit, testable and aligned with the operational importance of the diagnostic environment.Because a system that supports maintenance, troubleshooting and recovery is already part of the railway security boundary.Thanks for listening to Cybersecurity Under Pressure. Follow the show for more real attacks, technical breakdowns and practical lessons for cybersecurity leaders.Explore all episodes and resources:https://cybersecurityunderpressure.com/episodes
• 
  When Edit Permissions Become System-Level Code Execution 04.09.2026 1godz 20min

  Least privilege can look perfectly correct inside an application and still fail one layer below.In this episode, we examine CVE-2026-3014 in Siemens Siveillance Video, a critical vulnerability affecting the Management Server API. An authenticated user with edit permissions can execute arbitrary code in the context of the Management Server Service.That distinction matters. This is not an unauthenticated remote-code-execution scenario. The attacker already needs a meaningful application privilege. But the vulnerability exposes a deeper architectural problem: a permission intended to authorise configuration changes can cross the application boundary and inherit authority from the service and operating system underneath it.We break down that privilege path from the application role to the Management Server API, the Windows service account and ultimately the host on which the management capability runs.For a video-management platform, the consequences extend beyond a single server. Management systems can sit at the centre of cameras, alarms, operator workflows and other physical-security capabilities. The relevant security question therefore becomes not only who can authenticate, but what each authorised identity can ultimately reach if one layer of the architecture fails.The episode then moves into the operational decisions. How should organisations respond when a critical vulnerability affects an actively used management server? Is patching immediately always the safest option? Which administrative identities actually require edit permissions? From where can those accounts reach the management plane? And what architectural controls can reduce exposure while maintaining the physical-security capability?We explore dedicated management enclaves, deny-by-default connectivity, bastion and privileged-access management, MFA, just-in-time administrative access, privileged-session monitoring and service-account hardening as parts of the same defence-in-depth argument.The central lesson is that least privilege cannot be assessed only at the user interface.A defensible architecture must follow privilege across the complete stack:application role → API → service account → operating system → connected assets and management networksCybersecurity Under Pressure explores real vulnerabilities, their operational consequences and the engineering decisions required to protect cyber-physical systems.Websitehttps://cybersecurityunderpressure.comTelegramhttps://t.me/cybersecurityunderpressure
• 
  A Critical CVE Is Not an Attack Path: Assessing PLCnext Risk in the Plant 02.09.2026 1godz 30min

  A critical vulnerability tells you what could be exploited. It does not tell you whether an attacker can actually reach it, what conditions would be required or what the operational consequences would be inside your plant.In this episode, we examine the Phoenix Contact PLCnext advisory as a practical example of why OT vulnerability management cannot stop at CVSS.For PLCnext firmware before version 2026.0.3, CVE-2025-41769 affects the PROFINET service in its default configuration. An unauthenticated remote attacker able to reach that service could trigger a buffer overflow, potentially causing a controller reboot or arbitrary code execution. The wider advisory also covers a denial-of-service condition affecting the PLCnext Engineer interface and a lower-impact SQL injection issue.The vulnerability is clear. The plant-level exposure is not.We break down the questions that determine whether the CVE represents an urgent production risk: which controller versions are actually deployed, whether the affected service is enabled, from which network zones PROFINET is reachable, which engineering conduits cross those zones, what filtering and monitoring exist, and whether an attacker could satisfy the necessary preconditions.The episode then moves from technical exposure to operational decision-making. Should the organisation patch immediately, isolate the controller, introduce compensating controls or continue production while collecting stronger evidence? How should teams respond when asset inventories are incomplete, maintenance windows are limited and an uncontrolled intervention could create its own safety or availability risk?The Pressure Test places those decisions inside a Tier-1 automotive plant with hundreds of robotic systems, continuous production commitments and a critical vulnerability affecting controllers embedded in the manufacturing process.The central lesson is that two plants can carry the same CVE and still face completely different risks. A defensible OT vulnerability assessment must connect the advisory to the real architecture:affected asset → reachable service → attack preconditions → feasible attack path → operational consequence → detection and mitigationCybersecurity Under Pressure explores real vulnerabilities, their operational consequences and the engineering decisions required to protect cyber-physical systems.Websitehttps://cybersecurityunderpressure.comTelegramhttps://t.me/cybersecurityunderpressure