The timetable is eminently realistic. It may be quite the change however; but whether that's a bad thing? The specific criticism in the letter appears to be a little unreasonable, frankly.

Presumably any actively supported software is taking _some_ steps within that first day of becoming aware that there exists an actively exploited exploit. Merely reporting it's existence confidentially does not appear to be an infeasible step, at least for professional organizations (what about small-scale OSS?). The requirement does not apply to all vulnerabilities; it applies to vulnerabilities the manufacturer knows of _and_ that are actively exploited _and_ the corporation knows this.

They letter authors express the worry that governments will abuse these vulnerabilities; but while the worry is reasonable, the correct avenue for that is public discourse and accountability; not granting corporations access to vulnerabilities that governments may not see via one specific route, surely? Additionally, if abuse of vulnerabilities by governments is a problem, then let's address _that_ not merely one specific means of communication about them. And if the worry is abuse; then surely this holds for all actors, explicitly non-governmental ones too. Nor is it obvious abuse will rise merely due to reporting. And lack of reporting may indeed encourage abuse by non-governmental organization because there is less chance of it being detected. There already exists a somewhat legal but unethical market for exploits; adding government bureaucracy here is almost certainly better than just letting money talk. The argument seems almost bad in faith; it's concerned about abuse by intelligence services that presumably have some democratic oversight; yet not concerned about abuse outside of that. Had the authors argued in favor of obligatory secrecy regarding _all_ actors, and proposed a mechanism to safeguard that, their claimed aim would have been more plausible - but they did no.

The exposure risk the letter posts makes no sense. The legislation doesn't require publication; it requires confidential reporting. The only way this argument makes sense (but the letter doesn't make it explicit) is if they think corporations will be unable to communicate securely with such a reporting endpoint, or that the endpoint itself will be accessible by bad actors (presumably via a security problem?). Again, the letter does not make this argument; it's leaving us guessing.

The letter conflates mitigation by the software publisher with mitigation by the software consumer, and the way it does that sure looks intentional; essentially claiming there's no benefit from letting the software's user mitigate a vulnerability because the producer already is. That's clearly nonsense. The letter also uses emotive language such as "each disclosure
triggers a wave of government notifications"; I'm skeptical the authors are capable of being unbiased if that's how they're presenting this argument to change policy.

Fundamentally, the letter appears to value private corporate control over secrets above government access. That's simply a political stance - but I'd have an easier time taking that seriously if they just came out and said it.

Additionally, the letter doesn't address one of the points of partial transparency like this: it discourages harmful CYA secrecy. Reporting on vulnerabilities is a financial risk; there's always the incentive to find excuses (whether explicitly, or organically due to how organizations work) to mitigate that at the expense of mitigating the harms of the vulnerability itself. People and corporations act differently when they know others might take note of their choices. And that's often a good thing. Even _if_ there are real harms due to confidential reporting, it's not clear those outweigh the benefits.

To be clear: I do NOT support the CRA (don't know enough, but it sounds potentially onerous, for sure); I merely don't believe this letter makes a very convincing case against article 11. There may well be better arguments, and almost by definition improvement is possible.