A PLC in your plant gets compromised on a Tuesday afternoon. Security identifies the intrusion, isolates the subnet, contains it in four hours. Good number. They are proud of it, and they should be – four hours is a strong response time. Nobody told quality. The parts produced during the compromise window are already on a truck to a Tier 1 integrator, and your control plan logged every one of them as conforming.
This scenario keeps me awake for two reasons. I am accountable for manufacturing engineering technical authority in an aerospace environment. I sign off on process integrity frameworks that feed directly into AS9100 traceability. I am also a Certified Ethical Hacker who has spent years probing exactly these systems from the outside. I know how trivially an exposed PLC can be talked into reporting normal while running altered parameters. The gap between what the SOC sees and what the quality system captures is not a technical nuisance. In aerospace it is a flight-safety event dressed up as a successful incident response.
The failure mode nobody wrote down
Your PFMEA does not list "adversary" as a failure mode. I have written and reviewed dozens of them across automotive and aerospace, and they share the same assumption space. Process FMEAs are built around drift – tooling wear, operator error, supplier variation, environmental factors. They assume the process changes unintentionally, slowly, within bounds that SPC can catch.
When someone deliberately alters torque, temperature, or pressure on a PLC, everything in your monitoring stack reports nominal. This is what quality leaders who do not understand offensive security miss. The attacker does not just change the process parameter. They change the reporting layer that feeds your control plan. Your HMI shows green. Your SPC chart looks beautiful. The data historian records values within specification. The parts are wrong, and every mechanism you built to catch wrongness is confirming correctness.
I have seen this from the offensive side. A PLC with an exposed management interface – and there are more of those on factory floors than any CISO wants to admit – can be instructed to maintain one set of operating parameters while reporting a second, sanitised set upstream. Minutes, not hours. The skill required is not nation-state tier. The access is often already there, sitting on a flat network segment where IT and OT were never properly segmented because someone needed remote support access in 2019 and it was never revoked.
The ticket that closes on one side and never opens on the other
OT incident response is built around three objectives: contain the threat, recover the network, restore operations. There is no fourth objective that says "freeze production, quarantine everything made during the compromise window, and hand the serial number range to quality." I have reviewed incident response runbooks from major manufacturers. The word "quality" appears in zero of them.
This is where the work I led at Airbus on routing verification KPIs becomes relevant. We achieved a 97% reduction in internal lead time by building real-time process integrity validation – not after-the-fact audit, but live confirmation that the process is actually executing what it was authorised to execute. The principle scales directly. If you can verify a routing in real time, you can verify a PLC parameter has not drifted from its authorised configuration. You are asking the system to prove what it did, not what it says it did.
But right now, when the SOC closes the ticket, that is the end of the event. In an AS9100 environment, flight hardware was built under altered conditions with no traceability flag. When the regulator asks which serial numbers were affected – and they will – you will not have an answer. You will not even have a bounded range. You will have a four-hour SOC report and nothing to hand the auditor.
The SOC tells you when they closed the door. The quality system is supposed to tell you what walked out while it was open.
What a quality-aware OT response actually looks like
This is not a cybersecurity initiative. Every time I raise this in cross-functional meetings, someone from IT security nods and says "great, we'll add it to our roadmap." No. This is a PFMEA update. It belongs to quality.
- PLC parameter integrity checks in the control plan. Not a cyber add-on. A first-class control characteristic, verified in real time, with the same escalation path you would use for any critical-to-quality parameter.
- Automated production freeze on unauthorised parameter deviation. If a PLC reports a parameter that does not match its authorised golden configuration, production stops. Not logs. Not alerts. Stops.
- Cross-functional incident response with a quality trigger. SOC detection of an OT intrusion must automatically trigger quality containment – serial number range identification, physical quarantine, and an 8D investigation. The SOC does not close the ticket until quality signs off.
- Quarantine windows tied to the intrusion timeline, not the detection timeline. The four hours your SOC took to respond is not the window. The window starts when the attacker first touched the PLC, which may be weeks earlier. Your forensic timeline defines the quarantine scope.
I applied this dual-system thinking to work that produced a 50% decrease in EASA audit findings in one cycle. The blind spots were never in one system. They lived in the seam between IT security and quality management, where each assumed the other was covering the risk. Neither was. The adversary lives in that seam.
Key takeaways
- A successful SOC response does not mean parts are safe. It means you have no excuse for not asking which serial numbers were produced during the compromise window.
- Adversarial PLC modification defeats SPC and control plans by design – the attacker alters the reporting layer, not just the process layer.
- PLC parameter integrity belongs in the control plan as a critical-to-quality characteristic, not in a cybersecurity framework that nobody on the shop floor reads.
- In AS9100 environments, a compromised PLC is not a data breach. It is undocumented flight-critical hardware with no integrity evidence. The regulator will not accept a SOC report as a substitute for traceability.
The question was never whether security can detect the breach. It is whether your quality system can trace every part produced while the building was open. In aerospace, a compromised PLC does not exfiltrate data. It ships flight-critical hardware with no verifiable integrity – and your control plan, your SPC charts, and your signed-off first-article inspection all confirm the parts were fine, because the system that told you so was lying.