zlacker

> That doesn't seem like what the CRA stipulates. I think it's more about manual attestation in its most traditional meaning, i.e, an organization attests that X software is secure.

CRA can require EU-wide recall of "products with digital elements" which are found to be non-compliant by national market surveillance. While we may analogize this requirement to the recall of slow-moving physical products with rare market withdrawal, software developers and attackers iterate more quickly.

Centralized software distribution like mobile app stores would have the ability to implement a kill switch (recall) on non-compliant products. Products which depend on centralized cloud services could have binaries verified before they are allowed to connect to an API. This would give regulators the tools to rapidly implement software "recalls".

  (58) … significant cybersecurity risk or pose a risk to the health or safety of persons … market surveillance authorities should take measures to require the economic operator to ensure that the product no longer presents that risk, to recall it or to withdraw it …

  (60) … market surveillance authorities should be able to carry out joint activities with other authorities, with a view to verifying compliance and identifying cybersecurity risks of products with digital elements. 

  (61) Simultaneous coordinated control actions (‘sweeps') are specific enforcement actions by market surveillance authorities that can further enhance product security.

>>transp+(OP)
So what would you propose for recalling physical products that have insecure software that can cause physical trouble? What framework would have sufficed?

>>EMIREL+y
Kill switches based on attested binary identity exist and can be deployed at scale. So they can and likely will be used to comply with regulatory decisions. What remains to be seen is how those regulatory decisions will be made for complex software supply chains.

In part, open-source software arose in response to opaque software.

Can opaque regulation equally govern open and opaque software?

Should open software have open (i.e. continuously evolving in public, not point-in-time negotiated) regulation that can keep up with open development and security research? Much will depend on the operational practices and transparency of national institutions tasked to implement EU CRA.