I have stood in front of a PFMEA worksheet with fifteen engineers and watched cyber-tampering get scored as occurrence 1, severity 9, detection 2. The reasoning was simple and wrong: it hasn't happened here, and our PLCs are on a separate network. Every time I hear that second clause I ask to see the architecture diagram. Nine times out of ten there is a jump host, a shared engineering workstation, or a vendor VPN that makes the separation fictional. The team revises the score. Nobody thanks me.

This week CISA and the FBI published a joint advisory on Iranian state-sponsored actors expanding their targeting of Siemens, Schneider Electric, and Rockwell Automation ICS devices in US critical infrastructure. These are the S7-1500s, the CompactLogix controllers, the Modicon PLCs that run stamping presses, body-in-white weld cells, and CNC machining centres across automotive Tier 1s and aerospace suppliers. The advisory frames the threat as service disruption and data compromise. That framing is dangerously incomplete.

The attack that produces parts, not headlines

When security teams talk about ICS compromise they imagine ransomware locking up HMIs, production grinding to a halt, a press release within forty-eight hours. That is the loud scenario. The quiet one is worse.

An adversary with sustained access to a Siemens S7 or Rockwell ControlLogix does not need to stop your line. They need to change one register. Torque target value. Spindle speed. Feed rate. Clamping force. Weld current for twelve milliseconds out of an eight-second cycle. The line keeps running. The andon stays green. The parts look identical. Your inline gauging measures dimensions that conform. Your SPC charts show a process in control — because the process is in control of a different parameter than the one you approved.

I hold a CEH certification and spent enough time in offensive security to know how access escalation works on these controllers. I also spent twenty years in quality leadership running plants that depend on them. Those two perspectives collapse into one observation: cybersecurity is obsessed with confidentiality and availability; quality assumes integrity is a given. The gap between those two assumptions is where the next catastrophic defect lives.

Why your control plan is blind to this

Your control plan is built on trust. It trusts that the parameter set loaded into the PLC this morning is the parameter your engineering team released through PPAP. It trusts that the torque value the controller reports to your traceability system is the torque the spindle actually applied. It trusts that nobody touched register 0x42 between the last audit and now.

Here is what I have actually found in plants:

  • Engineering workstations with domain admin rights directly addressing PLCs. One compromised Active Directory account and you have write access to every controller on the floor. I have seen this in plants certified to IATF 16949 and AS9100 without a finding.
  • No change-management on PLC logic. Mechanical revisions go through a documented ECR process with cross-functional approval. Logic changes happen through a TIA Portal session at 2 AM with no quality notification.
  • Vendor VPNs with persistent access. The system integrator who commissioned the line three years ago still has credentials. Never rotated. The integrator's own network was never assessed.

During AS9100 and IATF 16949 audits I have watched IT-OT security get bundled into the IT clause review like it is a firewall configuration question. It is a process-integrity question. The auditor checks whether the antivirus is current. Nobody asks whether the PFMEA includes adversarial parameter modification as a failure mode. Nobody asks whether the control plan verifies parameter integrity at a frequency commensurate with risk. The standard does not explicitly require it, so it does not happen.

A parameter you cannot verify is an assumption you are shipping to your customer.

What quality-driven OT defence looks like

The defence is not purely a network segmentation exercise. Necessary, but insufficient. A properly segmented PLC with no parameter verification is a well-locked room with nobody checking what comes off the machine. It has to be layered with quality system controls, and it has to be owned jointly by manufacturing engineering and quality — not parked with IT security.

Cryptographic parameter verification between the released program and the running controller, checked on a defined interval and at every changeover. Hardware-level feedback loops that compare commanded values to measured values on the process side — not the controller side — and flag divergence as a quality nonconformance, not a cybersecurity alert. Independent read-only parameter logging on a separate network segment that quality can review without depending on the controller's own self-reporting. PFMEA revisions that score cyber-tampering at the occurrence it actually deserves given your architecture, not the one your team finds emotionally convenient.

I reduced EASA audit findings by half in one cycle by applying the same logic to documentation integrity. The principle scales. If your quality system cannot independently verify that the process ran to specification, you do not have a controlled process. You have a process that reports it ran to specification. Those are different things, and the difference matters more now than it did five years ago.

The recall nobody is modelling

Every automotive recall risk model I have reviewed weights design defects, supplier defects, manufacturing process drift, logistics damage. None include adversarial parameter modification. The insurance industry has no actuarial table for it. IATF 16949 does not explicitly require it. Yet CISA is telling us, explicitly and repeatedly, that state-sponsored actors are inside critical infrastructure control systems right now.

Key takeaways

  • Revise your PFMEA to score adversarial parameter modification based on actual network architecture, not historical absence — if a compromised AD account can write to your PLCs, occurrence is not 1.
  • Implement cryptographic or checksum-based parameter verification between released programs and running controllers, checked at every changeover and on a defined interval.
  • Separate process-side feedback from controller self-reporting — your traceability system should read from sensors and encoders, not from the register the controller populates.
  • Move IT-OT security out of the IT audit checklist and into process-integrity reviews where quality and manufacturing engineering own the risk assessment jointly.

The Foxconn ransomware attack, the CISA advisory on Iranian actors in ICS environments, the steady drumbeat of OT compromise reports — these are not information security stories. They are quality stories told in the wrong magazine. The next major automotive or aerospace recall may not begin with a design flaw discovered in field returns. It may begin with a register value nobody verified, on a controller nobody monitored, producing parts that passed every inspection because the inspection trusted the same compromised signal path. Your quality system is only as strong as the integrity of the parameters it never independently checks.