For years, many organizations treated cybersecurity as something that could be strengthened over time. While this was important, it was often approached as a downstream responsibility rather than a defining part of product strategy. Security issues were typically patched after release, and vulnerabilities were handled as they emerged. Compliance was a process that could be addressed later.
As pointed out in this previous QNX blog from Winston Leung, companies now need to get ready for the EU Cyber Resilience Act (CRA). The act establishes cybersecurity requirements for products with digital elements placed on the EU market that tie security to the full lifecycle of the product—not just to the point of launch. There are various industries that are affected by the EU CRA Act, including Industrial Automation, Consumer Electronics, IoT Devices, Telecom, Energy & Utilities, and Professional Services. Further, there are different classifications within the EU CRA based on the criticality of the system at hand; for example: smart home devices vs critical utilities infrastructure would be considered at different levels of security classification.
Why EU CRA Matters and Reflects a New Reality?
The EU CRA is a new regulation that outlines a legal framework describing the cybersecurity requirements for hardware and software products with digital elements placed on the market of the European Union. In practice, it basically applies to any products containing software and connected functionality.
As products are becoming more software-defined, more connected, and more dependent on multiple vendors, development tools, and third-party components, the risk of cyber-attacks is also exponentially increasing.
While non-safety-critical systems are not heavily impacted by the EU CRA, any mission-critical system that has complex hardware and software will be required to comply with stringent security requirements at a higher classification level. Cars, medical devices, industrial systems, even refrigerators now run more software than previous times. And we are seeing attacks everywhere now - not just on laptops and servers, but even on operational technology such as vehicles, hospitals, factories, machines, and devices.
The increased cyber-attacks on devices are leading to stronger expectations for built-in cybersecurity, rising demand for SBOMs (Software Bill of Materials) and CVE (Common Vulnerabilities and Exposures) transparency. This also comes with a growing scrutiny of software supply chains. Security is converging as a primary concern in connected systems, making cybersecurity not just a technical priority but a broader issue of continuity, trust, and resilience.
With the EU CRA, products in the field are now being judged not only by what they do, but by how securely they are designed, how transparently they are maintained, and how responsibly vendors handle vulnerabilities over time, post-production after systems are deployed in the field. In effect, having Systems lifecycle accountability is not just a best practice, but is becoming a necessary standard to have products working in the field.
To address the increased risks surrounding security, the EU CRA is centered around building products that are secure by design. The expectation is that manufacturers proactively reduce risks during design and development. It includes vulnerability management to identify, monitor, and remediate vulnerabilities effectively, while transparently communicating and providing security documentation and reporting obligations. This matters because it extends the company’s responsibility (that is, selling into the EU) well beyond the release phase. It formalizes the expectation that cybersecurity must persist throughout the support period of the product.
What has Fundamentally Changed?
The urgency surrounding the EU CRA comes partly from its timeline. Reporting obligations for exploited vulnerabilities begin on September 11, 2026, and all other requirements apply from December 11, 2027. Those dates are important because they turn long-range awareness into immediate execution pressure. Organizations selling into the EU no longer have the luxury of treating product cybersecurity as a future-state ambition. The transition from discussion to operational readiness is already underway.
Major organizations are already preparing teams and structures to address this regulation. While the timelines alone are not what makes the EU CRA so consequential, the readiness required is more important than ever.
Many organizations already perform security activities. They may have secure development practices, patch processes, product documentation, or vulnerability programs. The challenge is that the EU CRA regulation does not simply ask whether these activities exist. Companies now will need a systematic, measurable, repeatable, and documented approach across the full product lifecycle. It also does not hand manufacturers a single prescriptive standard they can adopt and be done. Instead, companies must select, justify, and sustain their cybersecurity approach across. The EU CRA, in effect, demands both compliance and organizational maturity for products to be rolled out.
Why is this difficult to implement and how does it affect Lifecycle Accountability?
The most important idea behind the EU CRA is that security responsibility does not end at the product’s release. The regulation’s essential requirements cover both product cybersecurity and vulnerability handling. In practical terms, this means that manufacturers are expected to build products securely and then continue managing those products responsibly over time. That includes identifying and documenting vulnerabilities and components, supporting vulnerability reporting, providing security updates, and maintaining the ability to respond to security issues throughout the supported lifecycle.
The overhead to maintain lifecycle accountability becomes an operating principle. This brings in an additional complexity on product maintenance where some of the hardest challenges are not at the beginning of the product journey, but later: ongoing vulnerability handling, timely updates, end-of-support notifications, incident response, auditability, and post-end-of-life concerns are all part of the process. This requires product, engineering, security, and support teams to work as a connected system rather than as isolated functions.
The EU CRA also affects products containing open-source software. If the open-source software is used in the context of a commercial purpose- where the product being sold has open-source components - then all the requirements of EU CRA still apply. This effectively introduces due-diligence obligations for open-source software stewards - including fixing vulnerabilities arising from open-source software components and not waiting until the community fixes it. Hence, companies will need to comply with EU CRA while commercially integrating open-source components into products placed on the EU market.
How does QNX help to address EU CRA?
At QNX, cybersecurity is foundational. It influences how we design, build, test, and maintain our products. This culture enables us to deliver secure and trusted platforms for critical embedded systems. QNX integrates security principles at every stage, from architecture through to deployment. Ensuring security is not an afterthought but a core design principle. In addition, QNX also contributes to cybersecurity working groups and standard bodies to stay ahead of emerging threats and help shape the future of secure embedded systems.
Aligned with ISO/SAE 21434, ISO 27001, UNECE R155/R156, the QNX processes align with key automotive and IT security standards to meet customer and regulatory expectations across global markets. This maps directly to the requirements of the EU CRA, especially from a point of Vulnerability Management & Reporting, Secure configuration, Secure development lifecycles, SBOM, and Extended EOL (End-of-life support).
QNX also has an established cybersecurity baseline that strongly supports EU CRA compliance, including ISO 21434 certifications for both the QNX Cyber Security Management System and QNX 8.0-based products, and has ongoing formal EU CRA conformity work.
The broader QNX portfolio reinforces that lifecycle orientation. QNX’s software and services in terms of foundational software include a host of deliverables and post-product maintenance. It includes the operating system, hypervisor, middleware, development tools, security solutions, professional services, compliance management, secure delivery, proactive updates, long-term support, and traceability. It also emphasizes runtime security capabilities such as secure boots, integrity measurement, access controls, binary signing, policy management, and monitoring-oriented controls. Those capabilities matter because they help support repeatable, evidence-based product governance; the kind of governance the EU CRA increasingly demands.
One of the clearest examples of this lifecycle thinking is QNX’s focus on support beyond conventional product milestones. With extended EOL(End-of-life) support and a Post-EOL CVE Monitoring Service designed to address the monitoring gap by tracking runtime components that have reached end of life, aggregating data from multiple CVE sources becomes more manageable. This also includes performing technical assessments and providing reporting and remediation actions through QNX’s professional services. Industries such as industrial automation, robotics, and other related domains typically have their products running in the field for a long period of time. Having resiliency and trust in their operations hence becomes crucial for long-term reliability.
Conclusion
EU CRA has implications far beyond Europe, especially for global companies that sell into the EU. Organizations focused on broader global markets are seeing the same pressures emerge everywhere: customers want visibility into software content, regulators expect stronger vulnerability response, and the market increasingly assumes that secure-by-design and secure-by-default are foundational expectations, not premium features.
That is why the EU CRA matters now, and its timing reflects a market reality that was already accelerating where security can no longer be episodic, reactive, or separate from product strategy. It must be architectural, operational, and enduring. The strongest organizations will not be the ones that wait to assemble evidence at the end. They will be the ones that use this shift to modernize how products are designed, built, secured, maintained, and supported across the full systems lifecycle.
QNX’s approach matters in the EU CRA’s context because it addresses the challenge where it lives—across development discipline, software transparency, vulnerability management, runtime protection, and long-term support. As lifecycle accountability becomes the new standard for digital products, foundations like EU CRA will matter more than ever to deliver a safe, secure, and reliable product.