Cyber Resilience Act for OEMs: From Compliance Evidence to a Lifecycle Service

Hi and hello dear friends of IoT. This is your podcast about real-world IoT implementation. I'm your host Madeleine Mickeleit, trained as a mechanical engineer. And today we're talking about a topic that's becoming a real issue for a lot of you and a lot of manufacturers. It's about the European Cyber Resilience Act, or CRA for short. A lot of you might know something about it, might hear about it. So today we're starting with facts and definition on a real-world example. Danfoss, it's a Danish family-owned company, manufactures drive technology, cooling systems and some other industrial machinery.

And we want to answer today questions like: which use cases are relevant for CRA? How is it integrated in your architecture? We try to explain it not too technical, so don't worry. And what is it actually cost, or what are actual business cases behind it, and how to work here together with partners, maybe your cloud partners, things like this.

And today we're recording with the company I haven't had in the podcast, I guess, for over a year: our partner Cumulocity, formerly known as Software AG. And today with Miguel Morales, he's Vice President Cloud Alliances at Cumulocity. And as always, you can find all information on implementing these and other projects on iotusecase.com. Also contacts and sources you'll find in this show. Hi Miguel, thanks for being here.

Miguel

Excited to be here with you. Thank you.

It's so lovely to have you today. Maybe to directly start with you, Miguel, and your role. You are the Vice President Cloud Alliances at Cumulocity. What does that mean and how did you get to this role? Because you have been working also with other big companies in your past. So I'm really curious to learn more about this.

Miguel

So the Vice President of Strategic Cloud Alliances role is focused on the global alliances with the hyperscalers. So specifically Microsoft, AWS, and Google. We deploy together on their infrastructure. We integrate with their solutions. And we partner with them commercially to solve some of these tough problems like CRA compliance that we'll be talking about today.

And I got here by a series of unfortunate events, I guess. Or fortunate or unfortunate, right? I grew up at Texas Instruments for about eight years in embedded systems. So I've always been either in the microcontroller or microprocessor embedded system side of things. Lately, I'm becoming more of an engineer again. And I moved into IoT officially in 2015. I joined a startup called Exosite out of Minneapolis.

Cool.

Miguel

For an industrial company called Parker Hannifin. I joined them, Vice President of IoT at the corporate level, working with the businesses to commercialize IoT solutions. There I had exposure to implementing on Azure IoT, licensing, elevate licensing, Litmus Automation, to companies that I think are doing a great job in this industry. And then I moved into Microsoft and Azure IoT for four years, working with OEMs and with operators on deployment systems.

Perfect for our discussion today also. So Miguel, before we dive in, let me probably introduce you. So you lead Cumulocity's global alliances with the hyperscalers. Which one, by the way? Maybe you can answer that in a second. And you started your career at Texas Instruments, about eight years in embedded systems. In 2015, you moved into IoT with a startup called Exosite, where you grew their Parker Hannifin account so much that they brought you in as Vice President of IoT at the corporate level. And from there you spent four years at Microsoft Azure IoT working directly with OEMs and operators. So how long have you been at Cumulocity now, and what does CRA mean to you today?

Miguel

I've been at Cumulocity for three years. It's been great. I started in sales and I've just really come to appreciate the power of a channel, of partner channel, in our growth strategy. And honestly I also have discovered through the CRA what I think is one of the most critical topics of our industry.

The reason that I've gone through all of these changes, I just realized last year, is we're heading into this like brave new world of infinite capability. And the CRA was the first sort of teacher for me. In studying the CRA, it became my teacher to understand that we need autonomy to earn trust before it earns authority. And what started off as like, man, look at those CRA requirements, as really challenging or even onerous – I think it has proven to be quite timely and appropriate for where the industry is going. And so that passion is really reflected in our partnerships with the hyperscalers, being very focused on landing OT security and using that opportunity to modernize for the coming age.

All right. So first of all, I'd love to learn more about how you deploy and integrate with AWS, Google and Microsoft, because some listeners might actually think Cumulocity competes with hyperscalers. So it would be good to understand how you actually work together with them, as you were just mentioning also the partnership. And it might be also interesting for people who work with Microsoft or other hyperscalers how they could use assets, features from Cumulocity here. I guess we will come to that in a second related to CRA.

And by the way, I loved your picture about the teacher. There was a really important point here. But before we go further, let me quickly frame the topic, or maybe we could frame the topic so everybody is on the same page with CRA. And actually somebody of our community asked me if we could put together a top 10 list of actions or considerations on that, because manufacturers are at very different stages here depending on knowledge and company size and how much they already know about it. So do you think we could do that today?

Miguel

Certainly, certainly. We keep saying in the CRA that the EU Cyber Resilience Act is regulation that has two major dates coming up in September of this year, September 2026, and then full enforcement of December 2027. And it really holds the manufacturers of connected products accountable for managing the cybersecurity of their assets and requires evidence of doing so. And so in September, you're supposed to start reporting on any exploited vulnerabilities or exploitable vulnerabilities to the governing bodies in Europe within 24 hours of identifying them, and then following up on a clock with how you're handling the event.

So it regulates manufacturers' products, if you want so, and the product means in this case a software or hardware product and its remote data processing solutions, right? So when I'm a manufacturer and I'm selling a product or a digital product, it's relevant for me.

Miguel

100 %. And it's sort of a brother or a sister regulation to some of the other ones you may have heard of, but we're not talking about today, but are also relevant – the Data Act. What we will talk about today is the relationship between the manufacturer of the product and the customer's requirement for NIS2 regulatory compliance.

And so the EU CRA says the manufacturer has to provide evidence of the vulnerabilities and provide patches for download or for deployment. The NIS2 regulation is the operator side of the equation. And it says, well, you buy products. You have to demonstrate that you are operating these products and maintaining your cybersecurity posture as an operator.

Right. And they are two central pillars of the European cybersecurity strategy. And as you said, NIS2 regulates more the operators, the end user who is using, for example, a digital project or product, for example a manufacturer cloud or a manufacturer connected product. And then the CRA regulates what we just told, like the manufacturer product itself, right?

Miguel

Indeed. And so hopefully you remember more than one thing from the podcast, but I would say ...

It's the first thing you have to remember.

Miguel

The first thing is you don't have to treat CRA compliance as just a compliance initiative. There is a commercial opportunity here that can really accelerate the ROI for your compliance project. And it lives in the intersection of these two worlds, of the CRA requirements and then the NIS2 requirements. And that's what I'd like to communicate.

Let's come to this in a second, and you just talked about the compliance project. And as a lot of people are listening to the podcast, they know that I'm always curious about learning out of the practice. Before we continue, can you bring up like one customer example of your ecosystem? Because I know you have lots and lots of customers and partners. By the way, check out the website, there are a lot of partners in the Cumulocity area. But yeah, maybe we could point out one project of a manufacturer which fits here, which we can use to discuss a bit more in a practical way, if you know what I mean.

Miguel

Certainly. I mean, you mentioned it at the beginning. So Danfoss published a cybersecurity paper on the DrivePro products. Published it last year.

First of all, so Danfoss are manufacturer of the drives, for example, or cooling systems. So they have their products in the field of their customers. And what is their use cases?

Miguel

Correct. So Danfoss is a diverse company and they have – I think they call it a climate solutions group, which is like the HVAC – and they have where the drives part of their business is a significant portion of the products. And we're talking about an industrial automation, an actuator component that's going to spin motors.

And so these are really – they for a while had been governed by the IEC 62443 standard, which is really an engineering standard that claims the engineering process is secure and then that the products themselves can demonstrate specific security levels according to how they've been designed and verified. And what the CRA adds on top of that is the requirement that links it to the market, that says, in order to sell it in Europe moving forward, you have to provide the evidence of what software is being deployed through your SBOM and the reporting requirements, so that there is no security by obscurity, vulnerabilities are shared and everybody can benefit.

I see. So what you're describing here are more the technical use cases, I would say – things like rolling out the latest firmware or keeping a record that shows exactly what was updated and when. So that's the audit log part, I would say. These are basically also product features that different IoT solutions offer for this, and companies like you sell them as part of their platform. So I think that's worth naming these clearly here, because if you're listening now and your company does something similar or you need something similar, you could already start thinking like, oh okay, that applies to us too.

So if you want to see how Cumulocity actually supports this technically, they have a specific page for CRA and NIS2 compliance on the website. So we'll link you that in the show notes if you want to learn more. And we'll actually get into some of these concrete features later in the episode, so stay tuned. But now let's look at the actual business use case behind this. So for Danfoss specifically, what's the real business reason for offering all of this to their end customer?

Miguel

Yeah, so if you can imagine Danfoss as the manufacturer sells these to the end customer who it requires NIS2 compliance, that means their end customer needs to demonstrate they're managing cybersecurity. So Danfoss says, hey, let me make it easy for you. Here is the cybersecurity paper about the standards we use that motivate our design. And there's three layers. There's the drives, there's the gateway, there's the IoT platform. They mentioned Cumulocity is the IoT platform in the white paper.

I will put that in the show notes, by the way, if you want to look that up, the white paper.

Miguel

Yes, please. Thank you. And so they fundamentally – their customers, when they buy Danfoss product using the DrivePro product, can ensure that they benefit from easy deployment of the latest version of firmware. And they can see if they need to make any updates to maintain compliance. And they have that evidence, the audit logs that show when things were installed. So for a NIS2 operator, that's extremely valuable, because NIS2 comes with personal liability.

And I think about this: if I owned a company and I were personally legally liable for compliance on this regulation, I want more than just the word of my team that we're following cybersecurity. I think that's where the opportunity lies for a company like Danfoss to say, let us give you evidence, let us give you tooling that ensures we deploy the latest and greatest versions of software security patches and that we're maintaining this discipline that we publish in the white paper. To me, that's value. That's a certain peace of mind.

I think that we're going to start seeing a lot more of these white papers, a lot more of these services of companies that recognize the opportunity to sell a service on top of the hardware they sell, to deliver that peace of mind and the evidence of how their devices are being maintained in an operator environment.

Okay, so let me put this in order so that I for myself have a sum-up of what you just said. What you just described are the technical use cases, I would say. So the three layers – drives, gateway and the IoT platform – you have easy firmware updates and audit logs as proof.

I'm thinking of, for example, a customer of Danfoss here, for example a water treatment plant. I just looked that up on their website, so they actually list water and wastewater as one of the industries. Wanting lots of these motor drives to power pumps and conveyor belts here in the field of their customers. And they would say now, okay, dear customer, we make your life easy. We show you automatically if your pump is secure, and we make sure – so we will send you updates whenever something needs fixing.

And the plant operator is the one who is personally liable under NIS2. So when Danfoss gives them this proof and easy firmware updates, that's real useful help for someone who would otherwise have to prove all of this themselves. So for every single drive on their own. Thinking about it this way, where's the line between what a manufacturer like Danfoss has to do under CRA and what becomes kind of an extra opportunity for these customers on top?

Miguel

Yeah, so it's useful to draw a boundary between what's necessary and what the opportunity is, right? And what's necessary to be compliant is that you publish your SBOMs, your software bill of materials – that's essentially all the stuff that you use to generate your firmware – that you publish active exploits and that you publish exploitable vulnerabilities, and then you patch them and you make that patch available.

But frankly, that's where CRA ends. You can post the firmware on a website and say, you better watch this website for my firmware updates and then deploy them. Then the NIS2 operators say, okay, you have to prove how you are maintaining the cybersecurity health of your fleet across all the different things you buy. And most operators have a diversity of OEM products that they deploy.

And so that's the gap. If you want to close the gap and say, I'm not just going to post it on a website, but I'm going to give you a tooling that shows you how you're deploying that in the fleet you've purchased from me, and providing auditable evidence that you can use when you have to prove your own compliance – that's the opportunity that exists in the market to commercialize. Frankly, if you can do that better and easily, it's a differentiator, it's a revenue stream. And I think that's what people miss when they think about CRA as just the legal requirement.

Yeah, absolutely. So now thinking about the commercial side, have you seen companies in your ecosystem that actually turned this compliance work into a paid service? So something a customer pays extra for? A lot of companies are still testing this out, learning about this, especially with CRA deadlines coming up. So has anyone actually made real money from this yet?

Miguel

At a high level, I visualize the value streams of IoT programs as either internal use, optimizing workflows for internal use, versus external revenues. And in the value stream of the external use cases, so when you start to sell the product – the foundation for both, internal and external, is actually that you have to have that remote accessibility, you have to be collecting telemetry, you have to be able to update those devices, you want a certain level of security. And now the regulations are gating commercial sale with compliance.

But the first stage that we see in our customers is they just license the software, not for money. They ship the software, but there's a license with it that says, hey, you'll let us collect data so that when you call us, we serve you better. And next, in order to elevate to pricing the software, you have to understand the risk that you're reducing for that customer and then price it, right? So in this case, it's the compliance risk of the NIS2 operator.

And one of the top 10 things that everybody should do, in the document that we'll have available at the end of the podcast as well for download, is go ask three of your operators one question. What is the evidence that you need for your next audit? And what would you pay to stop collecting, assembling that evidence yourself? That's not my research. That validates whether my hypothesis is true for you as an OEM. If you ask your customers that are operating your equipment: what is the evidence that you need, and how much would you pay to not have to put together that evidence yourself? What if I just gave it to you for all of my products?

And that's the opportunity. And clarify with them what the exchange is going to be, how it's going to work. And I think you'll learn a lot about that risk gap that moves from just licensing connected products for free as a value add to a priced software license. And beyond that, you can start to sell outcomes. Once you start collecting enough evidence of how your devices are performing in your customer base, you can start to consider selling outcomes or selling security as a service. Like, I can guarantee that my products are always going to be 90 % on the latest firmware. You can start to get more creative with the service level agreements and capture more of that value.

But that's sort of the maturity curve. And the first step just requires compliance. The next step requires the license. The next step requires pricing the risk. And then that requires sufficient evidence that you have an opportunity to commercialize outcomes.

Oh, that's a really exciting point. So you're saying figure out what real risk you're removing for the customer and charge based on that value. So I'll actually bring this up in our next community session. That's really interesting, and ask people how they see that. But when you say risk here, do you mean something like a security insurance, or is it broader than that?

Miguel

Yeah, I mean, there's risk in the insurance sense. But I think that the majority of these cases aren't necessarily selling a security service, a security lifecycle service – I do think that's applicable to the CRA – if you interpret risk as operating risk. What is the chance that the guy operating the fryers at the fast food restaurant is going to maintain it like that fryer needs? Make sure that the filter is changed and the oil is clean. And I'm using a different customer use case here, but the risk is pretty high.

Like if the manufacturer can provide evidence that that operation can improve, to the asset owner and to the P&L of the operator, they're reducing real monetary risk, right? Because the project was created with certain assumptions, and to a certain extent the risk that those assumptions are not met in the field is what you can price. And in this case, we're just talking about cybersecurity risk.

But when I say price risk, I think that the more common use case is: instead of a freemium model where like, oh, I have cool features over here and less cool features for the basic version – you have to instrument the platform with your definition of risk that you think you mitigate for the end customer. Then convince yourself that indeed you are mitigating it, and you have an opportunity to price it. And I do think that's a growing trend amongst the hardware manufacturers, is pricing software services. I see it amongst a majority of our connected product companies that have been with us for, say, more than three years. They reached that point where they've seen enough evidence and they understand the risk gap they can close, and they start commercializing the lifecycle services.

Am I as a manufacturer, by the way, responsible in the relation of CRA here when it's about the device core function? Or is it about also everything I'm connecting to my cloud? Where's the space I'm moving in as a manufacturer, because there is a pre and an after process around my connected product?

Miguel

The product itself is what carries the CE mark, right? The hardware carries that CE mark. And there's different risk levels, right? Most products are actually self-certified. Then depending on the risk class, you can go on the ENISA website and they classify them as important devices, class one, class two, critical devices. And it really becomes about how close you get to, let's call it, infrastructure, right? Like if something bad happens to certain devices. So you should definitely know, because once you get to class two and critical, then you require third-party certification.

And the scope of what they certify includes the hardware and the solution that supports it. It does include your device management product. And you have to be able to describe the whole process by which you monitor for vulnerabilities, generate your SBOMs, generate the VEX files, submit them, and then propagate that into your fleet to understand which updates are required and how you make those updates available. And that can feel overwhelming if that's not a core part of your operations. Like if you're not a medical company today – maybe for some of the industrial OEMs or other OEMs, this feels new to them.

So we do have a reference design that we publish. There's a white paper that we wrote together with EY Legal in Germany, Cumulocity and EY Legal in Germany, that's available on our website. And then as part of my job, I get the pleasure of connecting this reference design into the various hyperscaler ecosystems. That's where we collaborate. Microsoft is one of the world's largest enterprise IT security companies. So they have the firmware scanning and the role-based access control services and the audit signature technology, et cetera. So that's where we collaborate with the hyperscalers, is this reference design that you can leverage today.

We also have a professional services package that is like a one-month evaluation. Interview your team, say, where are you today across your entire fleet? These are the recommendations. And it's a more rigorous version of my top 10 things you can do to become CRA compliant thing that will be available.

Okay, so I'll put that white paper you just mentioned in the show notes. If you want to learn more about that, please look that up. So now before we get to the top 10 list, let's walk through this step by step so we understand how that actually works. So let's say a vulnerability gets discovered in your product software. So what happens next? What do customers do and how do you help them, more from a technical aspect?

Miguel

ENISA themselves have done a much better job, I would say, since publishing the original CRA text. They recently released a document – I think it's still in draft, but heading to final – that talks about secure by design principles and secure by default. These are kind of the two high-level ideas that they want to demonstrate. And they get relatively specific in that document about what defines one or the other. So on my list is definitely connect yourself to that website, monitor it and interpret that for yourself.

It includes: you got to take all your firmware and make sure that it's being scanned. And I'm of the belief you almost need like continuous scanning, because vulnerabilities these days are emerging and they're exploited – you know, 30 % of them exploited within the first day. Average number of days of exploit for vulnerability versus the patch is negative seven days. On average, the exploits are happening seven days before they're getting patched. So the industry has to catch up here: continuous scanning.

For example, my drives or my gateways or whatever named hardware I have in the field on the customer side.

Miguel

Oh yeah. So imagine a gateway in your drive – then the gateway has software, your gateway and your drive has software. So you are responsible for proving that the software, as you deliver it, as you install it at the customer, or as you perform firmware updates, that it has no known exploitable vulnerabilities.

And that's kind of an interesting thing. So there's a difference between – I use Linux, Linux has vulnerabilities, and exploitable vulnerabilities, because that gap is your design. The number of vulnerabilities that are even really available for exploit has to be harmonized. And so there are tools for that. There are internal processes by which you decide what is an exploitable vulnerability, and map a very long list of known vulnerabilities to what's actually exploitable on your device. You're only responsible for communicating what's either under exploit or exploitable. So that gap is one where I see customers working on that: how do they define exploitability and what they actually have to publish in what I think they call it a VEX file to the regulator.

Okay. By the way, when you are interested to learn more about security by design, I did one episode, and also we have a lot of partners who are focused on that. So we're not driving into that in the podcast, but if you're interested, I'll put you also in the show notes the link to the podcast episode I had about this.

Miguel

I will listen to it as well. Then those vulnerabilities are true for the software bill of materials in a given firmware distribution. And that's deployed to a certain set of devices. So OEM, make, model, version has firmware versions that are compliant, right? And firmware versions that are out of date that still represent those vulnerabilities.

So the OEM needs to be able to prove that for the make model version – of every make model version they sell of hardware – they have firmware available that addresses the vulnerability within a certain period of time. That's a requirement. So when you are able to deploy those, how easy can you make that? That's when you get an IoT platform involved.

Yeah, that's what I just want to ask. So how do I do that on the IoT platform? For example, especially this customer pointed out Cumulocity as a database, but also I have maybe other IoT platforms. How do I make sure that it is CRA conform? For example, that I have multifactor authentication, or like my data storage is okay? So do you have examples how I manage this layer?

Miguel

Yes. Essentially the CRA has, I think, 50-something obligatory clauses, right? If you were to read the text, there's 50 lines in there that say, you got to do this, you got to do that. And I segment them into procedural – like things that you have to submit a report – and platform implementable.

And so Cumulocity targets the platform implementable ones, that say stuff like, you need to have a secure identity on the device for authenticating it before it accesses your platform. And so Cumulocity has support for PKI certificates and those need to rotate on a regular basis. You have to make that firmware available for download, so we are able to not only stage the firmware and say, okay, here it is, it's available – but if you want, Cumulocity will make sure that it's easily deployed across the appropriate make model versions firmware, and that we can provide the audit logs that say, well, hey, we shipped that firmware on this date to those devices. And then the devices reported that the firmware update was successful, or they reported that the firmware update was not successful. And we have to remediate those devices to make sure that they caught up to the appropriate rate. And that's the part that can get really difficult at scale.

That's the value of an IoT platform like Cumulocity, when you talk about making a service like that available, especially for OEMs, because they sell stuff globally. So you're not talking about a factory site where you control the network. You're talking about devices that are distributed globally. So making that service available globally, maintaining availability, designing the services to remediate the corner conditions – those are the things that are sort of baked into the Cumulocity IoT platform and that OEMs benefit from not having to design. They can stay focused on the differentiating aspects of what evidence they need to generate for their customers, or the data value propositions of using secure, verified secure device data for insights and improving operations.

Every device is ultimately responsible for reporting secure identity, its build time state, and its runtime state, and its environment. I call it the BRE model. So tell me your identity and is it current – it's probably a PKI certificate. What firmware are you supposed to run? Are you really running that firmware, if you run a hash over your runtime, or did somebody inject something? And what network are you on? What configuration do you have? That's the data a platform needs to be able to compare against and continuously calculate compliance. I'll stop right there, but I think that's the big shift: moving from once a year compliance to the ability to continuously prove which devices are or are not compliant and automatically generate the evidence that's needed to validate.

Okay, to sum that up: so the big shift here is moving away from a once a year compliance check to being able to prove compliance continuously and automatically, device by device. So, and one more question before we get to the top 10 list, finally. So how does that actually work between you and the hyperscaler? So who does what and how does it fit together?

Miguel

I think it's different for each hyperscaler. I guess I can talk about what Cumulocity is really great at, right? At the end of the day, we are going to manage the security posture of the device. All the firmware updates, the identity updates – we're going to orchestrate those updates across a diverse fleet of large devices, small devices, medium devices that are globally distributed. And so that's the deployment side of the equation.

With the hyperscalers, we collaborate in two ways. They have hosted infrastructure at many of these OEMs and many of the operators. So they may already have a significant investment or a commitment that they've made to those hyperscalers to consume X amount of Azure or AWS or Google. And so what we do is we make Cumulocity available for purchase in their marketplace. So if you have a commitment to Azure and you purchase Cumulocity, the entire license counts towards that consumption. So there's an incentive for collaborating with the hyperscalers and making sure that we integrate with the products.

Microsoft has Entra for role-based access control, to control who has access to make which changes on the platform. Microsoft has the firmware scanning tool, so you can identify vulnerabilities and map to which devices they exist in the fleet. They have the audit logs. Microsoft can be the CA that generates or signs the identities that you can deploy to your devices. So it just depends. In the case of Google, that's more of a data integration and security infrastructure. So it depends on the hyperscaler, but fundamentally we connect into the existing services that customers have, and then we provide that orchestration layer for how we evidence that the devices are being updated in a compliant way.

Okay, let's bring this together. So far we've talked about things like publishing your SBOM – that's your software bill of materials, basically a full list of every software component in your product. Designing security into your product from the start. Scanning continuously for problems and figuring out which vulnerabilities are actually dangerous.

You also said something that stuck with me: ask your own customer what evidence they need for the next audit. That's a really good point. And what they'd pay to not have to collect it themselves. And that's a key point, like keeping the patch itself free, but selling the proof and tracking around it as a service. And a lot of this already sounds like our top 10 list, so maybe we could finally come to that. So what's the complete top 10 list, and what are the top 10 actions here from your point of view?

Miguel

The first I didn't mention is get it out of legal immediately.

All right. Why is that?

Miguel

I mean, it's just been a pattern over the past year. I talk to a customer, I'm like, tell me about your CRA initiative. And they're like, oh, it's still in legal. I was like, okay, well, you have to move that into the product P&Ls, right? Because it's a business continuity risk to the P&Ls. And so we have to drive accountability that's supported by legal and informed by legal as to what you can say. But make sure that the P&Ls are owning compliance.

And not just one P&L, but strategically – item two, look across your whole product fleet, because maybe there's best practices and one product team is already deployed, you can leverage across other parts of your product. You do have to make sure you have a monitoring infrastructure for the scanning, for the SBOM generation, sort of integrated as a core function of your software and firmware development practice, right? Because you have to quickly react not only to patch vulnerabilities, but to remain compliant, be able to communicate them within 24 hours.

So the automation of that evidence. Customers are working through how to translate – find out how you're going to translate vulnerabilities to exploitable vulnerabilities, because that gap matters so that you're not just publishing vulnerabilities that are not relevant to your product. Since the September date is coming up real soon, you want to make sure that you have the disclosure paths identified.

Yeah. Let me check: the September date is the earlier deadline for that manufacturers already have to report when a security flaw or something.

Miguel

Yes. So they need to report the actively exploited vulnerabilities and severe incidents. ENISA is standing up a single reporting platform. You have to do what within 24 hours, what you have to do within 72 hours, what you have to do within 15 days. And there needs to be a disclosure policy. There's a contact point. You need to know who in your country do you need to send this thing to, right? So you have to make sure that you understand exactly where the documentation is going to flow on September 11th of 2026.

And you need somebody watching the ENISA developments, because they're doing their best to publish their interpretation of their own regulation into what they're going to be looking for. Nobody's been audited yet. Even though their interpretation might shift a little bit, the fundamentals are always still going to remain, right? Fundamentally, you're still going to need to know what's in your product. You're going to need to watch it. You're going to need to fix it. You're going to need to prove it. But you should be watching when ENISA finalizes their Secure by Design and Secure by Default playbook. When the single reporting platform website becomes available, you need to know the day of.

And come up with commitment for support in writing. And again, flow it to the P&Ls. Because by the way, making the patches available has to be free, right? The commercialization part is providing the evidence to your customer. But this all has to be provided for free according to the regulation, and you have to record it for five years. So you need to build that into your ROI, your program calculation.

Make sure you have a way to actually land those updates – that's where Cumulocity can help. And make sure that you ask, that everybody's clear about where your responsibilities end to be compliant and what the commercial opportunity could be. So again, go ask your customers that question about what evidence do you need to prove for compliance, and how much would you pay if I gave it to you instead of you having to compile it yourself. So you can validate my claim of what the ROI calculation would be. And so I'll provide kind of a high-level ROI calculator.

That would be nice.

Miguel

And what is it costing me today to do all of this stuff, and what happens if I replace it with awesome IoT platform and I can make some revenue off of it. I'm looking at ROI calculations of 4x to 8x returns depending on how much you can optimize out of those very human and manual processes that exist today.

Okay, that's cool. So I was not counting every point. Do we have 10?

Miguel

There's 10 in there. Yeah, you'll see in the downloadable PDF on the website.

Okay, definitely check that out. So as also people ask in the community – here we go, here we have it. So let's look ahead for the final question. In five years, for example, do you think that CRA compliance will be just a standard feature in any IoT platform provider like you, Cumulocity, or also OEMs could sell that out of the box? Or will every company still need its own custom project to get here? So what's your take?

Miguel

I think that cybersecurity is sort of like a fingerprint of a device. When you develop a device, it has a fingerprint, and that shape defines how it could be exploited on various different levels, whether it's application, network, access, deployment. And so I think that cybersecurity is going to remain a bespoke product specific need. But the principles, the workflows of, let's call it, the software development and deployment lifecycle at scale ...

Any update, for example, was successful or not successful. So that could be one thing.

Miguel

Oh yeah. Like a failed A/B update, you know, somebody pulled the power while you were receiving an update. The scenarios are so specific to the industry that I think that the low level cybersecurity, the device level cybersecurity considerations are going to remain specific. But the capabilities of an enterprise to manage cybersecurity and provide evidence to their executives and to their customer executives of cybersecurity program, I think that is going to be standard. Yes, it will be expected. And it will be removed from the market, in my opinion, not by the regulators, but by the bad guys that are able to exploit anything that isn't doing that.

So cybersecurity used to be like a differentiator, a nerdy topic. But in this world where AI can hack the US government or global governments and it's being withheld because it's too powerful – like think about five years from now, IoT devices are the ideal target. They might not have that visibility and discipline today to make sure that everybody knows what every IoT asset is in the network. So they're a perfect exploit, they're a preferred exploit for these attackers. And so I think AI is going to show us pretty quick who does and who does not have a fully automated, modernized cybersecurity, agile infrastructure, and those are the companies that will survive. I think the other products, they're just gonna be like, oh, you can't use that.

All right. So yeah, thanks. So that was just a little question for the future. And I hope you will stay connected to our network. So maybe we'll see you again, also in another podcast, or maybe one to our user group meetups, because people are talking a lot about this, but also other topics. So maybe you will stay connected to the network. I would love to hear from you again.

Miguel

I would love to. I've really enjoyed our conversation today. And I never thought when I was young that I'd be so passionate about regulation and compliance, but here I am, and I think it's a critical topic for the industry to get right. And I would love to be part of the conversation.

Perfect. Yeah. And thanks for all your insights today, and also for the concrete customer case, because that makes it more practical. So yeah, thanks for your time and the session today. And I would give you the last word to close the session, but from my side, thanks for your time and our session today.

Miguel

Thank you so much. My last word is: the CRA is one step along the way of moving towards more autonomous systems. It's a necessary step. And the reason I stay in IoT is that we have to develop connected solutions that earn trust before they earn the authority to act. I stay in the industry and I stay at Cumulocity and I work with the hyperscalers because I believe in that mission, and I hope that your listeners will join me on that journey and make sure that connected solutions earn trust before they earn the authority to act autonomously.

Perfect, love that. Have a nice rest of the week. Bye bye.

Miguel

Thank you. Bye.