ISO/SAE 21434 vs IEC 62443: Vehicle or Plant, and What If Your Product Is Both?

What is the difference?

ISO/SAE 21434 is written for one product class, road vehicles and the ECUs and software inside them; IEC 62443 is written for one environment, industrial automation and control systems and the components they are built from. The automotive standard describes the engineering lifecycle: organisational cybersecurity management (clause 5), project management (6), distributed activities between OEM and supplier (7), continual activities such as monitoring and vulnerability management (8), concept and TARA (9 and 15), product development and validation (10 and 11), production, operations and end of support (12 to 14). It does not contain technical requirements like “the ECU shall authenticate diagnostic sessions”; it tells you how to derive them from your own TARA.

IEC 62443 does contain technical requirements. 62443-3-3 lists system requirements per foundational requirement and Security Level, 4-2 does the same for components, and 3-2 gives the risk method with zones and conduits. 4-1 covers the development process, which is the part closest to 21434. Where 21434 says “derive your goals from the threat scenarios”, 62443 says “a component at SL 2 shall provide these capabilities”. That makes 62443 easier to specify in a purchase order and 21434 easier to apply to a product nobody has threat-modelled before.

Side by side

	ISO/SAE 21434	IEC 62443
What it covers	Cybersecurity engineering of road vehicles, their systems, ECUs and software across the lifecycle: TARA, concept, development, validation, production, operations, decommissioning; the process side of the UN R155 CSMS	Security of industrial automation and control systems: operator programmes (2-1), service providers (2-4), risk assessment with zones and conduits (3-2), system requirements (3-3), development lifecycle (4-1), component requirements (4-2)
What it does not cover	Prescriptive technical requirements or security levels; the plant or factory that builds the car; back-end and charging infrastructure outside the vehicle’s item definition	Vehicles and type approval; the OEM-supplier interface agreements that 21434 clause 7 formalises; attacker models with physical access to a mass-produced unit at home
Who is addressed	OEMs and their suppliers of ECUs, software and components; indirectly the type-approval authority through UN R155	Asset owners of plants, system integrators, and product suppliers of PLCs, drives, HMIs, machines and industrial software
Duration	A TARA for one ECU two to six weeks; a complete set of work products for a component project several months alongside development	A plant risk assessment two to three months; bringing a development process to 4-1 and a product to a 4-2 Security Level one to two years
Typical cost	TARA and cybersecurity concept for an ECU 10,000 to 30,000 euros; ECU penetration test and fuzzing 20,000 to 45,000; typical ranges for Germany and the EU, not an offer	OT risk assessment and penetration test 12,000 to 25,000 euros per site; 4-1 process and 4-2 component evaluations often five-figure sums per product; not an offer
Recurring duties	Continual monitoring, vulnerability management and incident response for the support period (clause 8 and 13); updates to TARA on changes	Patch and vulnerability management (2-3, 4-1 practice DM), reassessment of zones after changes, re-evaluation of components after major releases
Required by	UN R155 for type approval in the EU and 60 plus contracting states; OEM contracts and cybersecurity interface agreements; UN R156 for software updates alongside	OEM and operator specifications for machines and components; NIS2 for plant operators in practice; Machinery Regulation and CRA via harmonised standards for industrial products
Output	Item definition, TARA, cybersecurity goals and concept, specifications, verification and validation reports, cybersecurity case, release for post-development	Zone and conduit model with target SLs, requirement traceability per 3-3 or 4-2, process evidence per 4-1, optional certificates per product or process from accredited bodies

Choose ISO/SAE 21434 when

• Your product goes into a road vehicle: car, truck, bus, trailer with electronics, motorcycle. The OEM’s type approval depends on UN R155, and the OEM will cascade 21434 work products to you via a cybersecurity interface agreement.
• You are an OEM building a CSMS. UN R155 does not name a standard, but 21434 is what the authorities and technical services expect to see behind it.
• The threat picture is the automotive one: an attacker owns a unit, has unlimited time with it, and attacks via OBD, CAN, UDS, Bluetooth, cellular and the back end. The TARA method of clause 15 is built for that.

Choose IEC 62443 when

• Your product is a controller, drive, HMI, machine, robot or industrial software, or you run a plant. The buyer wants a Security Level and 4-1 process evidence, not a TARA in automotive vocabulary.
• Availability and safety of a running process dominate the risk. The zone and conduit method and the foundational requirements of 62443 express that; 21434 has no equivalent for segmentation of a plant.
• The CRA and the Machinery Regulation are your route to market. For industrial products the harmonised standards will build on 62443, not on 21434.

Both together

Products in between need both, and that is more common than it looks: EV charging stations (vehicle protocols on one side, grid and building automation on the other), agricultural and construction machinery with road-approved variants, and factory equipment built on automotive-grade controllers. The efficient approach is one risk assessment that produces both a 21434 TARA and a 62443-3-2 zone model, one development process documented against clause 10 of 21434 and 62443-4-1 with a mapping table, and one vulnerability-management process that serves UN R155, the CRA and plant customers.

Zyberum does TARAs and ISO/SAE 21434 work products for OEMs and suppliers, IEC 62443 risk assessments and 4-1 and 4-2 gap analyses for machine builders, and penetration tests and fuzzing of ECUs and industrial controllers. We do not issue CSMS certificates or IEC 62443 certificates; those come from type-approval authorities and accredited bodies. If your product sits in between, we map the two standards once so that you do not pay for two processes.