I am afraid this is a very narrow reading of the CRA. Did you read the act yourself or some qualified opinion by a European lawyer? Security updates are the default demand of CRA and not having them is an exception that requires an assessment of risk (which I would assume mean that it's only viable for devices not directly connected to Internet).

An (equally narrow ;)) quote:

"ensure that vulnerabilities can be addressed through security updates, including, where applicable, through automatic security updates that are installed within an appropriate timeframe enabled as a default setting, with a clear and easy-to-use opt-out mechanism, through the notification of available updates to users, and the option to temporarily postpone them;"

Thus, I expect RED to stipulate only radio firmware to be locked down to prevent you from unlocking any frequencies but the CRA to require all other software to be updatable to patch vulns.

I have not read the RED or the CRA, nor discussed what they specifically say with a lawyer who has read them. However, I have gone through a recent product R&D process in Europe where the product has WiFi and LTE connectivity, so it falls under the RED (even though WiFi and 4G are handled by off-the-shelf modules). I have read parts of the EN-18031 standards (mostly using their decision trees and descriptions of decision nodes as reference), I've been on a seminar with a Notified Body about what the practical implications of the RED are, I've filled out a huge document going through all the decision trees in 18031 and giving justifications for the specific path through the decision tree applies to our product. I've also discussed the implications of the RED and 18031 with consultants.

I don't doubt you with regard to what the RED and the CRA actually says. However I'm afraid that my understanding of it better reflects the practical real-world implications of companies who just need to go through the certification process.

18031 requires an update mechanism for most products, yes, however it some very stringent requirements for it to be considered a Secure Update Mechanism. I sadly don't have the 18031 standard anymore so I can't look up the specific decision nodes, but I know for sure that allowing anyone with physical access to just flash the product with new unsigned firmware would not count as a Secure Update Mechanism (I think unless you can justify that the operational environment of the product ensures that no unauthorized person has physical access to the device, or something like that).

EDIT: And I wanted to add, in one common use case for microcontrollers, namely as one part of a larger product with some SoC running Linux being the main application processor and with MCUs handling specific tasks, you can easily get a PASS in all the EN-18031 decision trees without an upgrade mechanism for the MCUs themselves. In such products, I can imagine a company deciding that it's easier to just permanently lock down the MCU with a write protect than to justify leaving it writeable.

Thank you, an interesting (and somewhat sad) perspective. Would be unfortunate if these two regulations combined result in less firmware update capabilities not more.

Yeah, it's sad. I can say with certainty that there are products whose developers would have decided to leave MCUs and/or SoMs writeable based on analysing the threat model, but where the rigid decision trees in EN-18031 around secure storage mechanisms and secure update mechanisms makes that too difficult to justify.