The CRA regulates your product's security. That's a quality system, not a firewall.

Here is an uncomfortable observation. I have stood in plants where the IT team could tell me the exact firmware version on every server in the rack room but could not tell me which SCADA tag feeds the torque value printed on the certificate of conformance. That is not a minor organisational gap. Under the EU's Cyber Resilience Act, it is the gap where your next audit failure lives — and possibly your next field failure.

The CRA implementation guidance has landed. Most manufacturers have already mishandled the triage. They sent it to IT because the word "cyber" appeared in the document. That is roughly the analytical depth most organisations brought to the question.

The CRA doesn't regulate your firewall

The CRA regulates the cybersecurity of your product across its lifecycle — design, production, deployment, maintenance, decommissioning. If you manufacture anything with embedded firmware, programmable logic controllers, or networked sensors — and in aerospace and automotive that is everything now — the CRA says you are responsible. For vulnerabilities in that product. For reporting incidents within strict timelines. For security by design throughout development.

Those are lifecycle obligations. They land on the manufacturing quality system because that is the system designed to own lifecycle discipline — incoming inspection, process control, traceability, corrective action, change management. The CRA did not invent a new discipline. It imposed an existing one on a domain that has been pretending it was exempt.

What the CRA demands is what quality already does

Vulnerability management is nonconformance management. A CVE in your embedded controller is a defect with a database entry instead of a reject tag — same containment logic, same impact assessment, same traceability downstream. Incident reporting under the CRA maps to 8D corrective action with a regulatory clock bolted to it. Security by design is APQP for embedded systems: threat modelling at the design phase, risk assessment before release, validation testing before you ship.

The mapping is straightforward once you stop seeing cybersecurity as a network discipline. It remains invisible in most plants because of a structural blind spot. IT owns "cybersecurity" on the org chart. IT thinks in perimeter defence, endpoint protection, patch cadence on enterprise systems. All necessary. None of them touch the question of whether the PLC setting your clamp force on a wing assembly has a known vulnerability that makes every torque value produced since that firmware version suspect.

Recent events made the stakes concrete. Coordinated attacks hit over thirty water systems in Minnesota, forcing one plant offline. Nation-state actors exploited a zero-click mail server flaw to reach Western critical infrastructure. OT security talent is retiring faster than organisations can replace it. These are not IT stories dressed up in manufacturing clothing. They are continuity failures with regulatory consequences — and the CRA is the enforcement mechanism that will make them costly in a language the boardroom understands.

Why IT ownership fails at the shop-floor boundary

IT protects servers. They understand segmentation, access control, patch scheduling. What they do not understand — and cannot reasonably be expected to — is which OT parameters carry quality-critical data. Which controller sets the torque. Which HMI feeds the traceability database. Which sensor calibration drifts into a safety margin over a production run. That knowledge lives in process engineering and quality.

I hold a CEH certification alongside my AS9100 and IATF 16949 work. I have operated on both sides of the cyber-physical boundary — ethical hacking work on one side, greenfield QA departments for 900-plus employee plants on the other. My observation from that position is uncomplicated. A compromised PLC is a nonconforming process input. If someone tampers with the clamp force parameter on your assembly station, every product produced since that change is suspect material. QRQC applies. You quarantine. You investigate. You trace the impact radius. You contain. The discipline is identical to what you would run for a suspect material batch from a supplier — because functionally, it is the same problem.

IT will not make that connection because they do not think in process capability and certificate of conformance. Quality will not make that connection because they do not think in attack surfaces and firmware vulnerabilities. The space between those two frameworks is where the next field failure lives, and it is widening.

If your cybersecurity response cannot survive a walk to the shop floor, it is not a response. It is a compliance document waiting to fail.

What a quality-owned CRA response looks like

The plants that pass the first CRA audit cycle will be the ones where quality built the framework. The shape is concrete.

• Cybersecurity PFMEA for OT-integrated processes. Every networked controller, sensor, and HMI gets a failure mode line item. The failure mode is unauthorised access or parameter manipulation. The effect is nonconforming product. The severity score reflects product impact, not server uptime.
• PPAP for supplier-embedded software. If your supplier ships a subsystem with firmware, you need software bills of materials, vulnerability disclosure commitments, and documented update pathways. Treat it like any other supplier PPAP submission — because under the CRA, it is one.
• Firmware updates through engineering change control. No production firmware change without an ECR, impact assessment, and validation cycle. This is not IT patching a server overnight. It is a process change that affects product conformity, and it routes through the same gate as any tooling modification.
• Cyber-risk assessed at incoming inspection. Networked components arrive with software. That software has a version, a known vulnerability list, and a supply chain of its own. Incoming inspection under the CRA includes verifying that the software state matches what was qualified — not just that the hardware dimensions are in tolerance.

I reduced EASA audit findings by 50% in one cycle. Not through thicker documentation. Through treating compliance as process discipline — making the standard visible in daily operations rather than a binder that gets opened when an auditor walks through the gate. The CRA will be satisfied by plants where cybersecurity controls live in the PFMEA, the control plan, and the reaction matrix — not by plants that maintain an excellent firewall policy and have no idea what firmware is running on their production controllers.

Quality leaders who cannot see the cyber-physical intersection will audit straight past the next failure. The plants that survive the first CRA cycle will be the ones where cybersecurity PFMEA, supplier software PPAP, and firmware change control sit alongside torque checks and CMM results on the same control plan. The rest will have excellent firewalls and compromised products, and they will not understand the distance between those two things until an auditor or an attacker shows them.