Miguel: It will depend on how the commission will finalize the descriptions on the product categories. As I said, that will happen at the end of this year. And the first thing is to determine if it is within the exclusions, and if not, if it falls in the regulation, then, under which category. But still, there are three lists in the law, but there is no accurate definition on that, so it will depend on the final implementing act, coming at the end of this year.

Miguel: Yep. It is more or less essentially the same question. So, first, if it is not a medical device, then it falls within the regulation. Then we'll need to figure out under which product. It could be a default product, and then you must just provide a self-declaration. But if it is a critical one, you need to undertake the hardest conformity assessment.

Miguel: As I said, the law was published at the end of November last year, but throughout the law, they are stating that they will publish implementing acts during the transition period. As I said, for this particular thing about the categories, they said the end of this year. But it is a quite complex regulation, that must be aligned with other regulations, as Maciej mentioned before. So, we'll see more implementing acts coming throughout the transition period.

Maciej: And maybe to add a little bit to that, ENISA has produced a very nice document, which can be found together with the actual CRA proper document, with all the articles. There is basically a CRA mapping to understand it. So, what they've done is they looked at different other regulations, some of which are industry-specific, like IEC 62443, for example. And they looked at different CRA regulations, and to what degree that existing regulation is aligned, and to what degree it isn't. And so, in this document outline, many of those aspects come on top of existing regulations. It’s a very interesting read, especially if you have some of the existing regulations in place already, and implemented them, you're complying. So, that document might come in very handy.

Maciej: Yes, the CRA mapping is on the ENISA website.

Miguel: It will depend on the product category. So, yes, going back to that slide where I was presenting the different procedures, you will have different options. You will have to pick up one. Obviously, you will take the easiest one, but it will depend, because it could be an industrial, but it could be also industrial and critical, and then a self-declaration is not sufficient.

Maciej: And I just want to add, Miguel, that it's expected that over 90% of the devices will fall within this self-assessment category.

Miguel: Yeah, the default one. Probably 10% will be on the important and critical. That's more or less the statistics around that.

Miguel: All of our SOMs are currently supporting TrustFence. Regarding certifications, there will not be a CRA certification. It's going to be the CE marking. So, if we are talking about other certifications in the cybersecurity world, like CISSP or PSA, yes, we are looking into that, because as Maciej said, in that document that we will share with you later, you can see the mapping between the CRA requirements and current standards and certificates. But, TrustFence is available in all of our SOMs. And yeah, it's included in the hardware itself.

Miguel: Not sure if I got the question right. Maciej, did you get that?

Maciej: So, I think the question is about triage information, and to whom you are supposed to share your findings about it, like if you deem that specific vulnerabilities don't affect you, who do you report that to? And I think that that depends on the criticality, again, of the device, but in self-assessment, you basically keep the documentation. You document the triage info. You then share your findings with end customers. Now, the question is, what happens if your triage is wrong? Right?

Miguel: Right.

Maciej: That's always the worst-case scenario. And that can be an opening for liability, potentially.

Miguel: Yeah, just to add something along that. One of the requirements in Annex I, Part II is that manufacturers will have to provide a mechanism for customers and users to share or submit any kind of vulnerability. So, even if your triage is wrong or it's not accurate, if you are getting... I mean, if you are following the law, you need to provide that portal, or contact form, for your customer or users to potentially communicate any issues. So, the CRA is trying to cover everything, from all different points of view. So that's one thing. And the other thing is the obligation of reporting, which is set in the Article 14, is mandatory, regardless of the product category. So it doesn't matter. You will have to do it.

Maciej: So, but that reporting is about, if you release a device, and you learn that someone hacked your device. And let's say, something that's not yet within the understanding of the wide community, right? If there's no CVE behind it, your obligation is to report that, to share that, "Hey, we were hacked. This is how we were hacked," right? And then you report that to the appropriate governing body. I think, Miguel, you've mentioned CSIRTs here, and ENISA itself, as governing bodies for that reporting.

Miguel: Yeah. Just to highlight, that notification is mandatory. It doesn't matter if you are a critical or important or default. You must do it. Thank you, Maciej.

Miguel: I can tell you that throughout the law, there are some mentions to small or medium companies. I mean, nothing is completely defined, but the commission is kind of trying to underline how important it is to support those kinds of companies, to avoid or mitigate the impact of the CRA. But other than that, there's not much written down. I don't know, Maciej, if you know something else.

Maciej: Well, I think it all comes down to what it costs to get the CE mark. Why? Because the end result is, if you want put a CE mark, you have to be CRA-compliant. Now, if, to sell your products, you're required to have a CE mark, or your customers would not purchase, then yeah, unfortunately, there is the cost of acquiring it, and CRA kind of adds to it. I know, as Miguel said, that they are looking at ways to mitigate that for small companies, but nevertheless, there will be impact.

Miguel: Yeah, and the key here, as Maciej mentioned, is to integrate early in your design, automated processes. Rather than trying to fix every kind, every vulnerability, one by one. It's quite important to do the triage and use automatic tools, like Digi ConnectCore Security Services and Digi ConnecCore Cloud Services.

Miguel: No, that will happen in June 2026.

Miguel: Looks like, because the CRA is not just hardware. It's hardware and software. Even in those product category lists, in the Annex III and IV, you can read it, specifically. Software, operating systems, apps, so, yes.

Miguel: Ooh. I am not an IM [inaudible 01:02:48] I mean, we are... I can talk about our business unit, the OEM business unit, but we are looking into the CRA details, to become compliant. I mean, not just ConnectCore. At the whole Digi portfolio. So, embedded and [inaudible 01:03:08] all of them. But even for the RED Delegated Act, that is gonna come into force in August 1st this year, we are looking into that as well, because it's gonna be kind of the first big milestone hitting. Yeah.

Miguel: Yeah, in Article II, which is the scope, they mention that it could be any product with digital elements, that could be potentially used to be connected. So, according to the wording, it could be anything. I mean, the market surveillance, they don't know if eventually you will connect or not your device, so, if it is capable of connecting, then yes, it will fall under the regulation. That's my understanding.

Maciej: Yes. I agree with your answer. Nothing else to add.