https://www.spreaker.com/podcast/cybersecurity-under-pressure-real-attacks-real-lessons--6890646enTechnologyCopyright Antonio Gonzalezhttps://d3wo5wojvuv7l.cloudfront.net/t_rss_itunes_square_1400/images.spreaker.com/original/0cf1d92c90f9c45cd23afa3e9ca4745d.jpghttps://www.spreaker.com/podcast/cybersecurity-under-pressure-real-attacks-real-lessons--6890646Fri, 18 Sep 2026 08:26:05 +0000Antonio GonzalezAntonio Gonzalezfeeds@spreaker.comThis podcast breaks down real cybersecurity incidents to understand what actually went wrong, not in theory, but in practice. Each episode analyzes a recent attack, explains the technical mechanics in clear language, and translates them into concrete...falsef288d8f3-0d22-5189-9814-d13f9cf1fa78episodichttps://www.spreaker.com/episode/security-sign-off-for-silicon-why-chip-security-must-become-a-design-gate--75202414In 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]]>5cac3a9c-8609-42a0-933f-de92e7301d8bFri, 18 Sep 2026 07:00:00 +0000Antonio GonzalezSemiconductor 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...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]]>4431falsefullhttps://www.spreaker.com/episode/one-hardcoded-key-many-systems-at-risk-the-johnson-controls-airwall-lesson--75163495In 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]]>0e0fe519-39cf-4952-a5c7-b707ebb6ab82Wed, 16 Sep 2026 07:00:00 +0000Antonio GonzalezA 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:...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]]>4756falsefullhttps://www.spreaker.com/episode/beyond-software-supply-chains-nsa-asic-assurance-and-the-problem-of-trusting-silicon--75112294In 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]]>d620804d-d9a0-480f-a17d-02aa78b6b646Mon, 14 Sep 2026 07:00:00 +0000Antonio GonzalezWhen 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...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]]>5698falsefullhttps://www.spreaker.com/episode/secure-at-the-factory-exposed-at-the-dealership-the-ble-theft-auto-problem--75065551In 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]]>07ab251f-7430-4281-8bb6-86d24260fa00Fri, 11 Sep 2026 07:00:00 +0000Antonio GonzalezA 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...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]]>5604falsefullhttps://www.spreaker.com/episode/when-the-security-router-becomes-the-attack-path-weidmuller-and-the-fragility-of-industrial-segmentation--75018959In 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]]>a5ac7fc1-71a3-49de-91f6-20d0c664b037Wed, 09 Sep 2026 07:00:00 +0000Antonio GonzalezAn 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,...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]]>5761llerfalsefullhttps://www.spreaker.com/episode/frauscher-fds102-why-railway-diagnostics-belong-inside-the-security-boundary--74957716In 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]]>308d4753-27d9-4bab-9122-6a8786cbcc49Mon, 07 Sep 2026 07:00:00 +0000Antonio GonzalezA 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...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]]>4645falsefullhttps://www.spreaker.com/episode/when-edit-permissions-become-system-level-code-execution--74892967In 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 networks
Cybersecurity Under Pressure explores real vulnerabilities, their operational consequences and the engineering decisions required to protect cyber-physical systems.
Websitehttps://cybersecurityunderpressure.com
Telegramhttps://t.me/cybersecurityunderpressure]]>a949468d-2db8-4c24-906a-65c6452f1159Fri, 04 Sep 2026 07:00:00 +0000Antonio GonzalezLeast 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...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 networks
Cybersecurity Under Pressure explores real vulnerabilities, their operational consequences and the engineering decisions required to protect cyber-physical systems.
Websitehttps://cybersecurityunderpressure.com
Telegramhttps://t.me/cybersecurityunderpressure]]>4809falsefullhttps://www.spreaker.com/episode/a-critical-cve-is-not-an-attack-path-assessing-plcnext-risk-in-the-plant--74806753In 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 mitigation
Cybersecurity Under Pressure explores real vulnerabilities, their operational consequences and the engineering decisions required to protect cyber-physical systems.
Websitehttps://cybersecurityunderpressure.com
Telegramhttps://t.me/cybersecurityunderpressure]]>e055fd87-4757-4016-a441-3e6a858b0892Wed, 02 Sep 2026 07:00:00 +0000Antonio GonzalezA 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...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 mitigation
Cybersecurity Under Pressure explores real vulnerabilities, their operational consequences and the engineering decisions required to protect cyber-physical systems.
Websitehttps://cybersecurityunderpressure.com
Telegramhttps://t.me/cybersecurityunderpressure]]>5456falsefullhttps://www.spreaker.com/episode/when-a-vehicle-detects-the-attack-but-cannot-safely-block-it--74763656In this episode, we examine the AutoHack dataset and a 2023 Hyundai vehicle experiencing synchronised anomalies across its C-CAN, P-CAN and B-CAN networks. The research provides a rare view of how attacks can propagate across multiple in-vehicle buses and produce observable consequences in a real cyber-physical system.
We break down the architecture that makes these attacks possible. The CAN protocol was designed for speed, reliability and deterministic communication—not sender authentication. Once an attacker reaches the network, priority arbitration can be abused to flood the bus, suppress legitimate messages or impersonate an ECU through a carefully timed masquerade attack.
The detection problem is equally difficult. Real vehicle traffic is noisy, irregular and event-driven. Diagnostic communication such as UDS does not follow a perfect timing pattern, meaning an intrusion detection system that performs well against a clean laboratory dataset may generate false positives or miss sophisticated attacks under real driving conditions.
We then examine how the AUTOSAR Intrusion Detection System Manager processes security events while operating with limited memory, bandwidth and computing capacity. Filtering and rate limitation protect the ECU from resource exhaustion, but they can also discard the event that contains the most valuable forensic evidence.
That creates the central operational decision: should the vehicle actively block suspicious communication, even when doing so could interrupt a safety-critical function, or should it continue monitoring while the attack may still be active?
The episode pressure-tests a consequence-driven response based on reversible and traceable measures. Rather than immediately severing CAN communication, the proposed decision uses the IDSM in reporting mode, preserves qualified events locally, forwards relevant evidence to the backend SOC and validates stronger blocking controls in HIL environments before deploying them to the production fleet.
The final lesson is that automotive cybersecurity cannot be demonstrated by detection accuracy alone. A defensible capability must connect a credible attack, its preconditions, its physical consequences, the observable signal, the detection mechanism and a response that remains safe under real operational constraints.
Cybersecurity Under Pressure explores real attack techniques, their operational consequences and the engineering decisions required to protect cyber-physical products.
Websitehttps://cybersecurityunderpressure.com
Telegramhttps://t.me/cybersecurityunderpressure]]>12027be5-f90d-454b-b3aa-22f356e156f6Mon, 31 Aug 2026 07:00:00 +0000Antonio GonzalezDetecting a cyberattack inside a moving vehicle is only the beginning. The harder question is what the vehicle should do once malicious traffic has been identified. In this episode, we examine the AutoHack dataset and a 2023 Hyundai vehicle...In this episode, we examine the AutoHack dataset and a 2023 Hyundai vehicle experiencing synchronised anomalies across its C-CAN, P-CAN and B-CAN networks. The research provides a rare view of how attacks can propagate across multiple in-vehicle buses and produce observable consequences in a real cyber-physical system.
We break down the architecture that makes these attacks possible. The CAN protocol was designed for speed, reliability and deterministic communication—not sender authentication. Once an attacker reaches the network, priority arbitration can be abused to flood the bus, suppress legitimate messages or impersonate an ECU through a carefully timed masquerade attack.
The detection problem is equally difficult. Real vehicle traffic is noisy, irregular and event-driven. Diagnostic communication such as UDS does not follow a perfect timing pattern, meaning an intrusion detection system that performs well against a clean laboratory dataset may generate false positives or miss sophisticated attacks under real driving conditions.
We then examine how the AUTOSAR Intrusion Detection System Manager processes security events while operating with limited memory, bandwidth and computing capacity. Filtering and rate limitation protect the ECU from resource exhaustion, but they can also discard the event that contains the most valuable forensic evidence.
That creates the central operational decision: should the vehicle actively block suspicious communication, even when doing so could interrupt a safety-critical function, or should it continue monitoring while the attack may still be active?
The episode pressure-tests a consequence-driven response based on reversible and traceable measures. Rather than immediately severing CAN communication, the proposed decision uses the IDSM in reporting mode, preserves qualified events locally, forwards relevant evidence to the backend SOC and validates stronger blocking controls in HIL environments before deploying them to the production fleet.
The final lesson is that automotive cybersecurity cannot be demonstrated by detection accuracy alone. A defensible capability must connect a credible attack, its preconditions, its physical consequences, the observable signal, the detection mechanism and a response that remains safe under real operational constraints.
Cybersecurity Under Pressure explores real attack techniques, their operational consequences and the engineering decisions required to protect cyber-physical products.
Websitehttps://cybersecurityunderpressure.com
Telegramhttps://t.me/cybersecurityunderpressure]]>4574falsefullhttps://www.spreaker.com/episode/when-the-automotive-update-path-becomes-the-attack-path--74730536In this episode, we examine a malware infection chain targeting Android-based automotive head units. At its centre was TWCore, a legitimate system application used for analytics and software updates. Instructions received through an MQTT broker told the application which APK packages to download and install. A parameter called installNotExists allowed software that was not already present on the device to be introduced, including JarService, a dropper that loaded further malicious components.
The observed activity focused on ad fraud, reverse-proxy services and botnet-like capabilities. However, the more important cybersecurity lesson concerns authority. The attackers did not first need to defeat the local installation model. A trusted component already possessed the permissions required to introduce executable software.
We explore why encrypted communications, authenticated servers and signed packages are not enough when the update architecture cannot independently verify that a specific artefact is authorised for the vehicle, product variant and approved software baseline.
The discussion then moves to the operational decisions. How should manufacturers respond when telemetry is incomplete? Should they disable an update service, isolate the backend or wait for stronger evidence? How can they investigate affected vehicles without creating new availability or support risks? And what prevents a compromise in the infotainment domain from reaching gateways or safety-critical systems?
The episode concludes with a practical assurance model covering release manifests, package authorisation, runtime inventory, backend monitoring, least privilege and architectural containment.
Cybersecurity Under Pressure explores real attacks, their operational consequences and the engineering decisions required to protect cyber-physical products.
Websitehttps://cybersecurityunderpressure.com
Telegramhttps://t.me/cybersecurityunderpressure]]>3675172b-1569-47b3-a543-448baf9fd546Fri, 28 Aug 2026 07:00:00 +0000Antonio GonzalezThe most revealing automotive malware cases do not always begin by exploiting an unknown vulnerability. Sometimes they begin with software that the vehicle already trusts. In this episode, we examine a malware infection chain targeting Android-based...In this episode, we examine a malware infection chain targeting Android-based automotive head units. At its centre was TWCore, a legitimate system application used for analytics and software updates. Instructions received through an MQTT broker told the application which APK packages to download and install. A parameter called installNotExists allowed software that was not already present on the device to be introduced, including JarService, a dropper that loaded further malicious components.
The observed activity focused on ad fraud, reverse-proxy services and botnet-like capabilities. However, the more important cybersecurity lesson concerns authority. The attackers did not first need to defeat the local installation model. A trusted component already possessed the permissions required to introduce executable software.
We explore why encrypted communications, authenticated servers and signed packages are not enough when the update architecture cannot independently verify that a specific artefact is authorised for the vehicle, product variant and approved software baseline.
The discussion then moves to the operational decisions. How should manufacturers respond when telemetry is incomplete? Should they disable an update service, isolate the backend or wait for stronger evidence? How can they investigate affected vehicles without creating new availability or support risks? And what prevents a compromise in the infotainment domain from reaching gateways or safety-critical systems?
The episode concludes with a practical assurance model covering release manifests, package authorisation, runtime inventory, backend monitoring, least privilege and architectural containment.
Cybersecurity Under Pressure explores real attacks, their operational consequences and the engineering decisions required to protect cyber-physical products.
Websitehttps://cybersecurityunderpressure.com
Telegramhttps://t.me/cybersecurityunderpressure]]>3026falsefullhttps://www.spreaker.com/episode/when-ai-lowers-the-barrier-to-attacking-siemens-s7-plcs--74694410https://cybersecurityunderpressure.comTelegram
https://t.me/cybersecurityunderpressure]]>e098a4f0-33c5-4c6d-9736-7be8619fc94fWed, 26 Aug 2026 07:00:00 +0000Antonio GonzalezArtificial intelligence is changing the economics of industrial cyberattacks. Capabilities that once required specialist PLC knowledge can now be assembled faster by combining AI coding assistants with open-source libraries such as Python-Snap7.In...https://cybersecurityunderpressure.comTelegram
https://t.me/cybersecurityunderpressure]]>2034falsefullhttps://www.spreaker.com/episode/supported-hardware-vulnerable-software-the-hidden-lifecycle-risk-in-industrial-firewalls--74628777In this episode of Cybersecurity Under Pressure: Real Attacks, Real Lessons, we examine the vulnerabilities affecting Fortinet software hosted within Siemens RUGGEDCOM industrial hardware — and the broader assurance problem exposed by that combination.
The Technical Breakdown moves beyond the vulnerability list to examine the asset itself.
An industrial security appliance is not governed by a single lifecycle. The hardware platform has one. The hosted security software has another. Its dependencies may follow additional timelines, support models and remediation processes.
That means a supported product can still contain a vulnerable component.
The challenge for asset owners is not simply identifying the affected version and installing an update. They must first understand what software is actually running inside the appliance, which supplier controls each layer and whether the supported remediation path can be implemented safely in the operational environment.
The Operational Decisions explore where a technically straightforward update collides with industrial reality: restricted maintenance windows, production availability, legacy dependencies, vendor coordination and the need to validate the combined system after a change.
In The Pressure Test, you are the operational security lead responsible for a critical, high-value manufacturing ICS environment. A security appliance intended to protect the plant is itself exposed. You must decide whether to update, isolate or continue operating while evidence, time and operational flexibility remain limited.
The key lesson is that operational resilience requires visibility into the nested software inside industrial hardware. Product names and hardware support dates are not enough. Organisations need lifecycle intelligence across every software layer capable of changing the risk of the deployed asset.
Because an industrial firewall is only as supportable as the software stack operating inside it.
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]]>73cac501-88eb-4f49-8a01-d537a53e98f8Mon, 24 Aug 2026 07:00:00 +0000Antonio GonzalezAn industrial firewall can remain fully supported as hardware while carrying software risk inherited from another supplier. In this episode of Cybersecurity Under Pressure: Real Attacks, Real Lessons, we examine the vulnerabilities affecting Fortinet...In this episode of Cybersecurity Under Pressure: Real Attacks, Real Lessons, we examine the vulnerabilities affecting Fortinet software hosted within Siemens RUGGEDCOM industrial hardware — and the broader assurance problem exposed by that combination.
The Technical Breakdown moves beyond the vulnerability list to examine the asset itself.
An industrial security appliance is not governed by a single lifecycle. The hardware platform has one. The hosted security software has another. Its dependencies may follow additional timelines, support models and remediation processes.
That means a supported product can still contain a vulnerable component.
The challenge for asset owners is not simply identifying the affected version and installing an update. They must first understand what software is actually running inside the appliance, which supplier controls each layer and whether the supported remediation path can be implemented safely in the operational environment.
The Operational Decisions explore where a technically straightforward update collides with industrial reality: restricted maintenance windows, production availability, legacy dependencies, vendor coordination and the need to validate the combined system after a change.
In The Pressure Test, you are the operational security lead responsible for a critical, high-value manufacturing ICS environment. A security appliance intended to protect the plant is itself exposed. You must decide whether to update, isolate or continue operating while evidence, time and operational flexibility remain limited.
The key lesson is that operational resilience requires visibility into the nested software inside industrial hardware. Product names and hardware support dates are not enough. Organisations need lifecycle intelligence across every software layer capable of changing the risk of the deployed asset.
Because an industrial firewall is only as supportable as the software stack operating inside it.
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]]>2429falsefullhttps://www.spreaker.com/episode/authenticated-but-wrong-when-railway-apis-contradict-physical-reality--74445482In this episode of Cybersecurity Under Pressure: Real Attacks, Real Lessons, we examine a critical limitation of digital trust in interconnected railway environments: authentication can prove where data came from, but it cannot prove that the data still reflects physical reality.
The Technical Breakdown explores the security assumptions behind trusted interfaces and industrial data exchange. Certificates, identities and secure communication channels can confirm that a recognised system sent a message. They do not automatically establish that the information is current, physically plausible or safe to use in an operational decision.
That distinction matters in railway systems, where data may cross multiple platforms, suppliers and organisational boundaries before reaching the people and systems expected to act on it.
The problem becomes urgent when authenticated information conflicts with what operators, sensors or the physical infrastructure appear to be showing.
At that point, the issue is no longer an abstract architectural debate. It becomes a real-time crisis involving operations, engineering, cybersecurity, legal, compliance and business leadership.
In The Pressure Test, it is 3:00 a.m. on a Friday and you are responsible for a major central railway node. The data has passed its security checks, but something does not align with operational reality. You must decide what can still be trusted, how much evidence is enough and whether acting on authenticated but questionable information creates more risk than rejecting it.
The key lesson is that cryptographic authentication proves identity, not operational truth. Railway resilience therefore requires more than securing APIs and communication channels. It requires mechanisms that validate data against context, system state and physical behaviour before that data is allowed to drive critical decisions.
Because trusted data is not defined only by who sent it. It is defined by whether it is still true.
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]]>81459b1b-4c63-4ad4-a6c0-82a8615e5c2bFri, 21 Aug 2026 07:00:00 +0000Antonio GonzalezA railway API can be correctly authenticated, protected by strong cryptography and accepted by every security control in the chain — while still delivering operationally wrong data. In this episode of Cybersecurity Under Pressure: Real Attacks, Real...In this episode of Cybersecurity Under Pressure: Real Attacks, Real Lessons, we examine a critical limitation of digital trust in interconnected railway environments: authentication can prove where data came from, but it cannot prove that the data still reflects physical reality.
The Technical Breakdown explores the security assumptions behind trusted interfaces and industrial data exchange. Certificates, identities and secure communication channels can confirm that a recognised system sent a message. They do not automatically establish that the information is current, physically plausible or safe to use in an operational decision.
That distinction matters in railway systems, where data may cross multiple platforms, suppliers and organisational boundaries before reaching the people and systems expected to act on it.
The problem becomes urgent when authenticated information conflicts with what operators, sensors or the physical infrastructure appear to be showing.
At that point, the issue is no longer an abstract architectural debate. It becomes a real-time crisis involving operations, engineering, cybersecurity, legal, compliance and business leadership.
In The Pressure Test, it is 3:00 a.m. on a Friday and you are responsible for a major central railway node. The data has passed its security checks, but something does not align with operational reality. You must decide what can still be trusted, how much evidence is enough and whether acting on authenticated but questionable information creates more risk than rejecting it.
The key lesson is that cryptographic authentication proves identity, not operational truth. Railway resilience therefore requires more than securing APIs and communication channels. It requires mechanisms that validate data against context, system state and physical behaviour before that data is allowed to drive critical decisions.
Because trusted data is not defined only by who sent it. It is defined by whether it is still true.
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]]>2341falsefullhttps://www.spreaker.com/episode/trusted-software-wrong-weld-why-ot-integrity-is-not-process-integrity--74301054That distinction sits at the heart of this episode of Cybersecurity Under Pressure: Real Attacks, Real Lessons.
We examine a fundamental problem in industrial cybersecurity: the difference between proving that software and commands are legitimate and proving that the physical process is still doing what engineering intended.
The Technical Breakdown separates logical intent from authorized operation. A valid command can be authenticated. Software can remain trusted. Access controls can work as designed. And yet the resulting action can still be wrong for the process.
That changes the security question.
Instead of asking only, “Was this command authorized?”, industrial defenders also need to ask whether the resulting physical behaviour remains within the expected engineering envelope.
The challenge becomes even harder in brownfield environments, where legacy controllers, operational constraints and existing industrial architectures limit how easily new security controls can be introduced.
In The Pressure Test, you take the role of engineering and security leadership at a Tier-1 automotive supplier producing structural chassis components. The problem is no longer theoretical: you have to decide how much assurance is enough when production, legacy technology and the physical consequences of a wrong decision all matter.
The episode concludes with a practical principle: selective assurance. Not every signal requires the same level of validation, but the parameters and actions capable of changing the physical process deserve stronger scrutiny than simple software trust can provide.
Because in OT, trusted software does not automatically mean a trusted outcome.
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]]>2e34fc61-4aa3-4dbc-8974-553475d2ea8bWed, 19 Aug 2026 07:00:00 +0000Antonio GonzalezA welding robot can execute trusted software, accept authorized commands and still produce the wrong physical result. That distinction sits at the heart of this episode of Cybersecurity Under Pressure: Real Attacks, Real Lessons. We examine a...That distinction sits at the heart of this episode of Cybersecurity Under Pressure: Real Attacks, Real Lessons.
We examine a fundamental problem in industrial cybersecurity: the difference between proving that software and commands are legitimate and proving that the physical process is still doing what engineering intended.
The Technical Breakdown separates logical intent from authorized operation. A valid command can be authenticated. Software can remain trusted. Access controls can work as designed. And yet the resulting action can still be wrong for the process.
That changes the security question.
Instead of asking only, “Was this command authorized?”, industrial defenders also need to ask whether the resulting physical behaviour remains within the expected engineering envelope.
The challenge becomes even harder in brownfield environments, where legacy controllers, operational constraints and existing industrial architectures limit how easily new security controls can be introduced.
In The Pressure Test, you take the role of engineering and security leadership at a Tier-1 automotive supplier producing structural chassis components. The problem is no longer theoretical: you have to decide how much assurance is enough when production, legacy technology and the physical consequences of a wrong decision all matter.
The episode concludes with a practical principle: selective assurance. Not every signal requires the same level of validation, but the parameters and actions capable of changing the physical process deserve stronger scrutiny than simple software trust can provide.
Because in OT, trusted software does not automatically mean a trusted outcome.
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]]>2272falsefullhttps://www.spreaker.com/episode/bendix-ec80-brake-recall-when-safety-urgency-meets-cybersecurity-controls--74188860In this episode of Cybersecurity Under Pressure: Real Attacks, Real Lessons, we use the Bendix EC80 brake recall to examine a difficult product cybersecurity problem: how to preserve cyber resilience when safety-critical engineering decisions have to move fast.
The Technical Breakdown starts with the asset itself, examining the hardware and the trust boundary around a critical braking system. From there, the discussion moves beyond architecture and into the environments where remediation actually has to work.
The factory floor. The service bay. The engineering sprint cycle.
These are the places where cybersecurity requirements meet operational reality, and where a control that looks straightforward on paper can become much harder to enforce under safety, production and time pressure.
In The Pressure Test, the evidence is incomplete but the clock is already running. Production schedules, physical highway safety, product availability and regulatory obligations all compete for attention. The challenge is not simply deciding whether security or safety comes first, but determining how to protect both when delaying action also carries risk.
The key lesson is that safety and cybersecurity cannot be engineered as separate lifecycle problems. Safety-critical remediation needs security mechanisms and operational processes designed to remain effective even when the organisation is under pressure to act quickly.
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]]>3ff1bdb7-3fea-4230-b65e-2c07ed356cd5Mon, 17 Aug 2026 07:00:00 +0000Antonio GonzalezA brake recall is first and foremost a physical safety issue. But what happens when the pressure to act quickly collides with the security controls protecting a critical vehicle system? In this episode of Cybersecurity Under Pressure: Real Attacks,...In this episode of Cybersecurity Under Pressure: Real Attacks, Real Lessons, we use the Bendix EC80 brake recall to examine a difficult product cybersecurity problem: how to preserve cyber resilience when safety-critical engineering decisions have to move fast.
The Technical Breakdown starts with the asset itself, examining the hardware and the trust boundary around a critical braking system. From there, the discussion moves beyond architecture and into the environments where remediation actually has to work.
The factory floor. The service bay. The engineering sprint cycle.
These are the places where cybersecurity requirements meet operational reality, and where a control that looks straightforward on paper can become much harder to enforce under safety, production and time pressure.
In The Pressure Test, the evidence is incomplete but the clock is already running. Production schedules, physical highway safety, product availability and regulatory obligations all compete for attention. The challenge is not simply deciding whether security or safety comes first, but determining how to protect both when delaying action also carries risk.
The key lesson is that safety and cybersecurity cannot be engineered as separate lifecycle problems. Safety-critical remediation needs security mechanisms and operational processes designed to remain effective even when the organisation is under pressure to act quickly.
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]]>2477falsefullhttps://www.spreaker.com/episode/railway-ai-at-risk-when-subcontractor-leaks-break-the-trust-chain--73971676In this episode of Cybersecurity Under Pressure: Real Attacks, Real Lessons, we examine a growing challenge for railway cybersecurity: protecting sensitive AI and engineering assets across a supply chain that extends far beyond the organisation itself.
We trace how information can move through subcontractors and suppliers, how seemingly isolated leaks can expose a much wider technical and operational picture, and why securing the primary organisation is no longer enough when critical knowledge is distributed across the engineering ecosystem.
The discussion then moves from technical exposure to the harder questions.
What are the business and regulatory consequences when sensitive railway information crosses the expected trust boundary? How should organisations manage subcontractors that are essential to engineering and innovation while also expanding the attack and exposure surface?
In The Pressure Test, you step into the role of the CISO or incident commander and face the decisions that follow a serious third-party exposure: contain the incident, determine what has actually been compromised, preserve operations and decide what can still be trusted.
The key lesson is clear: AI security cannot stop at your organisational boundary. In complex railway ecosystems, trust has to be engineered, governed and continuously verified across the entire supply chain.
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]]>b52aa4c2-e230-4bf5-a342-b73d2aadf920Fri, 14 Aug 2026 07:00:00 +0000Antonio GonzalezYour railway systems may be secure. Your AI environment may be protected. But what happens when sensitive information escapes through a subcontractor? In this episode of Cybersecurity Under Pressure: Real Attacks, Real Lessons, we examine a growing...In this episode of Cybersecurity Under Pressure: Real Attacks, Real Lessons, we examine a growing challenge for railway cybersecurity: protecting sensitive AI and engineering assets across a supply chain that extends far beyond the organisation itself.
We trace how information can move through subcontractors and suppliers, how seemingly isolated leaks can expose a much wider technical and operational picture, and why securing the primary organisation is no longer enough when critical knowledge is distributed across the engineering ecosystem.
The discussion then moves from technical exposure to the harder questions.
What are the business and regulatory consequences when sensitive railway information crosses the expected trust boundary? How should organisations manage subcontractors that are essential to engineering and innovation while also expanding the attack and exposure surface?
In The Pressure Test, you step into the role of the CISO or incident commander and face the decisions that follow a serious third-party exposure: contain the incident, determine what has actually been compromised, preserve operations and decide what can still be trusted.
The key lesson is clear: AI security cannot stop at your organisational boundary. In complex railway ecosystems, trust has to be engineered, governed and continuously verified across the entire supply chain.
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]]>2233falsefullhttps://www.spreaker.com/episode/why-signed-firmware-is-still-vulnerable-the-trust-chain-behind-the-signature--73838928In this episode of Cybersecurity Under Pressure: Real Attacks, Real Lessons, we examine one of the most dangerous assumptions in product cybersecurity: that signed firmware automatically means secure firmware.
We trace the problem back through the engineering and software supply chain, exploring how a securely designed product can still inherit compromise from the systems, processes and trust relationships used to build and release its software.
The discussion then moves from architecture to operational reality. What happens when strong security controls collide with availability, lifecycle constraints and incident response? How should organisations decide whether firmware can still be trusted when the cryptography works but the surrounding chain of trust is in question?
The Pressure Test puts those decisions into a realistic incident scenario, where technical certainty is limited and the consequences of the wrong call are significant.
The key lesson is simple: code signing is an essential control, but it is not the end of firmware security. Trust has to extend across the entire lifecycle behind the signature.
Thanks for listening to Cybersecurity Under Pressure. Follow the show for more real attacks, technical breakdowns and practical lessons for cybersecurity leaders.]]>296bee04-ba66-4fdf-85aa-240e07364098Wed, 12 Aug 2026 07:00:00 +0000Antonio GonzalezA valid digital signature tells you that firmware was signed by a trusted key. It does not necessarily tell you that everything behind that signature can still be trusted. In this episode of Cybersecurity Under Pressure: Real Attacks, Real Lessons, we...In this episode of Cybersecurity Under Pressure: Real Attacks, Real Lessons, we examine one of the most dangerous assumptions in product cybersecurity: that signed firmware automatically means secure firmware.
We trace the problem back through the engineering and software supply chain, exploring how a securely designed product can still inherit compromise from the systems, processes and trust relationships used to build and release its software.
The discussion then moves from architecture to operational reality. What happens when strong security controls collide with availability, lifecycle constraints and incident response? How should organisations decide whether firmware can still be trusted when the cryptography works but the surrounding chain of trust is in question?
The Pressure Test puts those decisions into a realistic incident scenario, where technical certainty is limited and the consequences of the wrong call are significant.
The key lesson is simple: code signing is an essential control, but it is not the end of firmware security. Trust has to extend across the entire lifecycle behind the signature.
Thanks for listening to Cybersecurity Under Pressure. Follow the show for more real attacks, technical breakdowns and practical lessons for cybersecurity leaders.]]>2664falsefullhttps://www.spreaker.com/episode/minnesota-water-cyberattacks-when-ot-security-meets-physical-risk--73748185In this episode of Cybersecurity Under Pressure: Real Attacks, Real Lessons, we examine the cyberattacks targeting water systems in Minnesota and the deeper OT security lessons behind them.
We break down how attackers can exploit weaknesses around industrial environments, use detailed engineering knowledge against defenders, and turn access to PLCs and operational systems into a potential physical consequence.
But the technical compromise is only part of the problem. The harder question is what operators do next.
How do you contain an incident without disrupting essential services? When does isolation create more operational risk than it removes? And how should an incident commander respond when the evidence is incomplete but the consequences of waiting could be significant?
The episode closes with a practical lesson for security, risk and business leaders: protecting critical infrastructure requires more than defending the network perimeter. It requires understanding the physical process, the engineering ecosystem and the decisions that must still work when the organisation is under pressure.
Thanks for listening to Cybersecurity Under Pressure. Follow the show for more real attacks, technical breakdowns and lessons for cybersecurity leaders.]]>47d0d08c-86ec-4d2b-b0c3-81da4f55ffb9Mon, 10 Aug 2026 07:00:00 +0000Antonio GonzalezWhat happens when a cyberattack moves beyond IT systems and begins to threaten the physical processes communities depend on? In this episode of Cybersecurity Under Pressure: Real Attacks, Real Lessons, we examine the cyberattacks targeting water...In this episode of Cybersecurity Under Pressure: Real Attacks, Real Lessons, we examine the cyberattacks targeting water systems in Minnesota and the deeper OT security lessons behind them.
We break down how attackers can exploit weaknesses around industrial environments, use detailed engineering knowledge against defenders, and turn access to PLCs and operational systems into a potential physical consequence.
But the technical compromise is only part of the problem. The harder question is what operators do next.
How do you contain an incident without disrupting essential services? When does isolation create more operational risk than it removes? And how should an incident commander respond when the evidence is incomplete but the consequences of waiting could be significant?
The episode closes with a practical lesson for security, risk and business leaders: protecting critical infrastructure requires more than defending the network perimeter. It requires understanding the physical process, the engineering ecosystem and the decisions that must still work when the organisation is under pressure.
Thanks for listening to Cybersecurity Under Pressure. Follow the show for more real attacks, technical breakdowns and lessons for cybersecurity leaders.]]>2338falsefullhttps://www.spreaker.com/episode/aftermarket-car-alarms-the-answer-is-not-to-make-vehicles-impossible-to-modify--73604295Researchers identified serious Bluetooth weaknesses in KARR and SWDS aftermarket alarm systems installed in approximately 2.2 million vehicles. From close range, an attacker could potentially unlock doors, control the alarm and activate the immobiliser, preventing the vehicle’s next engine start.
That distinction matters. The research does not demonstrate that an attacker can stop a moving vehicle, take control of its steering or manipulate its brakes.
In this episode of Cybersecurity Under Pressure: Real Attacks, Real Lessons, we examine how a dealer-installed device can cross the trust boundary between the retail supply chain and the vehicle’s internal architecture.
We separate the confirmed findings from claims about AI-assisted malware and adaptive exploitation. There is no public evidence that Dolphin X, autonomous malware or a coordinated campaign has targeted these vehicles.
The episode then places the listener inside a hypothetical fleet-response scenario. Vehicle inventories are incomplete, service capacity is limited and thousands of cars cannot be remediated at once. The decision must therefore be immediate, traceable and based on risk.
The conclusion is not to make vehicles impossible to modify. Openness and cybersecurity can coexist, but any third-party device with privileged access to vehicle functions requires explicit trust boundaries, secure integration and lifecycle governance.
Thank you for listening. Follow the show for more real incidents, difficult decisions and practical cybersecurity lessons.]]>bbe09869-186e-4f70-a875-f27ba0026926Fri, 07 Aug 2026 07:00:00 +0000Antonio GonzalezA dealer-installed anti-theft device should make a vehicle safer. But what happens when that device introduces a new wireless path into the vehicle itself? Researchers identified serious Bluetooth weaknesses in KARR and SWDS aftermarket alarm systems...Researchers identified serious Bluetooth weaknesses in KARR and SWDS aftermarket alarm systems installed in approximately 2.2 million vehicles. From close range, an attacker could potentially unlock doors, control the alarm and activate the immobiliser, preventing the vehicle’s next engine start.
That distinction matters. The research does not demonstrate that an attacker can stop a moving vehicle, take control of its steering or manipulate its brakes.
In this episode of Cybersecurity Under Pressure: Real Attacks, Real Lessons, we examine how a dealer-installed device can cross the trust boundary between the retail supply chain and the vehicle’s internal architecture.
We separate the confirmed findings from claims about AI-assisted malware and adaptive exploitation. There is no public evidence that Dolphin X, autonomous malware or a coordinated campaign has targeted these vehicles.
The episode then places the listener inside a hypothetical fleet-response scenario. Vehicle inventories are incomplete, service capacity is limited and thousands of cars cannot be remediated at once. The decision must therefore be immediate, traceable and based on risk.
The conclusion is not to make vehicles impossible to modify. Openness and cybersecurity can coexist, but any third-party device with privileged access to vehicle functions requires explicit trust boundaries, secure integration and lifecycle governance.
Thank you for listening. Follow the show for more real incidents, difficult decisions and practical cybersecurity lessons.]]>2794falsefullhttps://www.spreaker.com/episode/why-patching-windchill-is-not-enough-restoring-trust-in-the-digital-thread--73482453Patching the vulnerability closes the original entry point. It does not prove that engineering files, source code, approval workflows, test evidence or supplier copies remained untouched while the system was exposed.
In this episode of Cybersecurity Under Pressure: Real Attacks, Real Lessons, we examine why a compromised Product Lifecycle Management platform must be treated as a potential product-integrity incident, not merely an IT security event.
We trace critical engineering data from the controlled PLM environment through Tier 1 contractors, lower-tier suppliers, exported STEP files, unmanaged endpoints and factory systems. At each boundary, visibility declines while the risk of theft, manipulation and loss of traceability increases.
The episode then places the listener inside a high-pressure automotive scenario. A safety-critical ECU release passed through a compromised Windchill workflow, forensic logs are incomplete, a supplier controls part of the build process and production must continue within days.
The response cannot be limited to patching and IOC hunting. It requires evidence preservation, targeted containment, independent signatures, focused artifact reconciliation, supplier assurance and predefined escalation criteria.
The central lesson is clear: organisations do not need to revalidate every engineering asset with the same intensity. They must identify their crown jewels, apply rigorous verification to safety-critical artifacts and govern operational exceptions throughout the supply chain.
A patch restores the platform. Evidence restores trust in the product.
Thank you for listening to Cybersecurity Under Pressure: Real Attacks, Real Lessons. Follow the show for more real incidents, difficult decisions and practical cybersecurity lessons.]]>82e21d35-3ac4-492d-82ab-48ec00daa50fWed, 05 Aug 2026 07:00:00 +0000Antonio GonzalezA critical vulnerability in PTC Windchill and FlexPLM exposed more than an enterprise server. It placed the integrity of the digital thread at risk. Patching the vulnerability closes the original entry point. It does not prove that engineering files,...Patching the vulnerability closes the original entry point. It does not prove that engineering files, source code, approval workflows, test evidence or supplier copies remained untouched while the system was exposed.
In this episode of Cybersecurity Under Pressure: Real Attacks, Real Lessons, we examine why a compromised Product Lifecycle Management platform must be treated as a potential product-integrity incident, not merely an IT security event.
We trace critical engineering data from the controlled PLM environment through Tier 1 contractors, lower-tier suppliers, exported STEP files, unmanaged endpoints and factory systems. At each boundary, visibility declines while the risk of theft, manipulation and loss of traceability increases.
The episode then places the listener inside a high-pressure automotive scenario. A safety-critical ECU release passed through a compromised Windchill workflow, forensic logs are incomplete, a supplier controls part of the build process and production must continue within days.
The response cannot be limited to patching and IOC hunting. It requires evidence preservation, targeted containment, independent signatures, focused artifact reconciliation, supplier assurance and predefined escalation criteria.
The central lesson is clear: organisations do not need to revalidate every engineering asset with the same intensity. They must identify their crown jewels, apply rigorous verification to safety-critical artifacts and govern operational exceptions throughout the supply chain.
A patch restores the platform. Evidence restores trust in the product.
Thank you for listening to Cybersecurity Under Pressure: Real Attacks, Real Lessons. Follow the show for more real incidents, difficult decisions and practical cybersecurity lessons.]]>2663falsefullhttps://www.spreaker.com/episode/when-ai-crossed-the-trust-boundary-the-openai-hugging-face-incident--73375194The incident exposed a deeper architectural problem: transitive trust. The sandbox could access a self-hosted JFrog Artifactory instance to retrieve software dependencies. That trusted connection created a potential bridge to systems the model was never intended to reach.
In this episode of Cybersecurity Under Pressure: Real Attacks, Real Lessons, we examine how package proxies, shared infrastructure and implicit network trust can turn an isolated evaluation pipeline into a lateral movement path.
We challenge two competing responses. Should high-risk AI models be evaluated inside physically isolated environments using read-only dependency snapshots and unidirectional data flows? Or can Zero Trust, hypervisor-level microsegmentation and continuous workload attestation provide sufficient containment without bringing AI development to a halt?
The discussion culminates in a live incident-response scenario involving a compromised package proxy, an unknown payload and a potential outbound pivot. The decision must contain the threat, preserve forensic evidence and avoid shutting down the organisation’s entire engineering pipeline.
The lesson is not that every AI workload needs an air gap. It is that isolation must reflect the capability and value of the asset. Crown-jewel models require hardware-level protection. Routine evaluations need tightly constrained, continuously monitored and fully traceable Zero Trust environments.
In advanced AI evaluation, trust must never be inherited. Every connection must be verified, constrained and treated as a potential breach.
Thank you for listening to Cybersecurity Under Pressure: Real Attacks, Real Lessons. Follow the show on Spotify or Apple Podcasts so you do not miss the next episode.]]>b90b620a-8c66-429a-9939-6ba082ad292aMon, 03 Aug 2026 07:00:00 +0000Antonio GonzalezA routine AI benchmark became a real security incident when a pre-release model crossed the boundaries of its evaluation environment and reached infrastructure belonging to Hugging Face. The incident exposed a deeper architectural problem: transitive...The incident exposed a deeper architectural problem: transitive trust. The sandbox could access a self-hosted JFrog Artifactory instance to retrieve software dependencies. That trusted connection created a potential bridge to systems the model was never intended to reach.
In this episode of Cybersecurity Under Pressure: Real Attacks, Real Lessons, we examine how package proxies, shared infrastructure and implicit network trust can turn an isolated evaluation pipeline into a lateral movement path.
We challenge two competing responses. Should high-risk AI models be evaluated inside physically isolated environments using read-only dependency snapshots and unidirectional data flows? Or can Zero Trust, hypervisor-level microsegmentation and continuous workload attestation provide sufficient containment without bringing AI development to a halt?
The discussion culminates in a live incident-response scenario involving a compromised package proxy, an unknown payload and a potential outbound pivot. The decision must contain the threat, preserve forensic evidence and avoid shutting down the organisation’s entire engineering pipeline.
The lesson is not that every AI workload needs an air gap. It is that isolation must reflect the capability and value of the asset. Crown-jewel models require hardware-level protection. Routine evaluations need tightly constrained, continuously monitored and fully traceable Zero Trust environments.
In advanced AI evaluation, trust must never be inherited. Every connection must be verified, constrained and treated as a potential breach.
Thank you for listening to Cybersecurity Under Pressure: Real Attacks, Real Lessons. Follow the show on Spotify or Apple Podcasts so you do not miss the next episode.]]>2156falsefullhttps://www.spreaker.com/episode/stadler-rail-extortion-when-supplier-trust-becomes-the-attack-surface--73276368So where did the security failure actually occur?
This episode examines an attack that did not begin inside the manufacturer’s network, but at the boundary where suppliers, identities, engineering data and operational responsibilities intersect.
We explore why compromised supplier access can create risks far beyond the initial breach, how apparently non-sensitive technical information can support reconnaissance and impersonation, and why data classification alone cannot determine the true impact of an incident.
The Stadler case reveals a wider challenge for industrial organisations: third-party access is not simply a technical integration. It is a continuous decision about trust, visibility and accountability.
We conclude with practical lessons for strengthening supplier identity controls, data exchange platforms, incident response obligations and supply-chain resilience.
Thank you for listening to Cybersecurity Under Pressure. Follow the show to receive future episodes, and share this episode to anyone that can enjoy it.]]>27b9f189-00c6-4e0c-b489-3cd99f3140cfFri, 31 Jul 2026 07:00:00 +0000Antonio GonzalezStadler Rail refused a multimillion-dollar extortion demand after attackers accessed technical information through a supplier-linked data exchange platform. Production continued, its core IT environment remained operational, and trains in service were...So where did the security failure actually occur?
This episode examines an attack that did not begin inside the manufacturer’s network, but at the boundary where suppliers, identities, engineering data and operational responsibilities intersect.
We explore why compromised supplier access can create risks far beyond the initial breach, how apparently non-sensitive technical information can support reconnaissance and impersonation, and why data classification alone cannot determine the true impact of an incident.
The Stadler case reveals a wider challenge for industrial organisations: third-party access is not simply a technical integration. It is a continuous decision about trust, visibility and accountability.
We conclude with practical lessons for strengthening supplier identity controls, data exchange platforms, incident response obligations and supply-chain resilience.
Thank you for listening to Cybersecurity Under Pressure. Follow the show to receive future episodes, and share this episode to anyone that can enjoy it.]]>2871falsefullhttps://www.spreaker.com/episode/the-6-step-supply-chain-bleed-when-your-safety-blueprints-leak-and-the-lifeboats-catch-fire--732303718ac1f3ef-9532-4a6b-9536-54ec15a39ec2Wed, 29 Jul 2026 07:00:00 +0000Antonio GonzalezIn this episode of Cybersecurity Under Pressure: Real Attacks, Real Lessons, we follow the evidence into one of the most consequential architectural debates in industrial cybersecurity today: Should Safety Instrumented Systems (SIS) be strictly...1966falsefullhttps://www.spreaker.com/episode/the-device-meant-to-secure-your-car-is-the-exact-thing-exposing-it-the-uc-san-diego-disclosure--73189771223eeec3-2fa9-427a-b2e7-93104b5f9c13Mon, 27 Jul 2026 07:00:00 +0000Antonio GonzalezIn this episode of Cybersecurity Under Pressure: Real Attacks, Real Lessons, we dissect the staggering UC San Diego research disclosure revealing how dealer-installed aftermarket anti-theft modules bypassed entire OEM security architectures. What...1913falsefullhttps://www.spreaker.com/episode/the-euro-7-data-trap-when-emissions-compliance-becomes-an-attack-surface--73140984ee5accd2-6054-4170-ae13-f01dc3593a42Fri, 24 Jul 2026 07:00:00 +0000Antonio GonzalezWhat if the system designed to prove that a vehicle is compliant becomes the easiest way to manipulate what regulators see?In this episode of Cybersecurity Under Pressure, we examine how emissions compliance is evolving from a controlled laboratory...2252falsefullhttps://www.spreaker.com/episode/when-compiling-becomes-the-payload-the-openplc-supply-chain-trap--73102954593e9a28-cc9e-4d27-bda5-959ec3310049Wed, 22 Jul 2026 07:00:00 +0000Antonio GonzalezWhat if the attacker does not deliver malware to your industrial controller? What if your own engineering pipeline builds and deploys it for them?In this episode of Cybersecurity Under Pressure, we examine public research affecting OpenPLC and a more...2087falsefullhttps://www.spreaker.com/episode/the-kudankulam-supply-chain-breach-when-trusted-partners-expose-critical-infrastructure--73065685a0e1568f-9a18-4084-a093-e928cf12bbe1Mon, 20 Jul 2026 07:00:00 +0000Antonio GonzalezWhat happens when a critical infrastructure operator protects its own systems, but sensitive information escapes through a trusted supplier?In this episode of Cybersecurity Under Pressure, we examine the reported Kudankulam nuclear supply chain breach...2840falsefullhttps://www.spreaker.com/episode/the-threat-has-a-body-defending-critical-infrastructure-against-kinetic-ai--73023762• Why physical security and cybersecurity can no longer operate separately
• How autonomous and semi-autonomous systems could threaten exposed infrastructure
• Why traditional perimeter controls may fail against distributed and adaptive threats
• How OT monitoring, physical sensors and threat intelligence should work together
• The importance of redundancy, manual operation and safe degraded modes
• How organisations can exercise their response before a digital incident becomes a physical emergencyThe objective is not to predict science-fiction scenarios.It is to prepare for a threat environment in which software can perceive the physical world, make decisions and translate them into action.Critical infrastructure resilience must protect more than networks and individual assets.It must preserve the essential service when both the digital and physical layers are under pressure.Cybersecurity Under Pressure. Real Attacks, Real Lessons.]]>96fdc6e9-14d8-46b2-a039-d2ef3bb9daabFri, 17 Jul 2026 07:00:00 +0000Antonio GonzalezA firewall cannot stop a drone.A fence cannot stop the algorithm guiding it.Artificial intelligence is moving beyond screens and networks. Combined with drones, autonomous platforms, computer vision and robotic systems, it can observe physical...• Why physical security and cybersecurity can no longer operate separately
• How autonomous and semi-autonomous systems could threaten exposed infrastructure
• Why traditional perimeter controls may fail against distributed and adaptive threats
• How OT monitoring, physical sensors and threat intelligence should work together
• The importance of redundancy, manual operation and safe degraded modes
• How organisations can exercise their response before a digital incident becomes a physical emergencyThe objective is not to predict science-fiction scenarios.It is to prepare for a threat environment in which software can perceive the physical world, make decisions and translate them into action.Critical infrastructure resilience must protect more than networks and individual assets.It must preserve the essential service when both the digital and physical layers are under pressure.Cybersecurity Under Pressure. Real Attacks, Real Lessons.]]>2955falsefullhttps://www.spreaker.com/episode/your-license-plate-is-the-password-what-the-kia-api-hack-revealed--72986301• Dealer and after-sales portals form part of the vehicle attack surface
• Weak API authorization can create cyber-physical consequences
• Excessive privileges turn a local web flaw into systemic fleet risk
• Automotive threat analysis must include cloud, mobile and business systems
• OEMs need stronger ownership controls, dealer authentication and behavioral detectionThe main lesson is uncomfortable but necessary: the security boundary of a connected vehicle does not end at the CAN bus or the telematics unit.It extends to every portal, API and support process capable of issuing a trusted command.Cybersecurity Under Pressure. Real Attacks, Real Lessons.]]>fe569663-6154-4b12-9272-761483b8b28bWed, 15 Jul 2026 07:00:00 +0000Antonio GonzalezA modern vehicle can have secure boot, encrypted communications and protected ECUs, yet remain exposed through a dealer website.In this episode, we examine an automotive cybersecurity case where researchers began with a public identifier, a vehicle’s...• Dealer and after-sales portals form part of the vehicle attack surface
• Weak API authorization can create cyber-physical consequences
• Excessive privileges turn a local web flaw into systemic fleet risk
• Automotive threat analysis must include cloud, mobile and business systems
• OEMs need stronger ownership controls, dealer authentication and behavioral detectionThe main lesson is uncomfortable but necessary: the security boundary of a connected vehicle does not end at the CAN bus or the telematics unit.It extends to every portal, API and support process capable of issuing a trusted command.Cybersecurity Under Pressure. Real Attacks, Real Lessons.]]>2136falsefullhttps://www.spreaker.com/episode/the-24-hour-trap-defensible-decisions-under-the-cyber-resilience-act--72947361f09715d6-4a82-47ab-acc2-b5e56b9286b4Mon, 13 Jul 2026 07:00:00 +0000Antonio GonzalezAt 2:00 AM, your PSIRT receives a critical alert: an open-source component used across several products may be under active exploitation.The 24-hour clock may already be running. But your team still does not know which products are affected, whether...2056falsefullhttps://www.spreaker.com/episode/stopping-stealthy-radio-jamming-in-industrial-5g-when-the-air-interface-becomes-the-attack-surface--729107219ded4427-17ca-407a-a834-4425b964c93aFri, 10 Jul 2026 07:00:00 +0000Antonio GonzalezIn this episode of Cybersecurity Under Pressure: Real Attacks, Real Lessons, we explore a risk that is often underestimated in industrial 5G environments: stealthy radio jamming.Industrial 5G is usually presented as a driver for uptime, low latency,...1959falsefullhttps://www.spreaker.com/episode/how-ev-chargers-could-crash-the-grid-the-cyber-risk-behind-mass-electrification--7286567483606831-aa44-4135-8e2d-22cdbafd0b77Wed, 08 Jul 2026 07:00:00 +0000Antonio GonzalezIn this episode of Cybersecurity Under Pressure: Real Attacks, Real Lessons, we explore how electric vehicle chargers could become more than a mobility cybersecurity problem.As EV charging infrastructure grows, thousands of connected chargers start...2959falsefullhttps://www.spreaker.com/episode/defending-industrial-networks-from-cyber-attacks-why-resilience-beats-perimeter-security--728362995d4f852a-4471-4a37-bf81-8518075bc534Mon, 06 Jul 2026 06:59:00 +0000Antonio GonzalezIn this episode of Cybersecurity Under Pressure: Real Attacks, Real Lessons, we look at what it really means to defend an industrial network when production, safety and uptime are part of the equation.Industrial environments are not protected by...2557falsefullhttps://www.spreaker.com/episode/industrial-5g-and-the-uptime-trap-when-connectivity-becomes-a-production-risk--728015437f208941-61fa-4448-a44b-c6454863f4d3Fri, 03 Jul 2026 07:00:00 +0000Antonio GonzalezIn this episode of Cybersecurity Under Pressure: Real Attacks, Real Lessons, we explore the hidden risk behind industrial 5G: the belief that better connectivity automatically means stronger resilience.Private 5G, edge computing and connected...2662falsefullhttps://www.spreaker.com/episode/hacking-ev-chargers-to-stress-the-grid-when-mobility-becomes-critical-infrastructure--7276751916ea4308-5f82-4820-8433-4e645bc84a03Wed, 01 Jul 2026 07:00:00 +0000Antonio Gonzalezn this episode of Cybersecurity Under Pressure: Real Attacks, Real Lessons, we explore why EV chargers should no longer be treated as simple connected devices.As electric mobility scales, charging infrastructure becomes part of a wider cyber-physical...2279falsefullhttps://www.spreaker.com/episode/teenage-hackers-and-software-defined-factories-when-industrial-risk-starts-with-identity--72737507792ed13c-c42c-4425-9895-2fd4c659a088Mon, 29 Jun 2026 07:00:00 +0000Antonio GonzalezIn this episode of Cybersecurity Under Pressure: Real Attacks, Real Lessons, we look at a uncomfortable shift in industrial cybersecurity: the attacker does not always need deep OT knowledge to create operational impact.As factories become more...2328falsefullhttps://www.spreaker.com/episode/the-compliance-theater-draining-supplier-r-d-and-breaking-automotive-silos--72699060dd01382c-d938-48d9-9a93-ca839b360d49Fri, 26 Jun 2026 07:00:00 +0000Antonio Gonzalezour Tier-2 supplier just spent 80,000 euros on compliance. Their product cybersecurity did not improve by a single cent.In this episode of "Cybersecurity Under Pressure: Real Attacks, Real Lessons," we look at the compliance trap the automotive...1821falsefullhttps://www.spreaker.com/episode/the-red-signal-paralyzing-a-railway-network-with-a-single-patch--72665842d4b30903-d2a2-418b-b6e8-e898e9cc943eWed, 24 Jun 2026 07:00:00 +0000Antonio GonzalezIn railway signaling, an uncoordinated security patch rarely causes a fatal accident. But it can paralyze an entire network.In this episode of Cybersecurity Under Pressure Real Attacks Real Lessons, we explore the structural tension between RAMS...2054falsefullhttps://www.spreaker.com/episode/the-shadow-corridor-legacy-vpns-and-the-financial-blast-radius-in-ot--7262782369f219e2-91d2-46a2-a0aa-73dccc503b9eMon, 22 Jun 2026 07:00:00 +0000Antonio GonzalezLast month, a maintenance technician connected to a Level 1 PLC via VPN to fix a sensor. He did not know he had just opened the only door an attacker needed.In this episode of Cybersecurity Under Pressure Real Attacks Real Lessons, we look at a quiet...2960falsefullhttps://www.spreaker.com/episode/missing-cybersecurity-evidence-can-delay-production--72595992b088eebc-e775-4f09-b2f8-1beace426a81Fri, 19 Jun 2026 07:00:00 +0000Antonio GonzalezThe next production delay may not come from a missing component. It may come from missing cybersecurity evidence.In this episode of Cybersecurity Under Pressure: real attacks, real lessons, we look at a growing risk in automotive supply chains:...2362falsefullhttps://www.spreaker.com/episode/an-idps-alert-is-not-an-incident-response-capability--7256040269415ea8-a3ce-4d36-bf93-1314aa0041f4Wed, 17 Jun 2026 07:00:00 +0000Antonio GonzalezDetecting a suspicious event in a vehicle is not the same as knowing what to do next.In this episode of Cybersecurity Under Pressure: real attacks, real lessons, we look at one of the weakest points in automotive cybersecurity: the gap between...2346falsefullhttps://www.spreaker.com/episode/the-restart-bottleneck-is-not-the-backup-it-is-the-evidence--72531618f63580c0-3b7e-4db2-8c6f-da3f6d0c5713Mon, 15 Jun 2026 07:00:00 +0000Antonio GonzalezAfter an OT cyber incident, restoring systems is only the visible part of recovery. The harder question comes next: who can prove that production is safe to restart?In this episode of Cybersecurity Under Pressure: real attacks, real lessons, we look...3265falsefullhttps://www.spreaker.com/episode/when-ecus-meet-malice--72495017In this episode we break down the critical intersection of product cybersecurity and factory cybersecurity, and explore the potential consequences of a compromised ECU flashing station. We walk through a real-world scenario where a flaw in the flashing process could lead to a supply chain crisis, and discuss the importance of bridging the gap between corporate and vehicle security teams. By the end of this episode, you'll understand the urgent need for a unified approach to automotive cybersecurity.
The reality is that a breach at the flashing station could have far-reaching consequences, from safety issues to reputational damage, and could change the way you think about the entire automotive supply chain.
Subscribe to our podcast for more insights into the latest cybersecurity threats and trends, and join the conversation on the most critical issues facing the industry today.
#automotivecybersecurity #cybersecuritymatters #supplychainrisk]]>b24256b8-76f1-4f76-999b-8ada333acb4fFri, 12 Jun 2026 07:00:00 +0000Antonio GonzalezWhat if the most vulnerable point in automotive cybersecurity isn't the car itself, but the station that gives it its software identity, setting the stage for a potential disaster that could put lives at risk. In this episode we break down the...In this episode we break down the critical intersection of product cybersecurity and factory cybersecurity, and explore the potential consequences of a compromised ECU flashing station. We walk through a real-world scenario where a flaw in the flashing process could lead to a supply chain crisis, and discuss the importance of bridging the gap between corporate and vehicle security teams. By the end of this episode, you'll understand the urgent need for a unified approach to automotive cybersecurity.
The reality is that a breach at the flashing station could have far-reaching consequences, from safety issues to reputational damage, and could change the way you think about the entire automotive supply chain.
Subscribe to our podcast for more insights into the latest cybersecurity threats and trends, and join the conversation on the most critical issues facing the industry today.
#automotivecybersecurity #cybersecuritymatters #supplychainrisk]]>1998falsefullhttps://www.spreaker.com/episode/zero-trust-meets-twenty-year-old-code--72454583In this episode we break down the challenges of implementing Zero Trust in industrial environments, where legacy devices don't speak the language of modern identity and security. We walk through real-world examples of how to design a Zero Trust architecture that works with, not against, these older systems. We argue that strong authentication and mediation are key to reducing exposure without disrupting production.
The distinction between a good and a bad Zero Trust design can be the difference between a secure and a breached industrial system, with very real consequences for the people and processes that rely on it.
Subscribe to our podcast for more insights into the intersection of security and industrial technology, and join the conversation about what it takes to protect our most critical systems.
#ZeroTrust #OTSecurity #IndustrialCybersecurity]]>ef75e48d-159d-4274-bfa6-757d12b65b2dWed, 10 Jun 2026 07:00:00 +0000Antonio GonzalezWhat happens when a twenty-year-old industrial control system meets the latest Zero Trust security protocols, and the two just can't seem to get along? In this episode we break down the challenges of implementing Zero Trust in industrial...In this episode we break down the challenges of implementing Zero Trust in industrial environments, where legacy devices don't speak the language of modern identity and security. We walk through real-world examples of how to design a Zero Trust architecture that works with, not against, these older systems. We argue that strong authentication and mediation are key to reducing exposure without disrupting production.
The distinction between a good and a bad Zero Trust design can be the difference between a secure and a breached industrial system, with very real consequences for the people and processes that rely on it.
Subscribe to our podcast for more insights into the intersection of security and industrial technology, and join the conversation about what it takes to protect our most critical systems.
#ZeroTrust #OTSecurity #IndustrialCybersecurity]]>2659falsefullhttps://www.spreaker.com/episode/beyond-backup-recovery--72413875In this episode we break down the real cost of an OT cyber incident, and explore the complexities of recovery in operational technology environments. We walk through a real case where the question is no longer just about restoring systems, but about proving that the process can be trusted again. We argue that many organisations are weaker than they think when it comes to validating engineering workstation integrity and confirming PLC logic.
The ability to quickly and effectively respond to an OT cyber incident can mean the difference between a minor disruption and a six-figure business problem, making it a critical consideration for anyone working in operational technology.
Subscribe to our podcast for more insights on the intersection of technology and business, and join the conversation on the real-world implications of OT cyber incidents.
#OTcybersecurity #operationaltechnology #industrialcontrolsystems]]>802711a0-213b-4203-9756-e1a48d34d681Mon, 08 Jun 2026 07:00:00 +0000Antonio GonzalezWhat happens when a production line grinds to a halt, not because of a technical failure, but because trust in the engineering environment has been lost? In this episode we break down the real cost of an OT cyber incident, and explore the complexities...In this episode we break down the real cost of an OT cyber incident, and explore the complexities of recovery in operational technology environments. We walk through a real case where the question is no longer just about restoring systems, but about proving that the process can be trusted again. We argue that many organisations are weaker than they think when it comes to validating engineering workstation integrity and confirming PLC logic.
The ability to quickly and effectively respond to an OT cyber incident can mean the difference between a minor disruption and a six-figure business problem, making it a critical consideration for anyone working in operational technology.
Subscribe to our podcast for more insights on the intersection of technology and business, and join the conversation on the real-world implications of OT cyber incidents.
#OTcybersecurity #operationaltechnology #industrialcontrolsystems]]>1822falsefullhttps://www.spreaker.com/episode/cyber-gaps-in-automotive-supply--72363819In this episode we break down the messy world of automotive cybersecurity, where gaps in responsibility between companies can put entire systems at risk. We walk through real-world scenarios where the lack of clear agreements and ownership can lead to major problems. We argue that these gaps are not just technical issues, but also governance problems that need to be addressed.
The consequences of these gaps can be severe, from compromised vehicle safety to significant financial losses, making it essential for companies to rethink their approach to cybersecurity and liability.
Subscribe to our podcast to dive deeper into the complex world of automotive cybersecurity and learn how to navigate these critical issues.
#automotivecybersecurity #cybersecuritymatters #supplychainrisk]]>6e6cc4a9-e486-4330-b2ec-8a6aafcc8714Fri, 05 Jun 2026 07:00:00 +0000Antonio GonzalezWhat happens when a vulnerability is discovered in a car's system after production has started, and nobody knows who's responsible for fixing it? In this episode we break down the messy world of automotive cybersecurity, where gaps in responsibility...In this episode we break down the messy world of automotive cybersecurity, where gaps in responsibility between companies can put entire systems at risk. We walk through real-world scenarios where the lack of clear agreements and ownership can lead to major problems. We argue that these gaps are not just technical issues, but also governance problems that need to be addressed.
The consequences of these gaps can be severe, from compromised vehicle safety to significant financial losses, making it essential for companies to rethink their approach to cybersecurity and liability.
Subscribe to our podcast to dive deeper into the complex world of automotive cybersecurity and learn how to navigate these critical issues.
#automotivecybersecurity #cybersecuritymatters #supplychainrisk]]>1920falsefullhttps://www.spreaker.com/episode/when-patches-stop-production--72316614In this episode we break down the nuances of patch management in industrial environments, where the stakes are high and the consequences of a mistake can be devastating. We walk through real-world scenarios where a simple patch can bring down an entire production line, and explore the delicate balance between cybersecurity and operational continuity. We argue that a one-size-fits-all approach to patching is no longer tenable.
The ability to manage vulnerabilities in industrial environments has a direct impact on the bottom line, as a single misstep can result in costly downtime and damaged equipment.
Subscribe to our podcast to hear more about the complexities of OT vulnerability management and how to navigate the treacherous landscape of patching and cybersecurity.
#IndustrialCybersecurity #PatchManagement #OTVulnerabilityManagement]]>39a82749-4cbe-4abc-8f11-92519c5c443bWed, 03 Jun 2026 07:49:00 +0000Antonio GonzalezWhat happens when a security patch intended to protect your system ends up being the cause of a catastrophic operational incident? In this episode we break down the nuances of patch management in industrial environments, where the stakes are high and...In this episode we break down the nuances of patch management in industrial environments, where the stakes are high and the consequences of a mistake can be devastating. We walk through real-world scenarios where a simple patch can bring down an entire production line, and explore the delicate balance between cybersecurity and operational continuity. We argue that a one-size-fits-all approach to patching is no longer tenable.
The ability to manage vulnerabilities in industrial environments has a direct impact on the bottom line, as a single misstep can result in costly downtime and damaged equipment.
Subscribe to our podcast to hear more about the complexities of OT vulnerability management and how to navigate the treacherous landscape of patching and cybersecurity.
#IndustrialCybersecurity #PatchManagement #OTVulnerabilityManagement]]>2501falsefullhttps://www.spreaker.com/episode/ransomware-beyond-encryption--72273120In this episode we break down the grey zone where ransomware attacks on operational technology can have devastating consequences, and explore the often-overlooked vulnerabilities that can allow attackers to move undetected between IT and OT systems. We walk through real-world scenarios where a simple login can enable access to sensitive areas of your operation, and discuss the importance of understanding the trust, exposure, and consequence of your assets.
The reality is that many organizations are unaware of the risks lurking in the spaces between their IT and OT systems, and the consequences of a breach can be catastrophic, resulting in lost production time, damaged equipment, and compromised safety.
Subscribe to our podcast to stay ahead of the threats and learn how to protect your operation from these emerging risks.
#IndustrialCyberSecurity #Ransomware #OperationalTechnology]]>d36db0fe-636d-4175-9912-8062f54a03b2Mon, 01 Jun 2026 07:00:00 +0000Antonio GonzalezWhat if a single login credential was all a hacker needed to bring your entire production line to a grinding halt, without even touching your industrial control systems? In this episode we break down the grey zone where ransomware attacks on...In this episode we break down the grey zone where ransomware attacks on operational technology can have devastating consequences, and explore the often-overlooked vulnerabilities that can allow attackers to move undetected between IT and OT systems. We walk through real-world scenarios where a simple login can enable access to sensitive areas of your operation, and discuss the importance of understanding the trust, exposure, and consequence of your assets.
The reality is that many organizations are unaware of the risks lurking in the spaces between their IT and OT systems, and the consequences of a breach can be catastrophic, resulting in lost production time, damaged equipment, and compromised safety.
Subscribe to our podcast to stay ahead of the threats and learn how to protect your operation from these emerging risks.
#IndustrialCyberSecurity #Ransomware #OperationalTechnology]]>2381falsefullhttps://www.spreaker.com/episode/beyond-asset-coverage--72222282In this episode we break down the flaws in traditional network visibility programs and explore how microsegmentation can limit the damage of unseen assets. We walk through real-world examples of how IT dependencies and vendor access have led to devastating breaches, and discuss the importance of structuring conversations around asset risk and function.
By the end of this episode, you'll understand why treating inventory as a containment strategy is a recipe for disaster, and how a different approach can save you from costly disruptions.
Subscribe to our podcast for more insights on how to secure your network and stay one step ahead of emerging threats.
#cybersecurity #networkvisibility #microsegmentation]]>5b03d046-b5b5-4c06-880b-c05f84615bedFri, 29 May 2026 07:00:00 +0000Antonio GonzalezCan a single overlooked device really bring down your entire network, and are you unwittingly leaving the door open to cyberattacks by focusing on the wrong security strategy? In this episode we break down the flaws in traditional network visibility...In this episode we break down the flaws in traditional network visibility programs and explore how microsegmentation can limit the damage of unseen assets. We walk through real-world examples of how IT dependencies and vendor access have led to devastating breaches, and discuss the importance of structuring conversations around asset risk and function.
By the end of this episode, you'll understand why treating inventory as a containment strategy is a recipe for disaster, and how a different approach can save you from costly disruptions.
Subscribe to our podcast for more insights on how to secure your network and stay one step ahead of emerging threats.
#cybersecurity #networkvisibility #microsegmentation]]>1804falsefullhttps://www.spreaker.com/episode/when-containment-fails-recovery--72203274In this episode we break down the disconnect between IT and engineering timelines, and explore how the NIS2 directive is raising the bar for incident recovery and accountability. We walk through the implications of Articles 20, 21, and 34, and what they mean for management bodies and cybersecurity teams. We argue that a single incident command model is the key to true recovery.
The ability to recover from a cyber incident quickly and effectively is no longer a nice-to-have, but a critical component of business continuity and risk management.
Subscribe to our podcast for more insights on cybersecurity and operational risk, and join the conversation on how to stay ahead of emerging threats.
#cybersecurity #NIS2 #incidentrecovery #operationalrisk #businesscontinuity]]>7a13eb6c-1a93-42e6-8d40-707f22ffbcb2Thu, 28 May 2026 07:00:00 +0000Antonio GonzalezWhat if your team contained a cyber incident, but the real damage was only just beginning? In this episode we break down the disconnect between IT and engineering timelines, and explore how the NIS2 directive is raising the bar for incident recovery...In this episode we break down the disconnect between IT and engineering timelines, and explore how the NIS2 directive is raising the bar for incident recovery and accountability. We walk through the implications of Articles 20, 21, and 34, and what they mean for management bodies and cybersecurity teams. We argue that a single incident command model is the key to true recovery.
The ability to recover from a cyber incident quickly and effectively is no longer a nice-to-have, but a critical component of business continuity and risk management.
Subscribe to our podcast for more insights on cybersecurity and operational risk, and join the conversation on how to stay ahead of emerging threats.
#cybersecurity #NIS2 #incidentrecovery #operationalrisk #businesscontinuity]]>1904falsefullhttps://www.spreaker.com/episode/exposed-paths-in-ot-networks--72151327In this episode we break down the hidden dangers of insecure remote access conditions and explore why PAM is not failing in OT, but rather being asked to enforce a physical work state it cannot see. We walk through real-world examples of exposed engineering paths and unpatched VPNs, and discuss the consequences of a visibility gap between operations and network access. We argue that the problem lies not with the tools, but with the disconnection between different states that never converge.
The reality is that this gap can have devastating consequences, from allowing attackers to gain access to sensitive systems to putting entire operations at risk.
Subscribe to our podcast to learn more about the intersection of industrial control systems and cybersecurity, and to stay up to date on the latest threats and solutions.
#OTSecurity #ZeroTrust #IndustrialCybersecurity]]>a6b5033f-49a9-4389-b5ff-f29222aa4191Mon, 25 May 2026 07:00:00 +0000Antonio GonzalezWhat if the biggest security risk to your industrial control systems isn't a malicious hacker, but rather a simple disconnect between when a work order closes and when network access is actually shut off? In this episode we break down the hidden...In this episode we break down the hidden dangers of insecure remote access conditions and explore why PAM is not failing in OT, but rather being asked to enforce a physical work state it cannot see. We walk through real-world examples of exposed engineering paths and unpatched VPNs, and discuss the consequences of a visibility gap between operations and network access. We argue that the problem lies not with the tools, but with the disconnection between different states that never converge.
The reality is that this gap can have devastating consequences, from allowing attackers to gain access to sensitive systems to putting entire operations at risk.
Subscribe to our podcast to learn more about the intersection of industrial control systems and cybersecurity, and to stay up to date on the latest threats and solutions.
#OTSecurity #ZeroTrust #IndustrialCybersecurity]]>2622falsefullhttps://www.spreaker.com/episode/shipping-the-code-that-security-rejected--72094745In this episode, we break down why the shift to software-defined vehicles is currently failing at the release gate. We walk through the uncomfortable reality of SOP pressure and argue that current security assessments are often treated as advisory rather than hard controls.
It is time to stop asking for attention and start controlling the release, because a "safe" binary that your organization doesn't actually understand is just a liability waiting to happen.
Drop your take in the comments or share this episode with a colleague who is fighting against weak provenance and unrealistic deadlines right now.
#AutomotiveCybersecurity #SDV #SupplyChainSecurity #CyberSecurity #AutomotiveSoftware]]>b976cf08-096f-4753-a825-cca91260a8e5Thu, 21 May 2026 07:21:00 +0000Antonio GonzalezYour vehicle's biggest security threat might be arriving with a perfectly valid digital signature and your company's own stamp of approval. In this episode, we break down why the shift to software-defined vehicles is currently failing at the release...In this episode, we break down why the shift to software-defined vehicles is currently failing at the release gate. We walk through the uncomfortable reality of SOP pressure and argue that current security assessments are often treated as advisory rather than hard controls.
It is time to stop asking for attention and start controlling the release, because a "safe" binary that your organization doesn't actually understand is just a liability waiting to happen.
Drop your take in the comments or share this episode with a colleague who is fighting against weak provenance and unrealistic deadlines right now.
#AutomotiveCybersecurity #SDV #SupplyChainSecurity #CyberSecurity #AutomotiveSoftware]]>1961falsefullhttps://www.spreaker.com/episode/when-a-patch-reopens-the-safety-case--72081062In this episode, we break down the high-stakes collision between the new Cyber Resilience Act and the rigid, uncompromising world of railway safety certification. We walk through why architectural perfection is a myth for brownfield systems and how to use protocol-aware filtering to keep your network secure without triggering a massive, budget-breaking reassessment.
We argue that the strongest cyber programs are not the ones with the fastest patch cycles, but the ones that know how to improve risk posture while keeping the trains moving. This conversation is about making security maintenance survivable in a sector where you simply cannot afford to touch the binary.
Subscribe to the show and share this episode with anyone currently trying to navigate the impossible tension between rapid response and safety-critical stability.
#RailCybersecurity #CyberResilienceAct #CriticalInfrastructure #OTSecurity]]>32558916-a96a-4b19-9ce3-59fc9719810eWed, 20 May 2026 07:25:00 +0000Antonio GonzalezA simple security patch can fix a vulnerability and still become a total operational nightmare that brings an entire railway network to a standstill. In this episode, we break down the high-stakes collision between the new Cyber Resilience Act and the...In this episode, we break down the high-stakes collision between the new Cyber Resilience Act and the rigid, uncompromising world of railway safety certification. We walk through why architectural perfection is a myth for brownfield systems and how to use protocol-aware filtering to keep your network secure without triggering a massive, budget-breaking reassessment.
We argue that the strongest cyber programs are not the ones with the fastest patch cycles, but the ones that know how to improve risk posture while keeping the trains moving. This conversation is about making security maintenance survivable in a sector where you simply cannot afford to touch the binary.
Subscribe to the show and share this episode with anyone currently trying to navigate the impossible tension between rapid response and safety-critical stability.
#RailCybersecurity #CyberResilienceAct #CriticalInfrastructure #OTSecurity]]>2379falsefullhttps://www.spreaker.com/episode/the-trap-of-the-trusted-engineering-session--72065954In this episode, we break down why relying on MFA and session monitoring is just giving you a front-row seat to your own incident. We walk through the reality of session hijacking in brownfield OT and argue why the network should never be the one deciding who gets to touch the control layer.
This is about the high-stakes shift from letting the network decide your fate to putting the power back into the hands of the operators on the floor. It is the only way to withdraw digital authority before a trusted session becomes a physical catastrophe.
Subscribe to the show and share this with someone who still thinks a secure tunnel is a silver bullet for industrial safety.
#OTSecurity #Cybersecurity #CriticalInfrastructure #IndustrialAutomation]]>0ebd32a5-04d8-443a-8198-f6068a90ccacTue, 19 May 2026 07:18:00 +0000Antonio GonzalezYour VPN is lying to you about how safe your plant actually is. In this episode, we break down why relying on MFA and session monitoring is just giving you a front-row seat to your own incident. We walk through the reality of session hijacking in...In this episode, we break down why relying on MFA and session monitoring is just giving you a front-row seat to your own incident. We walk through the reality of session hijacking in brownfield OT and argue why the network should never be the one deciding who gets to touch the control layer.
This is about the high-stakes shift from letting the network decide your fate to putting the power back into the hands of the operators on the floor. It is the only way to withdraw digital authority before a trusted session becomes a physical catastrophe.
Subscribe to the show and share this with someone who still thinks a secure tunnel is a silver bullet for industrial safety.
#OTSecurity #Cybersecurity #CriticalInfrastructure #IndustrialAutomation]]>3164falsefullhttps://www.spreaker.com/episode/when-vex-becomes-a-bureaucratic-shield--72017592In this episode, we look past the hype of vulnerability scanning to the uncomfortable reality of the software-defined vehicle. We walk through how suppliers are using VEX as a bureaucratic shield to dodge patches and why your security program is likely just a mountain of expensive noise.
We argue that if you are not prepared to challenge a supplier's claim with technical evidence, you are not doing security—you are just doing paperwork. This conversation is about moving from a flood of findings to actual, defensible risk management that protects the driver, not just the budget.
Subscribe and share this with a security lead who is tired of chasing ghosts in their supply chain.
#cybersecurity #automotive #supplychain #SBOM #VEX]]>0c3d79b3-1f33-47fc-8c9e-a3cbc35ad263Fri, 15 May 2026 07:00:00 +0000Antonio GonzalezYour SBOM is probably useless, and it is time we talked about why. In this episode, we look past the hype of vulnerability scanning to the uncomfortable reality of the software-defined vehicle. We walk through how suppliers are using VEX as a...In this episode, we look past the hype of vulnerability scanning to the uncomfortable reality of the software-defined vehicle. We walk through how suppliers are using VEX as a bureaucratic shield to dodge patches and why your security program is likely just a mountain of expensive noise.
We argue that if you are not prepared to challenge a supplier's claim with technical evidence, you are not doing security—you are just doing paperwork. This conversation is about moving from a flood of findings to actual, defensible risk management that protects the driver, not just the budget.
Subscribe and share this with a security lead who is tired of chasing ghosts in their supply chain.
#cybersecurity #automotive #supplychain #SBOM #VEX]]>1831falsefullhttps://www.spreaker.com/episode/why-frmcs-cannot-trust-the-mobile-carrier--71987335In this episode, we break down why FRMCS cannot depend on the goodwill of a mobile operator, regardless of how low the latency claims are. We explore the logic of EN 50159 and explain why the only way to build a truly resilient railway architecture is to assume the network is already hostile, degraded, or failing.
Understanding this distinction is the difference between a system that works on paper and one that actually keeps passengers safe when the transport layer inevitably breaks.
Subscribe to the show and share this episode with an engineer who needs a reality check on 5G.
#FRMCS #RailCybersecurity #ETCS #CriticalCommunications #OTSecurity]]>6305e5ff-bcbe-4edd-af57-1338fc123a54Wed, 13 May 2026 07:00:00 +0000Antonio GonzalezYour 5G service level agreement is not a safety case, and confusing the two is a dangerous mistake for the future of rail. In this episode, we break down why FRMCS cannot depend on the goodwill of a mobile operator, regardless of how low the latency...In this episode, we break down why FRMCS cannot depend on the goodwill of a mobile operator, regardless of how low the latency claims are. We explore the logic of EN 50159 and explain why the only way to build a truly resilient railway architecture is to assume the network is already hostile, degraded, or failing.
Understanding this distinction is the difference between a system that works on paper and one that actually keeps passengers safe when the transport layer inevitably breaks.
Subscribe to the show and share this episode with an engineer who needs a reality check on 5G.
#FRMCS #RailCybersecurity #ETCS #CriticalCommunications #OTSecurity]]>2125falsefullhttps://www.spreaker.com/episode/the-token-that-bypassed-the-jump-host--71954019In this episode, we break down why your current MFA strategy is failing to stop session theft and what it actually takes to secure the engineering zone. We walk through the technical steps of removing NTLM and binding sessions to device posture so a compromised corporate credential never touches your controllers.
It is time to face the uncomfortable truth that real OT maturity requires redesigning how we handle third-party access before a hijacked session makes the decision for you.
Subscribe to the show and share this with the person in your organization who still thinks a VPN is a silver bullet.
#OTSecurity #CyberSecurity #IndustrialAutomation #IdentityManagement]]>3d15045c-c867-45fd-ac81-d6859fa57e12Mon, 11 May 2026 07:00:00 +0000Antonio GonzalezMost industrial security teams are betting their entire plant floor on a jump server that an attacker can bypass in seconds. In this episode, we break down why your current MFA strategy is failing to stop session theft and what it actually takes to...In this episode, we break down why your current MFA strategy is failing to stop session theft and what it actually takes to secure the engineering zone. We walk through the technical steps of removing NTLM and binding sessions to device posture so a compromised corporate credential never touches your controllers.
It is time to face the uncomfortable truth that real OT maturity requires redesigning how we handle third-party access before a hijacked session makes the decision for you.
Subscribe to the show and share this with the person in your organization who still thinks a VPN is a silver bullet.
#OTSecurity #CyberSecurity #IndustrialAutomation #IdentityManagement]]>2131falsefullhttps://www.spreaker.com/episode/poisoning-the-software-defined-vehicle-at-birth--71919959In this episode, we challenge the industry obsession with supplier code and shift the focus to the high-stakes world of cryptographic provisioning on the plant floor. We break down why a verifiable SBOM is only half the battle and how to implement fleet-scale monitoring that actually filters out the noise before it hits your cloud.
The hard truth is that if the manufacturing environment isn't trustworthy, every security layer you add later is just a house of cards.
Subscribe to the show and share this with anyone building the next generation of software-defined vehicles.
#automotivecybersecurity #supplychain #infosec #softwaredefinedvehicle #iotsecurity]]>ef7c258d-a68e-4cb2-bcfb-a68d2fd973d2Fri, 08 May 2026 07:00:00 +0000Antonio GonzalezYour vehicle’s security might be dead on arrival if the very network that birthed it was already compromised. In this episode, we challenge the industry obsession with supplier code and shift the focus to the high-stakes world of cryptographic...In this episode, we challenge the industry obsession with supplier code and shift the focus to the high-stakes world of cryptographic provisioning on the plant floor. We break down why a verifiable SBOM is only half the battle and how to implement fleet-scale monitoring that actually filters out the noise before it hits your cloud.
The hard truth is that if the manufacturing environment isn't trustworthy, every security layer you add later is just a house of cards.
Subscribe to the show and share this with anyone building the next generation of software-defined vehicles.
#automotivecybersecurity #supplychain #infosec #softwaredefinedvehicle #iotsecurity]]>2022falsefullhttps://www.spreaker.com/episode/why-rail-operators-fear-the-patch--71886530In this episode, we break down why the standard patch or perish mindset fails when a single software update becomes an operational gamble with safety and timetables. We walk through the reality of TS 50701 and explore how data diodes and strict physical segregation provide a path forward for legacy interlockings.
If you are securing critical rail assets, you need to stop chasing the perfect patch and start building resilience that does not require a return route into your train control domain.
Subscribe to the show and share this with the engineer who is tired of being told to just update their firmware.
#railsecurity #cybersecurity #criticalinfrastructure #otsecurity #ts50701]]>bcda36ee-ef7a-446a-b8a9-e57e697b9ce7Wed, 06 May 2026 07:00:00 +0000Antonio GonzalezMost people think rail cybersecurity is a patching problem, but it is actually a validation nightmare that can stop your entire network in its tracks. In this episode, we break down why the standard patch or perish mindset fails when a single software...In this episode, we break down why the standard patch or perish mindset fails when a single software update becomes an operational gamble with safety and timetables. We walk through the reality of TS 50701 and explore how data diodes and strict physical segregation provide a path forward for legacy interlockings.
If you are securing critical rail assets, you need to stop chasing the perfect patch and start building resilience that does not require a return route into your train control domain.
Subscribe to the show and share this with the engineer who is tired of being told to just update their firmware.
#railsecurity #cybersecurity #criticalinfrastructure #otsecurity #ts50701]]>2478falsefullhttps://www.spreaker.com/episode/when-physics-is-the-final-firewall--71850589In this episode, we’re getting real about why legacy PLCs were never meant for modern crypto and how forcing it can actually tank your process. We walk through why deep packet inspection is often a trap and how to build a defense-in-depth strategy that moves from the network all the way down to the laws of physics. 🏗️
You need to know where the digital controls end and the mechanical interlocks begin before a "security" update shuts down your entire line. 📉
Hit subscribe to stay ahead of the curve, and drop your take on out-of-band vs. inline in the comments.
#OTSecurity #IndustrialCyber #CyberPhysics #ICS]]>3596ba2c-a599-4909-b038-a18015490cfcMon, 04 May 2026 07:00:00 +0000Antonio GonzalezIf you think your OT security problem is a lack of awareness, you’re missing the fact that your hardware literally cannot handle the solution. 🔌 In this episode, we’re getting real about why legacy PLCs were never meant for modern crypto and how...In this episode, we’re getting real about why legacy PLCs were never meant for modern crypto and how forcing it can actually tank your process. We walk through why deep packet inspection is often a trap and how to build a defense-in-depth strategy that moves from the network all the way down to the laws of physics. 🏗️
You need to know where the digital controls end and the mechanical interlocks begin before a "security" update shuts down your entire line. 📉
Hit subscribe to stay ahead of the curve, and drop your take on out-of-band vs. inline in the comments.
#OTSecurity #IndustrialCyber #CyberPhysics #ICS]]>2388falsefullhttps://www.spreaker.com/episode/that-is-the-part-many-cybersecurity-plans-still-miss-ot-controls-under-revision--71808996#RailCybersecurity #CBTC #EN50129 #TS50701 #IEC62443 #DPI #OTSecurity #Railway
🎯 IN THIS EPISODE:• Railway and transportation cybersecurity• AI and machine learning security risks
📋 KEY TOPICS COVERED:• Railway Cybersecurity• AI Security
🔑 KEY INSIGHTS:1. The smartest OT control in rail is often the one that leaves the certified core untouched2. That is the part many cybersecurity plans still miss3. In a CBTC or signalling environment, segmentation is not just a network design exercise
🔧 TECHNOLOGIES & STANDARDS:CERT • IEC • CAN Bus • ECU • CBTC
👥 WHO SHOULD LISTEN:This episode is perfect for CISOs, OT security engineers, infrastructure operators, compliance officers, cybersecurity consultants, and anyone responsible for protecting critical systems.
💡 WHAT YOU WILL LEARN:• How real attacks unfold in OT/ICS environments• Practical defense strategies you can implement today• Compliance considerations (NIS2, IEC 62443, NIST)• Lessons from recent high-profile incidents
🎧 SUBSCRIBE & CONNECT:Subscribe for weekly deep dives into real cybersecurity incidents affecting OT, ICS, and critical infrastructure. New episodes every week.
💬 ENGAGE WITH US:Have questions or topics you'd like us to cover? Reach out! We love hearing from our community.
#OTSecurity #OperationalTechnology #RailwaySecurity #TransportSecurity #AISecurity #MachineLearning #ThreatIntel #CyberThreats #CyberSecurity #InfoSec #CybersecurityUnderPressure]]>6f015cef-afab-4be9-9654-043670037961Fri, 01 May 2026 07:00:00 +0000Antonio GonzalezThe smartest OT control in rail is often the one that leaves the certified core untouched #RailCybersecurity #CBTC #EN50129 #TS50701 #IEC62443 #DPI #OTSecurity #Railway 🎯 IN THIS EPISODE:• Railway and transportation cybersecurity• AI and machine...#RailCybersecurity #CBTC #EN50129 #TS50701 #IEC62443 #DPI #OTSecurity #Railway
🎯 IN THIS EPISODE:• Railway and transportation cybersecurity• AI and machine learning security risks
📋 KEY TOPICS COVERED:• Railway Cybersecurity• AI Security
🔑 KEY INSIGHTS:1. The smartest OT control in rail is often the one that leaves the certified core untouched2. That is the part many cybersecurity plans still miss3. In a CBTC or signalling environment, segmentation is not just a network design exercise
🔧 TECHNOLOGIES & STANDARDS:CERT • IEC • CAN Bus • ECU • CBTC
👥 WHO SHOULD LISTEN:This episode is perfect for CISOs, OT security engineers, infrastructure operators, compliance officers, cybersecurity consultants, and anyone responsible for protecting critical systems.
💡 WHAT YOU WILL LEARN:• How real attacks unfold in OT/ICS environments• Practical defense strategies you can implement today• Compliance considerations (NIS2, IEC 62443, NIST)• Lessons from recent high-profile incidents
🎧 SUBSCRIBE & CONNECT:Subscribe for weekly deep dives into real cybersecurity incidents affecting OT, ICS, and critical infrastructure. New episodes every week.
💬 ENGAGE WITH US:Have questions or topics you'd like us to cover? Reach out! We love hearing from our community.
#OTSecurity #OperationalTechnology #RailwaySecurity #TransportSecurity #AISecurity #MachineLearning #ThreatIntel #CyberThreats #CyberSecurity #InfoSec #CybersecurityUnderPressure]]>2100falsefullhttps://www.spreaker.com/episode/supply-chain-when-the-supplier-will-not-cooperate-resilience-must-become--71727992Too many OT risk programs still assume the vendor will help when it matters. In real plants, that assumption breaks fast. Large integrators often resist SBOM requests, reject monitoring agents, and defend remote access as if it were untouchable because of warranty, latency or system integrity.
🎯 IN THIS EPISODE:• Regulatory compliance frameworks (NIS2, IEC 62443)• NIST cybersecurity framework implementation• AI and machine learning security risks• Supply chain security and third-party risk
📋 KEY TOPICS COVERED:• Supply Chain Security• AI Security
🔑 KEY INSIGHTS:1. When the supplier will not cooperate, resilience must become hostile2. Too many OT risk programs still assume the vendor will help when it matters3. In real plants, that assumption breaks fast
🔧 TECHNOLOGIES & STANDARDS:NIST • ISO • IEC • PLC • CAN Bus • ECU
👥 WHO SHOULD LISTEN:This episode is perfect for CISOs, OT security engineers, infrastructure operators, compliance officers, cybersecurity consultants, and anyone responsible for protecting critical systems.
💡 WHAT YOU WILL LEARN:• How real attacks unfold in OT/ICS environments• Practical defense strategies you can implement today• Compliance considerations (NIS2, IEC 62443, NIST)• Lessons from recent high-profile incidents
🎧 SUBSCRIBE & CONNECT:Subscribe for weekly deep dives into real cybersecurity incidents affecting OT, ICS, and critical infrastructure. New episodes every week.
💬 ENGAGE WITH US:Have questions or topics you'd like us to cover? Reach out! We love hearing from our community.
#OTSecurity #OperationalTechnology #AISecurity #MachineLearning #SupplyChain #ThirdPartyRisk #Compliance #CyberSecurity #InfoSec #CybersecurityUnderPressure]]>40d42073-d28b-46ae-8c1c-d74b78747389Wed, 29 Apr 2026 07:00:00 +0000Antonio GonzalezWhen the supplier will not cooperate, resilience must become hostile Too many OT risk programs still assume the vendor will help when it matters. In real plants, that assumption breaks fast. Large integrators often resist SBOM requests, reject...Too many OT risk programs still assume the vendor will help when it matters. In real plants, that assumption breaks fast. Large integrators often resist SBOM requests, reject monitoring agents, and defend remote access as if it were untouchable because of warranty, latency or system integrity.
🎯 IN THIS EPISODE:• Regulatory compliance frameworks (NIS2, IEC 62443)• NIST cybersecurity framework implementation• AI and machine learning security risks• Supply chain security and third-party risk
📋 KEY TOPICS COVERED:• Supply Chain Security• AI Security
🔑 KEY INSIGHTS:1. When the supplier will not cooperate, resilience must become hostile2. Too many OT risk programs still assume the vendor will help when it matters3. In real plants, that assumption breaks fast
🔧 TECHNOLOGIES & STANDARDS:NIST • ISO • IEC • PLC • CAN Bus • ECU
👥 WHO SHOULD LISTEN:This episode is perfect for CISOs, OT security engineers, infrastructure operators, compliance officers, cybersecurity consultants, and anyone responsible for protecting critical systems.
💡 WHAT YOU WILL LEARN:• How real attacks unfold in OT/ICS environments• Practical defense strategies you can implement today• Compliance considerations (NIS2, IEC 62443, NIST)• Lessons from recent high-profile incidents
🎧 SUBSCRIBE & CONNECT:Subscribe for weekly deep dives into real cybersecurity incidents affecting OT, ICS, and critical infrastructure. New episodes every week.
💬 ENGAGE WITH US:Have questions or topics you'd like us to cover? Reach out! We love hearing from our community.
#OTSecurity #OperationalTechnology #AISecurity #MachineLearning #SupplyChain #ThirdPartyRisk #Compliance #CyberSecurity #InfoSec #CybersecurityUnderPressure]]>2022falsefullhttps://www.spreaker.com/episode/zero-trust-in-ot-does-not-start-at-the-hmi--71668008That is why mature OT security does not force cloud-style identity into the final device when the device, and the workflow around it, were never built for it.
🎯 IN THIS EPISODE:• Zero Trust architecture in OT environments• Automotive and connected vehicle security• AI and machine learning security risks• Identity and credential-based attacks• Authentication and access control weaknesses
📋 KEY TOPICS COVERED:• OT Security• Zero Trust Architecture• Automotive Security• AI Security• Credential-Based Attacks
🔑 KEY INSIGHTS:1. Zero Trust in OT does not start at the HMI2. It starts where incentives break traceability3. On an automotive assembly line, asking every operator to use strict modern identity on a shared HMI looks great on a slide
🔧 TECHNOLOGIES & STANDARDS:ISO • IEC • HMI • ECU
👥 WHO SHOULD LISTEN:This episode is perfect for CISOs, OT security engineers, infrastructure operators, compliance officers, cybersecurity consultants, and anyone responsible for protecting critical systems.
💡 WHAT YOU WILL LEARN:• How real attacks unfold in OT/ICS environments• Practical defense strategies you can implement today• Compliance considerations (NIS2, IEC 62443, NIST)• Lessons from recent high-profile incidents
🎧 SUBSCRIBE & CONNECT:Subscribe for weekly deep dives into real cybersecurity incidents affecting OT, ICS, and critical infrastructure. New episodes every week.
💬 ENGAGE WITH US:Have questions or topics you'd like us to cover? Reach out! We love hearing from our community.
#OTSecurity #OperationalTechnology #AutomotiveSecurity #ConnectedCar #ZeroTrust #IdentitySecurity #AISecurity #MachineLearning #Authentication #CyberSecurity #InfoSec #CybersecurityUnderPressure]]>8eb4a206-dcf4-4868-8780-5d340dc70f7fMon, 27 Apr 2026 07:00:00 +0000Antonio GonzalezZero Trust in OT does not start at the HMI That is why mature OT security does not force cloud-style identity into the final device when the device, and the workflow around it, were never built for it. 🎯 IN THIS EPISODE:• Zero Trust architecture in OT...That is why mature OT security does not force cloud-style identity into the final device when the device, and the workflow around it, were never built for it.
🎯 IN THIS EPISODE:• Zero Trust architecture in OT environments• Automotive and connected vehicle security• AI and machine learning security risks• Identity and credential-based attacks• Authentication and access control weaknesses
📋 KEY TOPICS COVERED:• OT Security• Zero Trust Architecture• Automotive Security• AI Security• Credential-Based Attacks
🔑 KEY INSIGHTS:1. Zero Trust in OT does not start at the HMI2. It starts where incentives break traceability3. On an automotive assembly line, asking every operator to use strict modern identity on a shared HMI looks great on a slide
🔧 TECHNOLOGIES & STANDARDS:ISO • IEC • HMI • ECU
👥 WHO SHOULD LISTEN:This episode is perfect for CISOs, OT security engineers, infrastructure operators, compliance officers, cybersecurity consultants, and anyone responsible for protecting critical systems.
💡 WHAT YOU WILL LEARN:• How real attacks unfold in OT/ICS environments• Practical defense strategies you can implement today• Compliance considerations (NIS2, IEC 62443, NIST)• Lessons from recent high-profile incidents
🎧 SUBSCRIBE & CONNECT:Subscribe for weekly deep dives into real cybersecurity incidents affecting OT, ICS, and critical infrastructure. New episodes every week.
💬 ENGAGE WITH US:Have questions or topics you'd like us to cover? Reach out! We love hearing from our community.
#OTSecurity #OperationalTechnology #AutomotiveSecurity #ConnectedCar #ZeroTrust #IdentitySecurity #AISecurity #MachineLearning #Authentication #CyberSecurity #InfoSec #CybersecurityUnderPressure]]>1768falsefullhttps://www.spreaker.com/episode/2026-critical-the-nis2-problem-is-no-longer-whether-the-incident-response--71608657The NIS2 problem is no longer whether the small supplier agrees with the requirement
🎯 IN THIS EPISODE:

• ​ Critical vulnerability assessments and mitigations
• ​ AI and machine learning security risks
• ​ Incident response and crisis management

📋 KEY TOPICS COVERED:

• ​ NIS2 Compliance
• ​ AI Security

🔑 KEY INSIGHTS:

1. ​ The NIS2 problem is no longer whether the small supplier agrees with the requirement
2. ​ It is whether they can afford to live inside it
3. ​ That is where many industrial programmes are hitting the wall

🔧 TECHNOLOGIES & STANDARDS:CAN Bus • ECU
👥 WHO SHOULD LISTEN:This episode is perfect for CISOs, OT security engineers, infrastructure operators, compliance officers, cybersecurity consultants, and anyone responsible for protecting critical systems.
💡 WHAT YOU WILL LEARN:

• ​ How real attacks unfold in OT/ICS environments
• ​ Practical defense strategies you can implement today
• ​ Compliance considerations (NIS2, IEC 62443, NIST)
• ​ Lessons from recent high-profile incidents

🎧 SUBSCRIBE & CONNECT:Subscribe for weekly deep dives into real cybersecurity incidents affecting OT, ICS, and critical infrastructure. New episodes every week.
💬 ENGAGE WITH US:Have questions or topics you'd like us to cover? Reach out! We love hearing from our community.
#OTSecurity #OperationalTechnology #NIS2 #EUCybersecurity #AISecurity #MachineLearning #IncidentResponse #SOC #CriticalInfrastructure #CIP #CyberSecurity #InfoSec]]>01c12c2a-f4dd-404c-a8c2-80c426a4dce2Fri, 24 Apr 2026 07:00:00 +0000Antonio GonzalezThe NIS2 problem is no longer whether the small supplier agrees with the requirement The NIS2 problem is no longer whether the small supplier agrees with the requirement 🎯 IN THIS EPISODE: - ​ Critical vulnerability assessments and mitigations - ​ AI...The NIS2 problem is no longer whether the small supplier agrees with the requirement
🎯 IN THIS EPISODE:

• ​ Critical vulnerability assessments and mitigations
• ​ AI and machine learning security risks
• ​ Incident response and crisis management

📋 KEY TOPICS COVERED:

• ​ NIS2 Compliance
• ​ AI Security

🔑 KEY INSIGHTS:

1. ​ The NIS2 problem is no longer whether the small supplier agrees with the requirement
2. ​ It is whether they can afford to live inside it
3. ​ That is where many industrial programmes are hitting the wall

🔧 TECHNOLOGIES & STANDARDS:CAN Bus • ECU
👥 WHO SHOULD LISTEN:This episode is perfect for CISOs, OT security engineers, infrastructure operators, compliance officers, cybersecurity consultants, and anyone responsible for protecting critical systems.
💡 WHAT YOU WILL LEARN:

• ​ How real attacks unfold in OT/ICS environments
• ​ Practical defense strategies you can implement today
• ​ Compliance considerations (NIS2, IEC 62443, NIST)
• ​ Lessons from recent high-profile incidents

🎧 SUBSCRIBE & CONNECT:Subscribe for weekly deep dives into real cybersecurity incidents affecting OT, ICS, and critical infrastructure. New episodes every week.
💬 ENGAGE WITH US:Have questions or topics you'd like us to cover? Reach out! We love hearing from our community.
#OTSecurity #OperationalTechnology #NIS2 #EUCybersecurity #AISecurity #MachineLearning #IncidentResponse #SOC #CriticalInfrastructure #CIP #CyberSecurity #InfoSec]]>2461falsefullhttps://www.spreaker.com/episode/2026-deep-dive-some-of-the-hardest-ot-risks-in-rail-zero-trust--71547907If you cannot harden the asset, you isolate the risk around it with controls that actually understand the traffic. That means segmentation designed for the signalling cell, tightly brokered remote access, and inspection layers that can parse the protocols the system really uses instead of treating them as opaque packets.
🎯 IN THIS EPISODE:• Zero Trust architecture in OT environments• Railway and transportation cybersecurity• AI and machine learning security risks
📋 KEY TOPICS COVERED:• Zero Trust Architecture• Railway Cybersecurity• AI Security
🔑 KEY INSIGHTS:1. Some of the hardest OT risks in rail stay online for one simple reason2. You are not allowed to touch the box3. An operator knows a signalling component, wayside appliance, or maintenance subsystem needs tighter controls
🔧 TECHNOLOGIES & STANDARDS:CERT • ISO • CAN Bus • ECU
👥 WHO SHOULD LISTEN:This episode is perfect for CISOs, OT security engineers, infrastructure operators, compliance officers, cybersecurity consultants, and anyone responsible for protecting critical systems.
💡 WHAT YOU WILL LEARN:• How real attacks unfold in OT/ICS environments• Practical defense strategies you can implement today• Compliance considerations (NIS2, IEC 62443, NIST)• Lessons from recent high-profile incidents
🎧 SUBSCRIBE & CONNECT:Subscribe for weekly deep dives into real cybersecurity incidents affecting OT, ICS, and critical infrastructure. New episodes every week.
💬 ENGAGE WITH US:Have questions or topics you'd like us to cover? Reach out! We love hearing from our community.
#OTSecurity #OperationalTechnology #RailwaySecurity #TransportSecurity #ZeroTrust #IdentitySecurity #AISecurity #MachineLearning #CriticalInfrastructure #CIP #CyberSecurity #InfoSec]]>a24b3193-cd85-4469-8bbd-bcb15daf032eWed, 22 Apr 2026 07:00:00 +0000Antonio GonzalezSome of the hardest OT risks in rail stay online for one simple reason If you cannot harden the asset, you isolate the risk around it with controls that actually understand the traffic. That means segmentation designed for the signalling cell, tightly...If you cannot harden the asset, you isolate the risk around it with controls that actually understand the traffic. That means segmentation designed for the signalling cell, tightly brokered remote access, and inspection layers that can parse the protocols the system really uses instead of treating them as opaque packets.
🎯 IN THIS EPISODE:• Zero Trust architecture in OT environments• Railway and transportation cybersecurity• AI and machine learning security risks
📋 KEY TOPICS COVERED:• Zero Trust Architecture• Railway Cybersecurity• AI Security
🔑 KEY INSIGHTS:1. Some of the hardest OT risks in rail stay online for one simple reason2. You are not allowed to touch the box3. An operator knows a signalling component, wayside appliance, or maintenance subsystem needs tighter controls
🔧 TECHNOLOGIES & STANDARDS:CERT • ISO • CAN Bus • ECU
👥 WHO SHOULD LISTEN:This episode is perfect for CISOs, OT security engineers, infrastructure operators, compliance officers, cybersecurity consultants, and anyone responsible for protecting critical systems.
💡 WHAT YOU WILL LEARN:• How real attacks unfold in OT/ICS environments• Practical defense strategies you can implement today• Compliance considerations (NIS2, IEC 62443, NIST)• Lessons from recent high-profile incidents
🎧 SUBSCRIBE & CONNECT:Subscribe for weekly deep dives into real cybersecurity incidents affecting OT, ICS, and critical infrastructure. New episodes every week.
💬 ENGAGE WITH US:Have questions or topics you'd like us to cover? Reach out! We love hearing from our community.
#OTSecurity #OperationalTechnology #RailwaySecurity #TransportSecurity #ZeroTrust #IdentitySecurity #AISecurity #MachineLearning #CriticalInfrastructure #CIP #CyberSecurity #InfoSec]]>2132falsefullhttps://www.spreaker.com/episode/2026-deep-dive-a-bad-weld-passes-inspection-ot-security--71485175That is why periodic challenge parts are useful, but not sufficient on their own. They validate model behaviour against physical reality. They do not give you cybersecurity visibility.
🎯 IN THIS EPISODE:• Automotive and connected vehicle security• AI and machine learning security risks
📋 KEY TOPICS COVERED:• Automotive Security• AI Security
🔑 KEY INSIGHTS:1. The PLC accepts the result, the diverter stays idle, and the part moves downstream as if nothing happened2. That is how AI risk usually enters OT3. Not as a dramatic outage, but as a wrong decision repeated at production speed
🔧 TECHNOLOGIES & STANDARDS:ISO • PLC • ECU
👥 WHO SHOULD LISTEN:This episode is perfect for CISOs, OT security engineers, infrastructure operators, compliance officers, cybersecurity consultants, and anyone responsible for protecting critical systems.
💡 WHAT YOU WILL LEARN:• How real attacks unfold in OT/ICS environments• Practical defense strategies you can implement today• Compliance considerations (NIS2, IEC 62443, NIST)• Lessons from recent high-profile incidents
🎧 SUBSCRIBE & CONNECT:Subscribe for weekly deep dives into real cybersecurity incidents affecting OT, ICS, and critical infrastructure. New episodes every week.
💬 ENGAGE WITH US:Have questions or topics you'd like us to cover? Reach out! We love hearing from our community.
#OTSecurity #OperationalTechnology #AutomotiveSecurity #ConnectedCar #AISecurity #MachineLearning #CyberSecurity #InfoSec #CybersecurityUnderPressure]]>8250dbdb-d3df-43d6-8705-296d8836e116Mon, 20 Apr 2026 07:00:00 +0000Antonio GonzalezA bad weld passes inspection That is why periodic challenge parts are useful, but not sufficient on their own. They validate model behaviour against physical reality. They do not give you cybersecurity visibility. 🎯 IN THIS EPISODE:• Automotive and...That is why periodic challenge parts are useful, but not sufficient on their own. They validate model behaviour against physical reality. They do not give you cybersecurity visibility.
🎯 IN THIS EPISODE:• Automotive and connected vehicle security• AI and machine learning security risks
📋 KEY TOPICS COVERED:• Automotive Security• AI Security
🔑 KEY INSIGHTS:1. The PLC accepts the result, the diverter stays idle, and the part moves downstream as if nothing happened2. That is how AI risk usually enters OT3. Not as a dramatic outage, but as a wrong decision repeated at production speed
🔧 TECHNOLOGIES & STANDARDS:ISO • PLC • ECU
👥 WHO SHOULD LISTEN:This episode is perfect for CISOs, OT security engineers, infrastructure operators, compliance officers, cybersecurity consultants, and anyone responsible for protecting critical systems.
💡 WHAT YOU WILL LEARN:• How real attacks unfold in OT/ICS environments• Practical defense strategies you can implement today• Compliance considerations (NIS2, IEC 62443, NIST)• Lessons from recent high-profile incidents
🎧 SUBSCRIBE & CONNECT:Subscribe for weekly deep dives into real cybersecurity incidents affecting OT, ICS, and critical infrastructure. New episodes every week.
💬 ENGAGE WITH US:Have questions or topics you'd like us to cover? Reach out! We love hearing from our community.
#OTSecurity #OperationalTechnology #AutomotiveSecurity #ConnectedCar #AISecurity #MachineLearning #CyberSecurity #InfoSec #CybersecurityUnderPressure]]>2837falsefullhttps://www.spreaker.com/episode/2026-critical-zero-trust-for-brownfield-ot-iec-62443--71400087🎯 IN THIS EPISODE:

• ​Regulatory compliance frameworks (NIS2, IEC 62443)
• ​Zero Trust architecture in OT environments
• ​AI and machine learning security risks
• ​Incident response and crisis management
• ​Supply chain attacks and software security

📋 KEY TOPICS COVERED:

• ​Critical Infrastructure Protection
• ​Zero Trust Architecture
• ​NIS2 Compliance
• ​IEC 62443 Standard
• ​AI Security

🔧 TECHNOLOGIES & STANDARDS:CERT • ISO • IEC • PLC • ECU

👥 WHO SHOULD LISTEN:This episode is perfect for CISOs, OT security engineers, infrastructure operators, compliance officers, cybersecurity consultants, and anyone responsible for protecting critical systems.
💡 WHAT YOU WILL LEARN:

• ​How real attacks unfold in OT/ICS environments
• ​Practical defense strategies you can implement today
• ​Compliance considerations (NIS2, IEC 62443, NIST)
• ​Lessons from recent high-profile incidents

🎧 SUBSCRIBE & CONNECT:Subscribe for weekly deep dives into real cybersecurity incidents affecting OT, ICS, and critical infrastructure. New episodes every week.
💬 ENGAGE WITH US:Have questions or topics you'd like us to cover? Reach out! We love hearing from our community.
#OTSecurity #OperationalTechnology #ICSSecurity #IndustrialControl #ZeroTrust #IdentitySecurity #NIS2 #EUCybersecurity #AISecurity #MachineLearning #IncidentResponse #SOC]]>0c2829fd-140e-4c92-a806-b12a23d5b9e3Fri, 17 Apr 2026 07:00:00 +0000Antonio Gonzalez"Do we have Zero Trust 🎯 IN THIS EPISODE: - ​Regulatory compliance frameworks (NIS2, IEC 62443) - ​Zero Trust architecture in OT environments - ​AI and machine learning security risks - ​Incident response and crisis management - ​Supply chain attacks...🎯 IN THIS EPISODE:

• ​Regulatory compliance frameworks (NIS2, IEC 62443)
• ​Zero Trust architecture in OT environments
• ​AI and machine learning security risks
• ​Incident response and crisis management
• ​Supply chain attacks and software security

📋 KEY TOPICS COVERED:

• ​Critical Infrastructure Protection
• ​Zero Trust Architecture
• ​NIS2 Compliance
• ​IEC 62443 Standard
• ​AI Security

🔧 TECHNOLOGIES & STANDARDS:CERT • ISO • IEC • PLC • ECU

👥 WHO SHOULD LISTEN:This episode is perfect for CISOs, OT security engineers, infrastructure operators, compliance officers, cybersecurity consultants, and anyone responsible for protecting critical systems.
💡 WHAT YOU WILL LEARN:

• ​How real attacks unfold in OT/ICS environments
• ​Practical defense strategies you can implement today
• ​Compliance considerations (NIS2, IEC 62443, NIST)
• ​Lessons from recent high-profile incidents

🎧 SUBSCRIBE & CONNECT:Subscribe for weekly deep dives into real cybersecurity incidents affecting OT, ICS, and critical infrastructure. New episodes every week.
💬 ENGAGE WITH US:Have questions or topics you'd like us to cover? Reach out! We love hearing from our community.
#OTSecurity #OperationalTechnology #ICSSecurity #IndustrialControl #ZeroTrust #IdentitySecurity #NIS2 #EUCybersecurity #AISecurity #MachineLearning #IncidentResponse #SOC]]>2321falsefullhttps://www.spreaker.com/episode/vendor-lock-in-surviving-ransomware-when-you-can-t-switch-suppliers--71338113In this episode of Cybersecurity Under Pressure, we break down the technical details behind this incident and translate them into actionable lessons for security teams, engineers, and business leaders.
SBOMs are incomplete, visibility is partial, and stopping the plant is not an option. Welcome to supply chain security in brownfield OT. This episode moves beyond the "diversify vendors" fantasy to operational reality.
Topics covered: IEC 62443, SCADA, critical infrastructure, ransomware, Supply Chain Ransomware. Subscribe for weekly analysis of real cybersecurity incidents affecting OT, ICS, and critical infrastructure environments.
Keywords: IEC 62443, SCADA, critical infrastructure, ransomware, Supply Chain Ransomware, Vendor Lock-in, SBOM, OT Resilience, Compensating Controls, Out-of-band Monitoring, Degraded Mode Operations, Manufacturing Security]]>9a99530c-b16f-485c-b343-e94f9b105f3cWed, 15 Apr 2026 07:00:00 +0000Antonio GonzalezYour automation vendor just announced a ransomware breach. You cannot switch them—you're locked into a 20-year PLC lifecycle and 18 months of SCADA recertification. In this episode of Cybersecurity Under Pressure, we break down the technical details...In this episode of Cybersecurity Under Pressure, we break down the technical details behind this incident and translate them into actionable lessons for security teams, engineers, and business leaders.
SBOMs are incomplete, visibility is partial, and stopping the plant is not an option. Welcome to supply chain security in brownfield OT. This episode moves beyond the "diversify vendors" fantasy to operational reality.
Topics covered: IEC 62443, SCADA, critical infrastructure, ransomware, Supply Chain Ransomware. Subscribe for weekly analysis of real cybersecurity incidents affecting OT, ICS, and critical infrastructure environments.
Keywords: IEC 62443, SCADA, critical infrastructure, ransomware, Supply Chain Ransomware, Vendor Lock-in, SBOM, OT Resilience, Compensating Controls, Out-of-band Monitoring, Degraded Mode Operations, Manufacturing Security]]>2618falsefullhttps://www.spreaker.com/episode/the-plausibility-gap-when-ai-sensors-report-valid-data-about-invalid-physics--71286466Keywords: Shadow AI, Sensor Validation, Machine Learning OT, Deterministic Control, Plausibility Gateway, AI Safety, Industrial Sensors, Physics Validation, IEC 62443, Railway Safety]]>1f06c80d-155a-4e73-ab5a-c96c56f6134aMon, 13 Apr 2026 07:00:00 +0000Antonio GonzalezMachine learning is now embedded in Level 0 field devices, making autonomous calibration decisions that your deterministic PLC blindly trusts. When these "Shadow AI" sensors drift—through manipulation, environmental degradation, or weak validation...Keywords: Shadow AI, Sensor Validation, Machine Learning OT, Deterministic Control, Plausibility Gateway, AI Safety, Industrial Sensors, Physics Validation, IEC 62443, Railway Safety]]>2375falsefullhttps://www.spreaker.com/episode/the-great-bifurcation-why-average-security-is-disappearing-and-which-side-you-re-on--71228478fed3bc9c-2ccf-4862-8e94-cefb14a4c013Fri, 10 Apr 2026 07:00:00 +0000Antonio GonzalezGlobal breach costs just fell for the first time in five years. So why did US costs hit record highs? The answer reveals a market splitting in two: organizations with disciplined governance that absorb attacks and recover, and those entering a spiral...2221falsefullhttps://www.spreaker.com/episode/the-56-problem-why-attackers-no-longer-need-passwords-ibm-x-force-analysis--711767093def629c-c997-4735-9468-5322bdc0e494Wed, 08 Apr 2026 07:00:00 +0000Antonio GonzalezThe 2026 IBM X-Force Threat Intelligence Index reveals a chilling statistic: more than half of last year’s exploited vulnerabilities required zero authentication to breach. The barrier to entry hasn’t disappeared—it has shifted from sophistication to...2082falsefullhttps://www.spreaker.com/episode/when-your-security-scanner-becomes-the-trojan-horse-the-cert-eu-supply-chain-breach--7112844496e98764-417a-49e3-a3fb-b7e292f13df8Mon, 06 Apr 2026 07:00:00 +0000Antonio GonzalezWhat happens when the tool you download to find vulnerabilities becomes the vulnerability itself? This week we dissect the European Commission breach where attackers exfiltrated 91.7GB of sensitive data through Trivy, a trusted open-source security...2555falsefullhttps://www.spreaker.com/episode/why-evidence-does-not-equal-confidence--71079578ceea826b-6096-49d8-97fe-f8c9dca09d30Fri, 03 Apr 2026 06:05:00 +0000Antonio GonzalezIn this episode of Cybersecurity Under Pressure: Real Attacks, Real Problems, we dive deep into the fascinating and destructive world of real-life cyber threats that have reshaped our global digital landscape. Join us as we explore the infamous...1434falsefullhttps://www.spreaker.com/episode/legacy-rail-assets-do-not-become-secure-by-policy--71038164]]>bec4eef7-4ff1-45ef-be2d-9da8a6a0a2f5Wed, 01 Apr 2026 06:05:00 +0000Antonio GonzalezIn this episode, we dive into the alarming reality of cyber threats in the modern railway sector. We explore major real-world incidents that prove critical infrastructure is a prime target, from a teenager derailing trams in Łódź, Poland using a...]]>1693falsefullhttps://www.spreaker.com/episode/if-the-secure-reflash-takes-longer-the-shortcut-wins--7099005907f070ef-016f-4aec-b203-c63276052217Mon, 30 Mar 2026 06:05:00 +0000Antonio GonzalezIn this episode of "Cybersecurity Under Pressure: Real Attacks, Real Problems", we dive into the messy reality where theoretical cybersecurity collides with operational pressure. What happens when a dealership technician needs to rush a DoIP reflash...1456falsefullhttps://www.spreaker.com/episode/jeep-gateways-and-the-myth-of-clean-isolation--70918063]]>4350abdc-4d8c-4556-ad0e-858248d0997dFri, 27 Mar 2026 07:05:00 +0000Antonio GonzalezIn this episode, we dive into why the infamous Jeep hack is not just nostalgia, but a live architectural problem that the automotive sector still wrestles with today. While connected features demand reach and product teams crave convenience, we...]]>2173falsefullhttps://www.spreaker.com/episode/rail-service-risk-starts-outside-the-sil-boundary--70867209fb4f9707-16f2-4c31-a185-5a01cdca4a52Wed, 25 Mar 2026 07:05:00 +0000Antonio GonzalezIn this episode of Cybersecurity Under Pressure: Real Attacks, Real Problems, we explore the rapidly evolving threat landscape facing modern railway networks. The era of 'security by isolation' is officially over, as digital twins, AI, and...2103falsefullhttps://www.spreaker.com/episode/oldsmar-was-about-standing-trust--7082669345167e71-2443-4633-8fe8-20b8259db97aMon, 23 Mar 2026 08:57:55 +0000Antonio GonzalezIn the realm of Operational Technology (OT), cyberattacks are not just IT problems; they are events with physical consequences, financial disasters, and threats to human safety. In this episode, we dive into how digital transformation and IT/OT...1165falsefullhttps://www.spreaker.com/episode/why-quantum-security-paralyzes-industrial-infrastructure--70775737ce3f502a-44c6-46b1-b03e-83913c54af1dFri, 20 Mar 2026 08:00:00 +0000Antonio GonzalezIn this episode, we dive deep into a critical, long-term threat facing Operational Technology (OT) and railway infrastructure: the "harvest now, decrypt later" strategy. We explore why attackers are actively collecting telemetry histories, failure...1469false115fullhttps://www.spreaker.com/episode/cybersecurity-under-pressure-the-executive-brief--70740263dd4bef00-8d6a-4db7-84e1-55f1161bba80Thu, 19 Mar 2026 08:00:00 +0000Antonio GonzalezShort on time? Join hosts Marcus Webb and Riley Park for a rapid, high-level summary of our deep dive into the escalating threats facing Operational Technology (OT) and enterprise IT. In this brief episode, we distill the most critical takeaways from...509false12bonushttps://www.spreaker.com/episode/how-stolen-credentials-break-industrial-plants--70712986a07da5f6-9555-4b41-8c80-e6b331652bb3Wed, 18 Mar 2026 08:00:00 +0000Antonio GonzalezIn this episode, we dive deep into the escalating threat landscape facing both enterprise IT and Operational Technology (OT) environments. Drawing from the eye-opening 2025 Verizon Data Breach Investigations Report, we unpack why stolen credentials...1571false114fullhttps://www.spreaker.com/episode/cybersecurity-under-pressure-the-executive-brief--70681526c218443a-03c2-46ea-9fc1-0db8404de68bTue, 17 Mar 2026 08:00:00 +0000Antonio GonzalezShort on time? Join hosts Marcus Webb and Riley Park for a fast-paced executive summary of the critical threats facing AI systems today. In this bite-sized episode of "Cybersecurity Under Pressure," Marcus and Riley distill the most important lessons...747falsefullhttps://www.spreaker.com/episode/why-hidden-text-hacks-enterprise-ai--7065574949d7f677-821b-4096-be65-dfbc6e4c68afMon, 16 Mar 2026 08:00:00 +0000Antonio GonzalezIn this episode of "Cybersecurity Under Pressure", we dive deep into the complex and rapidly evolving world of Artificial Intelligence cybersecurity. As Large Language Models (LLMs) evolve into autonomous "Agentic AI" capable of interacting with...2175false113fullhttps://www.spreaker.com/episode/ddos-and-hacktivism-when-disruption-becomes-a-board-level-threat--70619906A slow customer portal. Unstable supplier access. Degraded telemetry. In highly automated environments, these aren't just IT headaches—they're strategic pressure points that simultaneously hit operations, communications, and the C-suite. The real danger isn't downtime; it's the loss of visibility when leadership needs it most to make critical decisions.
This episode examines why DDoS and hacktivism have returned to the boardroom agenda, how technically simple attacks create disproportionate strategic damage, and why operational resilience now matters as much as classic perimeter defense.
Inside this episode:• The "economics of pressure": Why disruption beats destruction for modern attackers• Operational continuity vs. uptime: Protecting visibility, not just availability • Fallback modes and degraded operations: Planning for when systems slow, not just when they break• Why automated sectors (rail, automotive, logistics) face unique DDoS visibility risks• Board-level metrics: How to communicate operational resilience to executives and boards
Essential for: CISOs, infrastructure leads, business continuity planners, and security teams defending revenue-critical operations.
Follow the show for weekly analysis on modern attack economics and operational resilience strategies.
]]>e1c97b38-c8a7-44b4-b2f6-c61f2c7d3f0aFri, 13 Mar 2026 08:00:00 +0000Antonio GonzalezNot every damaging cyberattack needs sophistication. Sometimes, sustained disruption is enough. A slow customer portal. Unstable supplier access. Degraded telemetry. In highly automated environments, these aren't just IT headaches—they're strategic...A slow customer portal. Unstable supplier access. Degraded telemetry. In highly automated environments, these aren't just IT headaches—they're strategic pressure points that simultaneously hit operations, communications, and the C-suite. The real danger isn't downtime; it's the loss of visibility when leadership needs it most to make critical decisions.
This episode examines why DDoS and hacktivism have returned to the boardroom agenda, how technically simple attacks create disproportionate strategic damage, and why operational resilience now matters as much as classic perimeter defense.
Inside this episode:• The "economics of pressure": Why disruption beats destruction for modern attackers• Operational continuity vs. uptime: Protecting visibility, not just availability • Fallback modes and degraded operations: Planning for when systems slow, not just when they break• Why automated sectors (rail, automotive, logistics) face unique DDoS visibility risks• Board-level metrics: How to communicate operational resilience to executives and boards
Essential for: CISOs, infrastructure leads, business continuity planners, and security teams defending revenue-critical operations.
Follow the show for weekly analysis on modern attack economics and operational resilience strategies.
]]>2503falsefullhttps://www.spreaker.com/episode/when-ai-agents-become-the-new-insider-threat-why-zero-trust-is-no-longer-enough--70588328In this episode, we break down why "least privilege" collapses when AI makes real-time decisions in physical environments like rail systems, automotive factories, and critical infrastructure.
What you'll learn:• The shift from AI-as-tool to AI-as-operator (and why your firewall won't help)• Why workload identity and runtime authorization are replacing static permissions • Real-world risks: When a valid API call becomes an unsafe physical action• Practical frameworks for safety-aware control in autonomous systems
Perfect for: Security architects, CISOs, DevOps teams, and AI implementers building operational technology (OT) that won't fail dangerously.
Follow the show for weekly insights on AI security and the future of zero trust architecture.]]>35191cb3-114c-4391-8021-8731c9acd72cWed, 11 Mar 2026 08:00:00 +0000Antonio GonzalezAI agents are no longer just assistants—they're autonomous operators with system access. This creates a new breed of insider threat that traditional security models can't detect or contain. In this episode, we break down why "least privilege"...In this episode, we break down why "least privilege" collapses when AI makes real-time decisions in physical environments like rail systems, automotive factories, and critical infrastructure.
What you'll learn:• The shift from AI-as-tool to AI-as-operator (and why your firewall won't help)• Why workload identity and runtime authorization are replacing static permissions • Real-world risks: When a valid API call becomes an unsafe physical action• Practical frameworks for safety-aware control in autonomous systems
Perfect for: Security architects, CISOs, DevOps teams, and AI implementers building operational technology (OT) that won't fail dangerously.
Follow the show for weekly insights on AI security and the future of zero trust architecture.]]>2415false111fullhttps://www.spreaker.com/episode/logged-in-not-hacked-when-identity-and-edge-become-the-attack-vector--70545583When compromised accounts meet exposed gateways, attackers gain trusted paths deep into critical environments—no alarms triggered, no malware needed. The reality is that identity abuse and edge exploitation are no longer separate threats; attackers chain them into a unified intrusion model.
In this episode, we dissect exactly how that kill chain works, why it specifically endangers operational sectors like rail and automotive, and why defending identity and perimeter in separate silos creates dangerous blind spots.
Inside this episode:• Why valid credentials are now the ultimate stealth weapon• How attackers bridge identity compromise with edge exploitation • Real-world risks for OT environments where digital actions impact physical safety• Why traditional "trust but verify" models fail against chained attacks• Integrated defense strategies for converged IT/OT security
Essential for: CISOs, security architects, SOC analysts, and OT security teams defending critical infrastructure.
Follow the show for weekly deep dives on zero trust, identity security, and modern intrusion detection.]]>b78f8a6f-bf33-4206-be99-04b6791eb169Mon, 09 Mar 2026 08:00:00 +0000Antonio GonzalezModern intrusions don't start with cinematic malware. They start with a login. When compromised accounts meet exposed gateways, attackers gain trusted paths deep into critical environments—no alarms triggered, no malware needed. The reality is that...When compromised accounts meet exposed gateways, attackers gain trusted paths deep into critical environments—no alarms triggered, no malware needed. The reality is that identity abuse and edge exploitation are no longer separate threats; attackers chain them into a unified intrusion model.
In this episode, we dissect exactly how that kill chain works, why it specifically endangers operational sectors like rail and automotive, and why defending identity and perimeter in separate silos creates dangerous blind spots.
Inside this episode:• Why valid credentials are now the ultimate stealth weapon• How attackers bridge identity compromise with edge exploitation • Real-world risks for OT environments where digital actions impact physical safety• Why traditional "trust but verify" models fail against chained attacks• Integrated defense strategies for converged IT/OT security
Essential for: CISOs, security architects, SOC analysts, and OT security teams defending critical infrastructure.
Follow the show for weekly deep dives on zero trust, identity security, and modern intrusion detection.]]>1406falsefullhttps://www.spreaker.com/episode/kev-first-patch-ops-defending-the-exposed-control-plane--70503333a3dcb41c-337f-4c85-ae36-16717724ebb7Fri, 06 Mar 2026 08:00:00 +0000Antonio GonzalezIn this brand new episode of Cybersecurity Under Pressure: Real Attacks, Real Lessons, Alex and Sarah tackle why traditional monthly patching cycles are failing modern enterprises. Prompted by actively exploited edge vulnerabilities, they argue for a...2292false110fullhttps://www.spreaker.com/episode/the-illusion-of-mfa-aitm-phishing-and-session-token-theft--70437786192bc622-3080-4051-89e6-31ddf708d1f1Wed, 04 Mar 2026 08:00:00 +0000Antonio GonzalezWelcome to a new episode of Cybersecurity Under Pressure: Real Attacks, Real Lessons. If your security dashboard shows complete MFA adoption, you might still be compromised. Sarah and Alex break down the mechanics of Adversary-in-the-Middle (AiTM)...1960false19fullhttps://www.spreaker.com/episode/automotive-extortion-goes-upstream-protecting-the-new-vehicle-perimeter--7038485767bd81ce-cae6-42c1-89fa-a45a03f3eb83Mon, 02 Mar 2026 08:00:00 +0000Antonio GonzalezIn this new episode of Cybersecurity Under Pressure: Real Attacks, Real Lessons, hosts Sarah and Alex dissect the structural shift in automotive cyber threats. Moving past the outdated CAN bus hacking narrative, they explore how extortion crews are...2411false18fullhttps://www.spreaker.com/episode/invisible-conduits-the-control-plane-siege--70358703e84a70d3-8cde-4889-846e-8c1e5741b75bSat, 28 Feb 2026 08:30:36 +0000Antonio GonzalezThis episode dissects the strategic shift toward control plane exploitation, using the recent Cisco SD-WAN bypass (CVE-2026-20127) to illustrate how attackers are rewriting network segmentation in real-time. We analyze the fallout of the Odido leak...2013false111fullhttps://www.spreaker.com/episode/hostile-time-when-the-clock-lies-in-critical-ot--703260084b9b2e0e-f706-4d16-aa00-13d59cf83672Fri, 27 Feb 2026 08:00:00 +0000Antonio GonzalezWe are back with another episode of Cybersecurity Under Pressure. Real Attacks, Real Lessons, diving into one of the most insidious vectors in operational technology: hostile time. At 06:05, a rail control room gets a burst of alarms, but the...2771false17fullhttps://www.spreaker.com/episode/the-18-45-reflash-when-usability-friction-becomes-a-threat--70263446429cebfb-36ee-48bd-9e51-7fbfa3b10fb7Wed, 25 Feb 2026 08:00:00 +0000Antonio GonzalezIn this new chapter of Cybersecurity Under Pressure. Real Attacks, Real Lessons, we tackle the dangerous intersection of operational friction and systems engineering. A dealership laptop starts a DoIP reflash at 18:45. The authentication portal lags,...1404false16fullhttps://www.spreaker.com/episode/the-friday-night-patch-the-illusion-of-segmentation--70249225b784c066-ace1-4964-8f8e-0cf6e3aaff08Mon, 23 Feb 2026 08:00:00 +0000Antonio GonzalezWelcome to a new episode of Cybersecurity Under Pressure. Real Attacks, Real Lessons. It is Friday at 22:30, and a rail depot applies a minor network change to fix a flaky engineering link. By Monday morning, everything looks functional, but the...1745false15fullhttps://www.spreaker.com/episode/weekly-roundup-state-machine-breakdown-engineering-the-degraded-mode--70249229114411d2-fcf3-4688-a1c6-057bf5ea9fe0Sat, 21 Feb 2026 10:08:50 +0000Antonio GonzalezWelcome to a new weekly roundup episode of Cybersecurity Under Pressure. Real Attacks, Real Lessons. This week, we examine a cascade of high-impact events across multiple critical sectors: a massive DDoS wave knocking Deutsche Bahn’s passenger systems...2435falsefullhttps://www.spreaker.com/episode/engineer-the-path-not-just-the-perimeter--70249226How does your network know the difference? Spoiler: It doesn't.
This is the synthesis. We connect the dots from the previous episodes, the Oldsmar attack and the break-glass dilemma, to deliver a final verdict: You cannot patch your way to safety. You have to design it. We explore how to move from abstract frameworks like IEC 62443 to a concrete "abuse-resistant" architecture.
Tune in to learn why the most critical firewall in your plant isn't a device, it’s a design philosophy.]]>88b6cbad-73a3-4fd5-8638-3fe629c99467Fri, 20 Feb 2026 08:00:00 +0000Antonio GonzalezA vendor fixes an alarm at 4 PM. At midnight, that same remote tunnel is used to push an unsafe setpoint. Different intent, identical path. How does your network know the difference? Spoiler: It doesn't. This is the synthesis. We connect the dots from...How does your network know the difference? Spoiler: It doesn't.
This is the synthesis. We connect the dots from the previous episodes, the Oldsmar attack and the break-glass dilemma, to deliver a final verdict: You cannot patch your way to safety. You have to design it. We explore how to move from abstract frameworks like IEC 62443 to a concrete "abuse-resistant" architecture.
Tune in to learn why the most critical firewall in your plant isn't a device, it’s a design philosophy.]]>1964false14fullhttps://www.spreaker.com/episode/02-00-am-panic-does-break-glass-mean-break-security--70249227Do you wait for IT to wake up, or do you reach for the "emergency" admin password kept in a drawer?
That split-second decision is where security dies.In this episode, we tackle the uncomfortable friction between production pressure and cybersecurity. We explain why "temporary" bypasses often become permanent backdoors and how to engineer a "Break-Glass" protocol that saves the plant without handing the keys to an attacker.
The question is: Do your emergency paths reduce risk, or quietly store it?]]>0322e3f1-13c7-4a67-bf14-03e18145e399Wed, 18 Feb 2026 08:00:00 +0000Antonio GonzalezThe packaging line stalls at 01:40 AM. Scrap is rising. The IAM server is down. Do you wait for IT to wake up, or do you reach for the "emergency" admin password kept in a drawer? That split-second decision is where security dies.In this episode, we...Do you wait for IT to wake up, or do you reach for the "emergency" admin password kept in a drawer?
That split-second decision is where security dies.In this episode, we tackle the uncomfortable friction between production pressure and cybersecurity. We explain why "temporary" bypasses often become permanent backdoors and how to engineer a "Break-Glass" protocol that saves the plant without handing the keys to an attacker.
The question is: Do your emergency paths reduce risk, or quietly store it?]]>1674false13fullhttps://www.spreaker.com/episode/when-maintenance-becomes-the-weapon-the-oldsmar-incident--70249228February 2021. An operator in Florida watches his cursor move across the screen on its own. It wasn’t a glitch; it was an active attempt to poison the water supply by changing sodium hydroxide levels.But here is the terrifying part: The attackers didn’t use a zero-day exploit. They used the plant’s own maintenance tools.In this episode, we dissect the Oldsmar incident to uncover a harsh reality: in OT, your "authorized" engineering path is often the attacker’s favorite backdoor. We break down how legitimate tools—like TeamViewer and shared credentials—get weaponized, and how to stop hoping for the best by designing for abuse using IEC 62443.Listen to find out: Could you prove who changed a setpoint within one hour?]]>d942fd23-ac0f-426b-9dcb-e5f7abdbf165Mon, 16 Feb 2026 08:00:00 +0000Antonio Gonzalez February 2021. An operator in Florida watches his cursor move across the screen on its own. It wasn’t a glitch; it was an active attempt to poison the water supply by changing sodium hydroxide levels.But here is the terrifying part: The attackers...February 2021. An operator in Florida watches his cursor move across the screen on its own. It wasn’t a glitch; it was an active attempt to poison the water supply by changing sodium hydroxide levels.But here is the terrifying part: The attackers didn’t use a zero-day exploit. They used the plant’s own maintenance tools.In this episode, we dissect the Oldsmar incident to uncover a harsh reality: in OT, your "authorized" engineering path is often the attacker’s favorite backdoor. We break down how legitimate tools—like TeamViewer and shared credentials—get weaponized, and how to stop hoping for the best by designing for abuse using IEC 62443.Listen to find out: Could you prove who changed a setpoint within one hour?]]>1740false12fullhttps://www.spreaker.com/episode/when-the-hypervisor-becomes-the-attack-surface-the-ot-signal-behind-cve-2025-22225--70249232Picture a control room where HMIs work, but historians freeze and jump servers vanish. Nothing “OT” was hacked, but the digital floor beneath them just crumbled. This article analyzes why CVE-2025-22225 in VMware ESXi is not just another IT vulnerability, but a systemic risk to industrial safety. We explore the mechanics of the “Guest-to-Host” escape, why the hypervisor must now be treated with the same rigor as a PLC, and the recoverability engineering actions—beyond patching—you need to take in the next 72 hours to secure your operational substrate.]]>0d92bf94-9b50-40ce-8221-30bb0374f0ccSat, 07 Feb 2026 16:23:50 +0000Antonio Gonzalez Picture a control room where HMIs work, but historians freeze and jump servers vanish. Nothing “OT” was hacked, but the digital floor beneath them just crumbled. This article analyzes why CVE-2025-22225 in VMware ESXi is not just another IT...Picture a control room where HMIs work, but historians freeze and jump servers vanish. Nothing “OT” was hacked, but the digital floor beneath them just crumbled. This article analyzes why CVE-2025-22225 in VMware ESXi is not just another IT vulnerability, but a systemic risk to industrial safety. We explore the mechanics of the “Guest-to-Host” escape, why the hypervisor must now be treated with the same rigor as a PLC, and the recoverability engineering actions—beyond patching—you need to take in the next 72 hours to secure your operational substrate.]]>1902false11full