How ISO/SAE 21434 helps you get ready for the Cyber Resilience ActIf you work in automotive, you’ve probably already heard of the CRA – the EU’s Cyber Resilience Act. It’s one of the most ambitious pieces of cybersecurity regulation in years. And while it wasn’t written specifically for cars, it’s going to impact a huge part of how software gets built, updated, and maintained across the automotive stack.So here’s the question: how do you prepare for something like the CRA? And more importantly, how do you prove that your software is secure across its lifecycle, from design to development, to maintenance? That’s where ISO/SAE 21434 comes in.Two regulations, one goalLet’s be clear: ISO/SAE 21434 and CRA aren’t the same thing. The first is an automotive-specific cybersecurity standard. ISO/SAE 21434 specifies the cybersecurity requirements across the entire vehicle lifecycle: from concept and design to decommissioning. Whether it’s for risk management or threat analysis, it’s used by OEMs and suppliers to demonstrate that cybersecurity is always part of the process. The second is a broad EU regulation that applies to most software and hardware products on the market.But they’re aiming at the same target. And ISO/SAE 21434 practices overlap with many of the best practices demanded by the CRA. Both demand the same kind of discipline: secure coding practices, clear vulnerability handling, a structured risk assessment, and actual proof (via documentation) that you’re doing what the regulations demand. Not plans or intentions. Evidence.So if you’re already ISO/SAE 21434-compliant, you’re not starting from scratch when CRA enforcement begins. You’ve got documented processes. You’ve got traceability. You’ve got a culture of treating security as part of the product.Why it matters for open sourceOne of the big challenges with CRA is showing due diligence when you’re using open source software. If the upstream project isn’t CRA-ready, then you’re on the hook for filling the gap. That means more audits, more documentation, and more internal overhead.But thanks to Canonical’s ISO/SAE 21434 certification, that load gets lighter. We’re already following the right processes, including handling CVEs, tracking patches, and maintaining traceability for the software we build and deliver. So when you use Ubuntu or snaps in an automotive system, you’re not inheriting unknowns. You’re building on a stack that’s already aligned with security expectations.It also makes the compliance story easier to tell. When regulators or procurement teams ask, “how do you know this component is safe?”, you’ve got a clear answer with documentation to back it up.What this looks like in practiceSay you’re building an SDV platform and using Ubuntu as the base. At some point, someone’s going to ask: is this secure? How fast do you get patches? What happens if there’s a critical CVE? Who’s responsible for monitoring and fixing it?If your OS vendor is already ISO/SAE 21434-certified, you don’t have to scramble for answers. The processes are already documented. The responsibilities are assigned. And you’ve got an audit trail that shows your supply chain is under control.Not just for cars: how ISO 21434 helps beyond automotiveYou are affected by the CRA even if your business doesn’t revolve around building cars. Construction, agriculture, and other industries using software in vehicles will still need to comply, even if ISO/SAE 21434 isn’t applicable to them directly. That’s why at Canonical, we treat the CRA as a baseline for all products we build and support, regardless of the sector.Canonical already provides tooling for stringent security standards like FIPS and NIS2, and we are committed to full CRA alignment as it evolves. So whether you’re building software for a car, a tractor, or a crane, we’ve got you covered.When will the CRA come into play?In March 2024, the Cyber Resilience Act was approved by the European Parliament. The real deadline to focus on is December 2027: that’s when the enforcement of compliance requirements kicks in. Any product sold in the EU after that date, including automotive software-defined features, has to meet CRA obligations.That might sound far off, but we’re already halfway through the year. 2025 and 2026 are your window to prepare. And not just in theory: you’ll need working processes, proper documentation, clear traceability, and secure development practices in place and running before then. Put simply, 2027 isn’t when you can start planning compliance – it’s when you need to actually be compliant.If you’re already following ISO/SAE 21434, you’re not starting from zero. The structure’s there. To meet the requirements of the CRA, you should be mapping that structure you already have to the new rules and making sure it holds up under scrutiny.What about RED?The CRA isn’t the only regulation you need to think about. The Radio Equipment Directive (RED) adds cybersecurity requirements to anything that communicates over radio. In modern vehicles, that includes a growing number of components, from Wi-Fi and Bluetooth to 4G and 5G connectivity.The good news is that CRA and RED don’t pull you in different directions. They overlap in both scope and approach. If you’re already applying ISO/SAE 21434 and aligning with CRA expectations, you’re on solid ground for RED compliance too. Canonical’s processes around patching, CVE management, and documentation support both.Looking aheadThe CRA won’t replace ISO/SAE 21434, and ISO/SAE 21434 won’t give you a free pass under the CRA. But they reinforce each other. The more you invest in ISO/SAE 21434 today, the less painful CRA enforcement will be tomorrow.Canonical’s position is simple: open source is ready for regulated industries if it’s built right. Our ISO/SAE 21434 certification is one piece of that commitment. We are already ensuring that our processes and products are designed with the CRA in mind, as it is merely the next step in raising the bar. We think security should be taken into consideration from the beginning, rather than being added at the last minute.If you’re building automotive products and need to show your stack is secure, without slowing everything down, we should talk. At Canonical, we’re experienced at helping companies harness open source in the automotive space.Contact UsCurious about Automotive at Canonical? Check out our webpage!Want to learn more about software-defined vehicles? Download our guide!