Cyber Resilience Act Preparedness: Who's Ready, and Who Can't Be Reached

Computers are not safe. Even the best hardware and software products have the potential to conceal as-yet unknown vulnerabilities. And they aren’t all made that well. Many are shuffled into the world without a plan to detect, remediate, and notify users of those vulnerabilities.

The EU’s Cyber Resilience Act aims to improve that situation. The first of its obligations, effective as of September 11, 2026, requires makers of products with digital elements to report and remediate actively exploited vulnerabilities. The full requirements, mandating in-scope companies to take steps to prevent, identify, and remediate vulnerabilities in their products, come into effect December 11, 2027.

Having reviewed the publicly available information on vulnerability disclosure policies for companies in-scope for the CRA, it seems that time will be needed. The CRA requires companies to be prepared to receive vulnerability disclosures and share that information back with users when they are fixed. That is a documentation and process problem that must be solved ahead of time. While we will have to wait and see how companies respond to actual vulnerabilities, we can measure their preparedness now. 

To that end, we surveyed the websites of hardware and software makers for evidence of vulnerability disclosure programs. These would provide compliance with the Annex I requirement to “put in place and enforce a policy on coordinated vulnerability disclosure” and the Annex II requirement to have “the single point of contact where information about vulnerabilities of the product with digital elements can be reported and received, and where the manufacturer’s policy on coordinated vulnerability disclosure can be found.” Our goal was not to audit these companies, but to take a plausible measure of maturity heading into the September 11 enforcement date. 

The two markets we studied, hardware and software, tell two very different stories. Market share for smartphones and tablets is concentrated in a few well-prepared manufacturers. The remaining 5% fail basic requirements, like having a “website at which the manufacturer can be contacted.” Publicly traded software companies, on the other hand, show signs of maturing but must continue improving in order to meet the requirements of the CRA. 

CRA Scope and Its Challenges

The CRA applies to “products with digital elements.” That language is suitably broad to future-proof against new forms of insecurity in hardware, software, and their various combinations. There are also exemptions, like products that are already governed by other EU regulations including medical devices, motor vehicles, planes, and boats. 

The more significant carveout is for software as a service (SaaS), in which the maker delivers a software capability but not a software product. By some estimates, as much as 75% of software is now delivered as SaaS rather than as a downloadable software product. Market size estimates vary in terms of their own methodological scoping but agree that SaaS represents a sizable, if not predominant, chunk of total software value. SaaS products are out of the scope of the CRA because they do not deliver products with vulnerabilities that the owner must address. In terms of data security, however, they continue to store user data and present a meaningful risk vector.

Further complicating the picture, many companies offer both a SaaS and a downloadable or on-prem version of their product. There is a fundamentally complex scoping relationship between companies that maintain policies and programs and products that deliver capabilities through one or more deployment models.

In studying how many companies are prepared to meet the vulnerability reporting mandates, these nuances do not just add uncertainty to the classification process; they reveal the pressure points where expectations and outcomes are most likely to diverge in the application of the CRA itself. 

Measuring CRA readiness

To fix vulnerabilities, companies must first learn of them and be prepared to respond. Thus, while we can’t measure compliance failures that will take place in the future, we can measure the preventative mechanisms that should be in place ahead of time. 

To do so, we surveyed the presence and depth of vulnerability disclosure policies published on the websites of companies that sell in-scope hardware (smartphones and tablets) and software (downloadable or on-prem) products. Across these two groups we observed two very different failure modes, as well as signs of hope—including a vulnerability disclosure page added during our evaluation window. During this process we updated our criteria for preparedness to be more lenient and include not just vulnerability disclosure programs but any public policies about vulnerability management. 

For hardware products, we started with the 2,374 products registered with EPREL, the energy reporting mandate that all devices sold in the EU must comply with, and resolved those to brands and manufacturers. For software, we collected software companies traded on 16 stock exchanges in the UK and Europe: OMXSTO, LSE, Euronext, Xetra, and more, This yielded 486 companies. Narrowing to only those selling a software product—not SaaS, resellers, or service providers—left us with 226 companies. On further review, 64 of those (especially on the Polish exchanges) were video game studios. While those are in scope, they distort the view of companies most likely to have meaningful vulnerabilities. After removing those we had 162 publicly traded companies, almost certainly selling in the EU, whose products include non-SaaS software. 

Hardware: 95% good news, don’t ask about the rest. 

Compare the 2,374 EPREL-registered smartphones and tablets to the number of manufacturers you can name and you get a sense of the distribution of this universe. iPhones, for example, have seven entries in the EPREL registry and about 37% market share in Europe. Even after you get through Google, Samsung, and the rest of the name-brand Android makers, there are literally thousands of phones from no-name manufacturers. The prospects for their security response programs are about as bad as can be. 

Measuring preparedness as a percentage of models or manufacturers, the situation looks dire. Only 23% of models and 14% of manufacturers have baseline vulnerability reporting mechanisms. However, when we weight the manufacturers by reported market share of their devices, the risk to EU citizens is much lower. 

The majority of devices in use are made by companies that are not just well-prepared for the CRA, but have exemplary vulnerability disclosure processes. Market leaders Apple (37%), Samsung (30%), Xiaomi (13%), Google, Motorola, Huawei, and Oppo all exhibited the highest levels of maturity. They have product security incident response teams (PSIRTs), machine-readable CSAFs, and are themselves CVE numbering authorities (CNAs).

‍

The bad news is that the budget manufacturers have strong indications they will never be CRA compliant. 29% of EU models use a freemail domain (like @gmail.com, @hotmail.com, or @qq.com) for their EPREL regulatory contact. In terms of digital maturity, setting up email would generally come before a vulnerability response program. 16% of models (89 of 276 manufacturers) have no findable website at all; they can only be found through other storefronts. Again, this does not mean they won’t fix vulnerabilities, but it neither meets the CRA requirements nor inspires confidence.

Software: not bad, but not great

Whereas the hardware market cleanly polarizes into very mature and immature programs, the positions of the publicly listed software companies are more muddled. All of these companies had websites and means to contact them. The evidence for the vulnerability reporting maturity of these organizations, however, was mixed. 

31% had a public vulnerability disclosure process that we could find. Our searches included: crawling sites for security.txt files; crawling paths like /security and /legal in twelve languages; searching for company names and domains across an aggregated index of 4,132 bug bounty programs on services like HackerOne, Bugcrowd, and Intigriti; and a battery of web searches like “<company name> vulnerability disclosure,” “<product name> vulnerability disclosure,” and so on. Classification was done by Claude Sonnet with escalation to Opus in ambiguous cases and reviewed by a human. In genuinely ambiguous cases we gave the benefit of the doubt and counted the evidence as indicative of a positive capability.

59% visibly prepared, 41% we will find out later

Beyond the 31% with an identifiable vulnerability disclosure program, an additional 28% had discoverable pages related to their security programs—good evidence of some capability to discover and respond to vulnerabilities. While a VDP may be the letter of the law, we can reasonably believe that these companies will be able to fulfill their CRA reporting duties. Between a VDP or some kind of security program, 59% of companies had public evidence of being prepared to meet their CRA reporting requirements.

At the same time, even the less prepared organizations were not in the same situation as the phone manufacturers without a website. These are all sizable companies with millions or billions of Euros in turnover and clear paths to communicate with them. The CRA is hardly the first European data protection regulation, and prior requirements like publishing the email address of a Data Protection Officer create mechanisms for reaching them. 

Evidence for reasonable doubts

Much of our time went into reviewing and refining the classification methods, as the evidence was often genuinely ambiguous or even contradictory. For example, one of our early crawls flagged a company for a security.txt file with an expires date of 2023-07-30. On review, we saw that the resources linked from there are exemplary and active: a dedicated VDP subdomain and YesWeHack bounty program updated within the last month. The security.txt itself has not been looked at in years, eroding its function as the canonical source of contact information, but the programs themselves are alive. 

Nothing actually happens when a security.txt “expires”—it’s just supposed to keep contact information from becoming stale and inaccurate. In this case, the opposite has happened: the resources are up to date but the security.txt is not. It is a very minor signal, but still makes one wonder what else hasn’t been updated since 2023. We highlight this example because it is one where the net result still indicates a good posture for the company, while illustrating how the multiple signals of program maturity can be incongruous.

Predictors of CRA preparedness

The same correlation between program preparedness and company resources seen amongst hardware companies pertains to software companies, too. While only 31% of companies have a vulnerability reporting route, that covers 79% of total market cap. The 59% with any security documentation covers 87%. 

We have observed this correlation between market cap and security maturity elsewhere in our annual surveys of companies listed on the ASX. The CRA provides no exemptions for company size, so smaller companies will have to rely on their greater agility to counterbalance their lower capability in formal vulnerability programs. 

Signs of continuing improvement

We initially collected the data for this survey from August 13 to 22. While performing additional testing on August 28 to audit the methodology, we found something interesting: a vulnerability disclosure policy page that was not part of our dataset. This page was very obviously titled Vulnerability Disclosure Policy with all the primary branding of one of our targets. How had we missed it?

Our best guess is that it was brand new. This page’s last updated date was August 28, the day we found it. There was no prior record of it in archive.org’s Wayback Machine, while other privacy URLs for this site were recorded there. The exact search that found it on August 28 had been executed a week earlier with no result. The only thing that had changed was that the CRA’s enforcement date had gotten much closer.

The most likely explanation, then, was that the CRA was working exactly as planned: it had incentivized a company to adopt a vulnerability disclosure program. While regulations necessarily have enforcement dates when requirements come into effect, the goal is continuous long-term improvement. For sizable software companies, we see companies traveling along that arc. Other digital product classes, like hardware and SaaS, may require additional intervention.