Does ISO 21434 require obfuscation of our infotainment JavaScript?
No, and the standard is structured in a way that makes the question slightly the wrong shape. It does not contain a list of mandatory controls at all. It describes a risk-based engineering process: identify assets and their damage scenarios, derive threat scenarios, rate the risk, decide how to treat it, and keep the work products that show you did. A control appears in your file because a risk assessment put it there. So the honest answer is that obfuscation is required exactly when your own analysis concludes it treats an identified risk, and not otherwise, and the analysis is the deliverable rather than the control.
What is different about a risk-based standard compared with a checklist?
An unjustified control counts against you, which surprises teams arriving from checklist regimes. Under a checklist, switching on an extra security feature is free or mildly positive. Under a risk-based process, every control in the product is expected to trace back to a threat scenario and a risk value, and to have been chosen over the alternatives for a stated reason. A runtime guard nobody can connect to a threat scenario is not a bonus, it is an unexplained behaviour in a vehicle function, and an assessor is entitled to ask what it is for and what happens when it fires. Enable less, and document why, rather than enabling everything and hoping breadth reads as diligence.
Where does browser-style code actually appear in a vehicle programme?
In more places than the phrase in-vehicle suggests, and they have different risk profiles. The head unit interface is often built with web technology running in an embedded engine. There is usually a companion mobile application with a substantial web component, a telematics or connected-services portal, a dealer and service tool, and increasingly a web view embedded in the vehicle for third-party content. Each sits in a different place relative to the vehicle network, and treating them as one asset is the most common scoping error. Assess the head unit and the connected-services portal separately, because their damage scenarios have almost nothing in common.
Our head unit renders a rear-view camera view and warning telltales. Does that change our options?
Substantially, and this is the sharpest engineering point on the page. Once a display renders anything with a safety role, a control able to blank or halt that display interacts with a safety goal rather than only with a security one. The failure actions this engine offers are worth knowing precisely before enabling any of them. Blanking clears the document element, reloading calls the location reload function, redirecting assigns to location, and every one of those paths ends by throwing. The single exception is the degrade action, which sets a flag and raises a custom event for your own code to handle. On a display with any safety-related content, degrade is the only action defensible in a hazard analysis, and the reasoning belongs in the file alongside the decision.
How do the environment locks behave in an embedded head unit?
Poorly, because their assumptions are those of a public web page. The domain lock resolves the browser hostname and, when there is no usable value, fires the failure action before consulting your allowlist at all. Content loaded from local storage or an embedded viewer frequently has no meaningful hostname, so the guard fails in exactly the environment you are shipping into. The browser and operating-system locks read the navigator object and take the same failure path when it is absent, and an embedded engine that does not match their patterns classifies as unknown, which is never in an allowlist. These options are built for a site served over the public internet, and a vehicle head unit is not that.
What does type approval add on top of the engineering standard?
An audited management system and a requirement that it keeps operating after the vehicle is sold. The regulation your programme is approved against expects a cybersecurity management system covering development, production and the post-production phase, and a separate software update management system governing how updates are specified, verified and delivered to vehicles in the field. The practical consequence for a build pipeline is that your update evidence matters as much as your development evidence: being able to state exactly what an update contained, prove it came from the source you say it did, and reproduce it later, is directly in scope rather than a nice-to-have.
We are a supplier rather than the manufacturer. What is actually expected of us?
Whatever the interface agreement says, which is why reading it early is worth more than any tool decision. The relationship between manufacturer and supplier is expected to be governed by an agreement that allocates the cybersecurity activities between the parties, names who performs which analysis, and defines what evidence flows upward and when. Your build records are frequently a contractual deliverable rather than an internal artifact. If your pipeline cannot produce a manifest, a reproducible build and a component inventory on request, that becomes a commercial problem at the least convenient point in the programme.
How long do we have to keep the material needed to diagnose a release?
Longer than any build system default, and this is the requirement most often missed. Vehicles are supported for many years after the last one is produced, and a report can arrive against a release built by people who have left, using toolchains that have moved on. What you need archived is the exact source, the exact configuration including the seed, the symbol map for that build, and a documented way to rebuild and confirm you reproduced it. Set the retention policy from the support commitment for the vehicle programme, not from your continuous integration retention setting. Without that archive, protection has made a long-lived product harder to service, which is a genuine engineering cost.
Does the transformation interfere with our component inventory obligations?
It does if the inventory is generated from the shipped artifact, and the fix is ordering rather than configuration. Composition analysis recognises known code, and transformed output is much harder to recognise, so a scanner pointed at a protected bundle under-reports and produces a falsely clean inventory. Generate the inventory from your dependency manifests and lock files before the protection step, attach it to the release record, and keep the two together. This is the same ordering rule that applies to every tool that works by reading code.
Where should logic that matters to the vehicle actually live?
Behind the gateway, on the electronic control units that own the function, which is also what the architecture already assumes. A head unit is a presentation surface. Authority for anything consequential belongs to the units that enforce it and to the interfaces between them, and a check performed only in the interface layer is a check that anyone with access to that layer can remove. No build setting changes where a decision is being made. Treating the head unit as a renderer, with consequential decisions enforced further in and the boundary between them explicitly modelled, is both better engineering and a far easier position to defend in an assessment.
What is a defensible entry to put in the cybersecurity case?
A short, accurate one. State that a protection step is applied to the named interface bundles as the final stage of the build, that it is an obfuscating transformation intended to raise the cost of reading and casually modifying delivered code, and that it is not relied on as the treatment for any risk in the assessment unless your analysis specifically says so and shows the trace. Record which runtime options you deliberately left off and the availability or safety reasoning behind it. Then attach the evidence the pipeline produces: the reproducible build record and seed, the manifest, the pre-transformation component inventory, and the symbol map retention matched to the programme's support life.