The safety alarm went silent. Your control plan didn't notice.

The first thing you learn running a line is what silence sounds like. A stamping press that breaks rhythm, a conveyor that drops its hum, a safety curtain LED that goes dark — silence on a shop floor is never good news. But there is one kind of silence you have never been trained to hear: a safety alarm killed remotely while the HMI tells the operator everything is green. That is what state-linked hackers recently demonstrated they could do to industrial control systems. Operators ran their lines for hours. Nobody knew.

Would your quality system have caught it?

Your PFMEA treats safety devices as physics, not networked software

I sit in a strange chair. As Head of Manufacturing Engineering Technical Authority for Airbus in North America, I sign off on control plans and process validations that protect some of the most scrutinised production lines in aerospace. As a Certified Ethical Hacker with thirty-plus security certifications, I also know exactly how thin the air is between an OT network and someone who wants to bend it.

Here is the gap. When a PFMEA team assesses a process risk — a light curtain on a press, a torque monitoring system on a fastening cell — the safety device goes into the current controls column. It reduces the RPN. The device functions as designed because it is hardware obeying physical laws. Everyone nods and moves on.

Except that light curtain talks to a PLC. That PLC talks to an HMI. That HMI talks to a network switch that may share a segment with the corporate intranet, an engineering VPN, or a vendor's remote maintenance tunnel. The torque monitoring system logs to a database a maintenance technician reaches from a laptop he also uses to read email. Each junction is an attack surface. The PFMEA captures none of them, because the methodology assumes controls are deterministic hardware — not software running on networked infrastructure that can be modified at runtime by someone who is not on your team.

I have run this exercise with quality engineers. I ask: what is the failure mode if someone changes the alarm threshold on the torque monitor from 8 Nm to 80 Nm inside the PLC logic? The answer is usually a long pause. They have not considered it because the control plan was built on the assumption that the threshold stays where PFMEA validation left it. That assumption holds whether you are running automotive stamping with 900 employees or flight-critical aerospace subassemblies.

Alarm silence is indistinguishable from normal operation — that is the design flaw

The attack worked because it exploited a foundational assumption baked into every safety system I have ever audited: absence of alarm equals absence of danger.

This is a design philosophy problem, not a cybersecurity problem. When I test OT systems, the first thing I look for is not how to trigger an alarm. I look for how to suppress one. In most architectures, it is trivially easy. Modify a register. Change a timer value. Set an alarm tag to "acknowledged" in a perpetual loop. The PLC keeps executing. The line keeps producing. The operator sees green.

Your quality system then records a batch of parts as in-spec because the monitoring system that would have flagged deviation reported none. There was no deviation — because the system that detects it was told not to. The electronic device history record is clean. The traceability is perfect. The parts are wrong.

Recent CISA advisories on OT security and the steady drumbeat of infrastructure attack disclosures point at the same reality surfacing across bottling lines, turbine casting operations, and everything between: OT systems are contested ground. The gap between what operators see on an HMI and what is actually happening inside the PLC is the new hidden factory — except this one produces defective parts with an immaculate paper trail.

Alarms do not protect you from what they cannot see. And they cannot see themselves.

Quality directors don't own the OT security budget, but they own the escape

I have been the senior director of quality in plants where I did not own the IT budget, did not control network architecture, and could not tell you what firmware version ran on the PLCs my inspection systems depended on. That is normal. That is also the problem.

When I drove a 50% reduction in EASA audit findings in one cycle at Airbus, or achieved zero critical customer escalations within a quarter, it was because the quality systems were robust against the threats they were designed to see. Compromised safety inputs are not in that catalogue. IATF 16949 does not ask about them. AS9100 does not ask about them. VDA 6.3 treats equipment as a given, not as a contested surface. The standards assume the integrity of the tools — and when that assumption breaks, every certificate you issued on that line breaks with it.

But when a defective part escapes because a monitoring system was tampered with, who gets the call at two in the morning? Not the IT director. The quality director. The escape happened on your watch, through a path your control plan certified as controlled.

Most quality leaders do not know this gap between OT security and quality management even exists. They are busy building better fishbones while someone quietly rewrites the alarm logic underneath them.

Here is the test I want every quality director to run before their next audit. Walk to your engineering team and ask: if someone modified the alarm threshold on a critical safety device inside our PLC, would our quality system detect it? Not the security system. Not the firewall logs. The quality system — the one that signs parts off as conforming and ships them to a customer who will not forgive the escape. If the answer is no, and for most of you reading this it will be, then you have a control plan that trusts silence. And silence, whether on a press line at midnight or inside a network register nobody monitors, is the most expensive sound in manufacturing.