CRA-Compliant Update and Device Management: Build or Buy?

Madeleine:

Hello, dear friends of IoT, and welcome to the IoT Use Case Podcast, your channel for putting IoT into practice. I’m your host, Madeleine Mickeleit, a trained mechanical engineer, and I’d really like to recommend this episode to all of you – especially those of you who are manufacturers in the EU, and everyone who works with manufacturers or buys from them. Because since September 2026, something has been in force that many people have on their radar, but not everyone yet: the Cyber Resilience Act, or CRA for short.

That’s what we’re talking about today, and in very practical terms it means one thing above all: you have to keep the software on your devices up to date and secure in the field, even after they’ve been sold – and with many devices, for years. That’s exactly what today is about: how to handle update and device management, and how to maintain these devices in the field without having to drive out to each one individually. In the end, we’ll answer three questions today: What do I have to do? How do I do it now? And what do I need to watch out for, where can my costs really explode?

We’ll also work through an exciting business case and return-on-investment calculation, look at the technical implementation and, of course, answer the community questions I’ve received. And I have two great guests with me for that. You’ll find out who they are in a moment. As always, you can find all the information on implementing these and similar projects at www.iotusecase.com and in the show notes. Let’s go!

Hello Yves, hello Marvin. How are you both doing today? Yves, I’ll start with you.

Yves:

Hi, I’m doing well. I’m very happy to be here, since this is the first podcast I’ve ever done. And I’m curious to see how we’ll get on.

Madeleine:

How we’ll get on. Yes, very nice. Where am I reaching you right now? Where are you?

Yves:

I’m working from home in Nierstein, near Mainz, not far from our company, which is based in Mainz.

Madeleine:

Okay, cool. Well then, greetings from Mainz, from the Frankfurt region, and to everyone listening right now. So, you’re a graduate engineer and have been with PHYTEC Messtechnik GmbH for many years, today as Head of Product Management. Maybe we can talk briefly about your motivation: What makes product development at your company so exciting? Do you have a personal interest in it, or a personal motivation? What keeps you in this field?

Yves:

Well, as an engineer I’m naturally excited about technology. I also do a lot in this area privately, and I always find it fascinating to see how technology keeps evolving. Revolutionary things like AI now, and IoT before that, have always been movements that excited me. And as an engineer, you look for solutions to problems – and we always have problems – and the solutions somehow come to you when you look at what tools you –

Madeleine:

They come to you. Nice. That’s great. A word about PHYTEC: For those who don’t know you yet – you just said you’re from Mainz. You supply embedded modules with a processor and everything around it that’s needed for a working system. If I’ve understood correctly, your customers use them to build their end systems, and your team is ultimately responsible for everything needed to make attractive products, including software and now also emerging topics like the Cyber Resilience Act. But you’re here today as an expert in security maintenance and management of these connected devices.

Can you describe embedded modules a bit? To me it’s always – I always put it a bit clumsily: you have a circuit board, and it’s populated with certain components, and that’s a module that then takes on [probably: “certain”] tasks within a larger device or system. Can you describe what your market looks like – did I put that correctly? And who are your customers? I’d be interested in that to start with.

Yves:

The idea of putting a processor – back then still microprocessors – on a circuit board and building the peripherals around it basically came from the company’s founder more than 30 years ago. The thinking was: if you design a microprocessor system or an embedded system, you always need a certain set of components that work together. The design is relatively complex, so why not encapsulate it on a module?

And say: if I have the processor, I also need memory attached to it, and the RAM interface, for example, is very fast, which means the routing is complex. And pretty much everyone needs a certain set of peripherals, [probably: “an Ethernet PHY, for example”] and so on. The signals from this module are then routed down and made usable on a carrier board that customers can design themselves – or we do it for them – where the individual features of the processor are then physically broken out, so that the corresponding interfaces are available. That’s the basic idea of a module like this.

And the whole thing is so generic that the target markets can be anything. It can be a ticket machine at a train station with a display and keyboard or touchscreen and a printer for receipts, or it can simply be a medical device, ultrasound or whatever – anywhere something needs to be controlled and regulated. We also have a lot of customers in industry, in manufacturing, automation and so on. Everything is possible with these –

Madeleine:

So you cover all kinds of industries. And now the question: What do you actually have to do with IoT? Because in the end, one could say your device simply gets built in. As you said, it ends up in a ticket machine or a medical device. Where does IoT come into play for you? Or let’s say: connecting the device or the processor.

Yves:

The devices are often connected. These days there are hardly any devices that aren’t. You can picture it any way you like: even the ticket machine will at some point want to send its cash data somewhere, because not everyone wants to do a sneakernet update, as you say, going there with a USB stick to read out the cash data. We also have a lot of customers with EV charging stations, for example, and those are controlled remotely as well. And of course a secure connection is important there.

Madeleine:

Okay. What I meant was also that one could say: sure, the ticket machine gets connected. But what does that have to do with you as an embedded module manufacturer? You know what I mean? Because you basically [probably: “supply”] the module. One could say that’s where it ends for you. You know what I mean?

Yves:

No, but that’s fundamentally not our philosophy. We do say the core is always the same, and of course that scales, and we can produce or develop it very cost-effectively compared to someone doing it in small quantities. We do it for many customers. But that also allows us to generate even more value on top. That means we have an operating system that runs on it. For the CRA, that operating system is also maintained accordingly with vulnerability management, meaning CVE monitoring, and with LTS streams, meaning continuously maintained software versions that can be rolled out in the field again and again to reduce or eliminate vulnerabilities.

And basically we always look at what many customers need and where we can do groundwork in advance. It starts with the module, where the core is always the same, but the software is designed the same way. Everyone needs an operating system, a Linux, and that operating system needs certain basic functions and special functions. The special functions are individual and customer-specific – we can’t finish everything for everyone.

Madeleine:

Generating added value – and as you mentioned: CVE monitoring, and also the software versions that need to be controlled. I think we’ll get to that in a moment, and Marvin, that’s where you come in, and you personally in this project. Let’s talk about you briefly, Marvin. Marvin König, today it’s you, I believe? Yes, exactly, you’re COO at ML!PA, you have a background in business informatics, you started with a dual study programme at Deutsche Telekom, already worked in IT consulting during your studies, and you’ve been with ML!PA since 2018, today as deputy managing director. You’re strategically responsible for the product area – we’ll get to which one in a moment. Can you tell us a bit more about yourself, your role and briefly about ML!PA, so we understand how you’re working with PHYTEC as a customer?

Marvin:

As you rightly said, I have a background in business informatics, and I actually started my career here at ML!PA the same way. That means I initially worked a lot in project business. Traditionally, we come more from the project business, so we developed IoT solutions cross-functionally. That really means hardware development here in-house, embedded development, but also cloud programming. So for our customers we really tried to cover the complete product end to end.

When it comes to customers, we’re talking about the rail sector, for example, as one area, but also the construction machinery sector and the construction industry in general, where we’ve developed solutions together with our customers. And over time, we simply developed more and more modules, so to speak, for recurring problems. So we tried to standardize these problems, these solutions for them, and then deploy them for our customers.

Madeleine:

Just briefly, for context, for those who don’t know you yet. So ML!PA, you have it in your name – ML!PA Consulting GmbH. Would you describe yourselves classically as – well, the word consulting really points towards advisory. But you do a lot more than that. You’re also a system integrator, or rather you offer individual support, but you also have your own products. Can you briefly position the company again, just for those who don’t know you yet, so they have it on their radar?

Marvin:

Exactly, that’s how we’ve developed. Historically, we’ve grown steadily. Classically, we come largely from consulting. But we’ve increasingly become a product company, which is what we are today. And, as I just touched on, we’ve taken our project experience, standardized the problems and, as you said at the beginning, bundled them into a device lifecycle management system, so to speak, which takes care of over-the-air updates, device monitoring, observability, but also asset management, and can manage the devices centrally for our customers.

Madeleine:

You’ve also worked on a project together here, which even resulted in – or where one of your products was used. We’ll come to that in a moment. Can you briefly describe what this joint project was? You’ve both already mentioned the common denominator, the CRA. How did you meet? How did you get started?

Yves:

Well, we were actually looking for a standard solution. As I said, we always try to have solutions for problems that many customers have. And one of them is updating – updating the device, exactly. We had already integrated update mechanisms into our BSP, a client – it’s called RAUC – which makes sure the system can be updated securely with two, well, with a fallback partition in case something goes wrong. And we always maintain that in the BSP. But we didn’t have a proper counterpart for centrally controlling lots of devices.

Of course, we looked at many solutions. There are lots of ready-made solutions out there. But most of them are take-it-or-leave-it solutions. You get something set up, a server, you see your devices there, and then you have to figure out how to use it in your use case. But over the years, while searching and also in conversations with customers, I noticed that customers always have different setups. There are always customers who already have their own infrastructure, to some extent, and would like to connect it.

There are also customers who have several projects in their company but don’t always use PHYTEC hardware – they also develop in-house or use other module manufacturers. And that’s why we didn’t want to build a solution ourselves, because that would have been a kind of vendor lock-in. We didn’t want any of that. We wanted to keep it open. So we looked for a partner. In terms of features, ML!PA’s L-IoT solution was really convincing. It was pretty impressive what they already had, especially in asset management. They were very detailed there.

And the advantage for us was that ML!PA is also a service provider that can make customizations. That fit very well with our realization that customers often still need individual adaptations to a certain degree. So a standard product, yes, but then please tailored a little in the details. That’s important from our point of view, and it’s now being confirmed in our collaboration that this seems to be the right approach.

Madeleine:

Can you briefly tell us how many devices are typically involved, just to give us a ballpark figure? If you’re talking about ticket machines, that’s a lot. How many devices are out in the field?

Yves:

First of all, I have to make one thing clear: we don’t do the updates at the customers’ sites. Our customers build the end device, and they typically manage the updates at their customers’ sites or give their customers the ability to manage the updates. As for quantities, our sweet spot is typically around 5,000 to 10,000 devices per year. We also have customers who only take 100 units or so, and we’re happy with them too. But there are also very large customers who take more than 50,000 units a year.

Madeleine:

Interesting. I can imagine it’s challenging to really keep all these devices up to date. Maybe we can talk a bit more about the challenges in a moment – and you also mentioned customizations – and what exactly your customers’ requirements are. Now you’ve brought L-IoT into play, and some listeners may not have heard of it. I believe, Marvin, it’s pronounced “Elliot”, right? L-IoT – that’s a product you launched, so to speak. Is that right?

Okay, so for everyone who wants to learn more: I’ll put it in the show notes in advance so you can read up on it later. I’ll add the link to the product. So in the end, this is a product that solves update and device management. Is that fair to say?

Marvin:

That’s exactly right. In the end, it solves exactly this point. And as Yves already indicated: there are solutions out there that our customers use to update devices, such as RAUC as one technology. What customers often underestimate as additional effort is that you need a whole management layer around it. In the end, you need staged rollouts. That means you want to control which devices updates are rolled out to. You need success criteria so that you can then go on to update the next 20 or 30 percent of the devices.

You want to provide rollbacks and perhaps be able to carry them out on-site, locally, if something goes wrong. You have different operating modes. In some circumstances, updates must not be carried out at all while the device is in operation, et cetera. So what we noticed with our customers is that there’s considerable complexity in the logic, which the software on the market, especially in the open-source space, can’t cover.

So that’s what we focused on: integrating any open-source solutions that customers already use, but providing all the logic behind them – to really make sure the devices don’t fail, to carry out updates step by step – in a management interface.

Madeleine:

What you just said is really interesting, because in the end that’s where the money is for manufacturers if they have to do it themselves. I can imagine the effort becomes extremely high if I have to manage hundreds or even thousands of devices myself. And you mentioned RAUC, which is an open-source update tool for Linux devices. I found the point you just made interesting, about all these things: an update must not be carried out when a certain situation occurs.

We’ve talked about CVE monitoring, software versions and so on. Can you tell me what a manufacturer actually needs to have on their radar, perhaps also with regard to the CRA? And what actually happens if I don’t do it? What do I lose in terms of time and money? Can we talk about that a bit? I’d be interested to hear what your experience has been.

Marvin:

With regard to the CRA in particular, it’s ultimately an obligation to keep the software up to date not only at launch, that is, not only at product launch, but throughout the entire lifecycle of the product. And this product lifecycle is at least five years, or however the manufacturer defines it for its customers, so possibly longer. Especially with our classic customers – freight transport, construction machinery – the lifetime of an asset can be ten years or considerably more.

And the Cyber Resilience Act basically says that you have to maintain the software over this lifetime, and that means: if there’s a vulnerability, it has to be addressed and fixed. So I have to patch this vulnerability in the field, and a system like device lifecycle management is simply essential for that. On top of that, we generally need to be more innovative, right? It’s not just that compliance is one topic – it’s increasingly about moving towards a software-defined machine or software-defined anything.

So that there’s less and less mechanical control and more and more control via software, electronically, and with that I also need some flexibility in the field to roll out additional functions to a machine retrospectively, for assistance systems, et cetera.

Madeleine:

Yes, exactly. A quick word on the Cyber Resilience Act: I’ll put the official EU regulation in the show notes again. You’ll also find all the timelines there. As you just said, the reporting obligation has been in force since September 11 this year. A reporting obligation for actively exploited vulnerabilities, as you said, and also for – I think they define it as severe incidents – which also have to be reported. And there’s a second deadline, December 11, 2027, when the full obligations such as CE marking and conformity assessment apply to all products placed on the market.

If you want to learn more about it: I did a whole episode on it, episode 222. Feel free to listen in, 222, or subscribe to the podcast and listen to it later. It’s explained in more detail there. Now you just said “becoming more innovative”. Can you explain again why that’s relevant for customers like PHYTEC, but also others you share? Why is it important to become more innovative here and to have this digital data?

Marvin:

Yves already touched on it. I think we’re all experiencing quite a significant revolution right now with artificial intelligence and the large language models that are out there, just as one aspect. And we’re simply noticing that digital products are currently developing even faster than 10 or 20 years ago. Digital, that is IT products, have always developed relatively quickly if you look back.

Personally, I see this development accelerating even further while competition from Asia, but also from America, is becoming much stronger. So in the end you simply have to keep up if we want to stay competitive here. And part of that is being able to roll out lots of digital products in the field. I think many of the technical challenges have been solved, especially in IoT. Many technical standards have become established. There are now solutions for many of the problems we had ten years ago. And now it’s really about rolling out solutions in the field in a scalable way.

Madeleine:

Especially when you have as many devices as we’ve just been talking about. Yves, my question: earlier you mentioned various things, including CVE monitoring and so on, and you said your customers also have customization requests. Can you describe what kind of information is generated, especially when you develop a product like this – what data points, so to speak, and what information is relevant for your customers?

Yves:

Well, basically I think you have to divide it into the payload data that makes up the application, meaning the actual data I want to transmit from the application – like with the ticket machine, where I want to transmit cash data or timetable information or something like that. And then there’s the system management data, which is more internal information used to identify the devices, network them and maintain them.

It starts with software versions. You need to know which device has which software version, so you can decide whether it needs to be updated or not, and which vulnerabilities this particular device has with this software version. And you also have to clarify compatibility. I might have certain hardware revisions that need specific software versions made for them. And in the next generation, the software is no longer compatible with the hardware at all. All of that has to be managed somehow.

And at some point that becomes a huge overhead. People underestimate it. At the start you think: I have a device and software, I’ll [probably: “get”] it together somehow. And then product management comes along and says: I want a variant X with a smaller display. And what do I know? A component gets discontinued? Then suddenly I need a new processor that requires a completely different build. And then I have all sorts of variants and groups of devices that I somehow have to manage.

And I think that’s probably the kind of data you meant. This management data – on top of the [probably: “application-specific”] payload data, there’s an additional management overhead.

Madeleine:

So for you it’s mainly about this system management data, this administrative data that has to be managed. Why didn’t you build it yourselves? A really silly question. You could have said: well, we’ll put a few people together internally and get to work on it. What was the reason you said you’d bring ML!PA on board? Where does the effort actually come from? And why did you decide not to do it yourselves?

Yves:

Well, we’re a manufacturing company, and we have this scaling mindset, I have to say. We try to create a product and use it to serve many customers. Of course we also do customer-specific development, but it always has to be in proportion. We also have to keep our production busy, because producing hardware is basically our core business. And too much individual implementation becomes difficult. There’s a certain limit per project, but at some point we say: no, now we have to stick to what we know best.

And that’s why we said: okay, we need a partner who can customize. And as I already mentioned, when you look at these individual device infrastructures – I might have a gateway with lots of smaller IoT devices underneath it, MCUs or similar, that directly control sensors. That creates very complex asset management, and you have to solve that with the customer somehow. And we didn’t want to go that deep.

That’s why we said: okay, we need a partner who can do this customization work but – and this is the great thing – also has a core product, a standard product that already has all the basic functions you typically need for IoT update and device management.

Madeleine:

So L-IoT, “Elliot”, as you called it, is the basis, so to speak, where you said: hey, it makes sense to buy this in.

Yves:

Exactly. And then we turned it into our own platform with our own philosophy.

Madeleine:

So the phyHUB, you just mentioned it. phyHUB – “phy” from PHYTEC and “Hub” from hub.

Yves:

“Phy” from PHYTEC, exactly. And the “Hub” is basically – the name is meant to describe it a bit. It’s supposed to be an ecosystem for [probably: “PHYTEC customers”]. So it shouldn’t just be a plain update and device management system; it should also house all the services we offer for product maintenance. That means all the results from these services, for example new software releases and the CVE monitoring.

And the CVE monitoring that we already prepare CRA-compliant for the customer for our core operating system should be visible there too. So that the customer can see the vulnerability for their product and, at the same time, what new software versions PHYTEC has already created that might fix the problem currently present in the field because of the version installed there. So it becomes a kind of management system that gives you a very good overview of what’s available and what problems I have.

Madeleine:

That makes sense. Have you ever done a kind of return-on-investment calculation? Because I can imagine there are many people out there who are still considering whether to build it themselves, or who may already be working on it. Can you say how many person-years have gone into this platform? Sorry, a slightly provocative question – I don’t know if you can answer it. And maybe also say how much time a manufacturer would realistically need to build something comparable in-house? Do you have any information on that? Yes, go ahead.

Marvin:

Maybe one more aspect first, to add to what Yves just said. Another point – and I think this applies to your listeners too – is vendor lock-in. If a company like PHYTEC, for example – this was part of our thinking – comes onto the market with an IoT solution or device lifecycle management, customers may not accept it, because they’re afraid of being tied to one supplier. We had exactly the same experience with our customer, by the way. The customers where we first deployed the system, Knorr-Bremse, for example, as one of our customers – they also had these concerns about vendor lock-in, and so do lots and lots of industrial customers.

Madeleine:

Vendor lock-in would mean that the device is set up for one platform, so to speak – keys, certificates. Exactly.

Marvin:

Yes, exactly. That there’s this dependency on a provider and you may not be able to get your device out of it so easily. And it was important to us to address that a bit. That’s why the customer can grow with phyHUB at PHYTEC, for example. That means they can start with the phyHUB offering, take software maintenance there, and also use the platform as a SaaS solution, but later they can move on to hosting it themselves to reduce that dependency. So we also make the product available as a software solution.

Yves:

It’s basically the same with our services. You can add the option of having us maintain your software – the entire operating system right up to the application layer. But at some point, once you’ve built up resources, you can also decide to take that over yourself. And I think that brings us back to the start of your question: return on investment and the effort for a platform like this. Marvin, maybe you can say in a moment what developing the whole system as a base system involved.

I can only say from our side: if you want to maintain an IoT device with a Linux, Yocto-based operating system, you need a lot of infrastructure. You need CVE monitoring and CVE management in some form. The software has to be scanned first. There are public databases that list and describe all the vulnerabilities that have been made public.

And then you need a toolset that scans your own configuration in a meaningful way. There are simple tools that just scan everything. They see: you have Linux version XY, okay, then I’ll give you all the CVEs. But they don’t take into account, for example, that I haven’t compiled certain libraries or drivers into my Linux at all and don’t even have them in my kernel config. And then suddenly I get millions of CVEs spat out that aren’t relevant to me at all. I have to pick them all out.

That means I first need a toolset – and that was our experience, as you say, the learning. Our experience was: wow, okay, I first need a toolset to do this scanning properly so I’m not overwhelmed by unnecessary information. And AI also generates a huge amount of information, some of which is too much. So the toolset is very relevant. We easily put two or three person-years into this CVE monitoring toolset alone, and then software maintenance comes on top.

If we do software maintenance for a customer individually, or for our standard products as core software maintenance, you need a test infrastructure where you build nightly builds and keep testing them. Creating all the test routines so that they really test meaningfully is anything but easy. You have to evaluate the results. You have to pull the patches every night. Then there are conflicts between the update patches and some vendor patches that are also present.

Once you have the infrastructure, you easily need one or two software developers who are really deep into Linux, who can continuously handle and resolve this BSP maintenance and all these conflicts, and who can also assess the CVEs and say: okay, this is critical for my product or it isn’t.

Madeleine:

Yes, exactly, and it doesn’t stop there, because you also have to make it available to the customer, and there’s also asset management and a rights and roles system that need to be developed, I imagine.

Yves:

Well, [probably: “L-IoT”] can do that.

Marvin:

Exactly, [probably: “you’ve just mentioned it”]. That’s where the complexity comes in, because ultimately it’s not just about the device that has to be managed – the devices are also tied to physical assets. That means you have to map the asset side. There are hierarchy levels and attributes to manage. Possibly relatively complex role and permission management – as you rightly pointed out – because you may want to carry out actions on individual devices or restrict things so that actions can only be carried out on individual devices.

And another complex topic – one that customers often underestimate – is ownership transfer. So who actually owns the device, who owns the physical asset, how can owners be changed, and what happens to the historical data that already exists?

Madeleine:

Can you briefly explain again what ownership transfer means?

Marvin:

It’s simply that over the course of its lifecycle, for example, a device can change owners step by step. It might first be produced, prepared in production, and have the manufacturer as its owner at that point, so to speak, then be handed over to a supplier and then perhaps to an end customer. So it may change owners several times during delivery, depending on how long the supply chain is or what the customer constellations look like.

Madeleine:

So in the end to a ticket machine manufacturer, so to speak, and there are also intermediate stages, for example.

Marvin:

Absolutely. There may also be an owner – in lots of scenarios, the owner of the ticket machine, for example, may be different from the actual operator. That means we’re in a scenario where there are two different parties who each have an interest in or responsibility for the device, the ticket machine. And taking these logics, these dependencies into account is one of the complexities involved.

Yves:

I have another nice example of that. We have a customer, for example, who makes emergency lighting for public buildings and the like. These are also connected systems – the lighting systems for escape route lights and so on are all connected. We call it the caretaker update. As the manufacturer of these lighting systems, you don’t want to just run an update, because you don’t know what the situation is on-site. Is it critical right now? Or with medical devices, you don’t want to just run an update while an operation is in progress.

And in this case, the caretaker basically needs certain minimum rights. The update is offered to him, and he’s the one who presses the button on-site and says: right, update now, because now it’s okay. The doors are locked, no one’s there anymore. The situation is safe. Now I can run this update, during which the system may be unavailable for a short time. And these are also individual implementations that at some point – L-IoT has already developed solutions that can now be offered as standard, but they always have to be adapted a little.

Madeleine:

Well, okay. The effort is just insane, and it sounds incredibly complex. If I wanted to do something like that myself, it’s, as you say, a few person-years, I’d say. Did you still dig into that a bit further? Sorry if I keep pressing the point. A return-on-investment calculation for the customer or – I don’t know, Marvin, whether you have anything on the setup, person-days per year, cost rates, whatever? Have you ever done the math?

Marvin:

I can perhaps talk about our own effort for product development and outline it a bit. We actually developed L-IoT, the product, over several years – four or five years – in various stages. First lots of individual modules – as I explained at the beginning – trying to standardize a lot through the projects and feed that into modules. And then intensively [inaudible] three years of product development, really casting it into a product and making it available as a solution, so to speak. So that’s a considerable investment on our part.

Madeleine:

Impressive. Okay. And you also have a wide range of customers. By the way, if you haven’t subscribed to the podcast yet, please do, because there’s an episode with Knorr-Bremse coming soon. They’re also part of our network. That’s actually a great segue, since it came up – they’re your customer too. And if you’re interested in exchanging ideas: we always have two sessions once a month, a tech session, for example. And that’s purely an exchange among users. So feel free to join.

By the way, I’d like to invite you too, if you’d like. All the technical leads from the various projects take part, people who deal with exactly this and exchange ideas. Just join, I’ll put it in the show notes. Because this is a huge topic, and I think everyone faces the same challenges. And talking about how it was solved – a warm invitation to all of you, feel free to join. It takes place once a month. I’ll put it in the show notes.

Right, but now briefly back to the solution part. You – or Yves, you said you decided on ML!PA precisely because the asset management was already there and everything you’ve just talked about was already solved. What’s the result now? Earlier you also talked about things becoming visible to the user, visually somehow. So what does your customer see now, and what’s the end result you’ve built here?

Yves:

Basically, the interfaces on this device management platform, L-IoT, are very open – there’s an [probably: “API”]. And together with ML!PA, we’ve also built in a CVE monitoring interface. It’s based on Dependency-Track. With it we can basically see and monitor the CVEs. And these scans come from us. You can also scan yourself if you want and then visualize it.

Basically, all that needs to be generated is an SBOM, or a VEX file that contains the information about CVEs, and with the VEX file also the triage process, meaning the decision on how I’ve solved the problem or how I want to solve it. This information then flows into the platform and is linked to the software versions I have available and to the product information.

What we’ve done is this: we produce in-house, and in production – we have a secure area where we can also install certificates and keys or activate encryption for secure communication. And there we can optionally activate phyHUB in the product already. When the customer boots up the product for the first time, it pops up as a visible device in their phyHUB instance, and then they can [probably: “start”] managing it.

Typically, they first do a baseline update, because you don’t know what software state it was shipped with. There’s usually a newer one already. Then you take it into the field, and you can monitor it there, and everything’s already set up. And as I said, you can also manage the CVEs yourself. And the advantage, because the system is so open, is this: if the customer already has a ticketing system, for example, and says: okay, I can see CVEs here in the platform, and now I want to give this to my team as a task so it gets fixed or a solution is found – then I can connect a ticketing system that already exists in the company, automatically generate tickets from it and also see whether they’ve been completed or not.

So it’s very flexible. You can take the solution from us, but you can also, if you already have infrastructure – build infrastructure for generating BSPs and compiling the operating system is usually, or often, available in-house too. Then, instead of taking the images from us, you can basically bring your own images into the platform. That’s the basic idea: to be as flexible as possible while still providing an overview and everything you actually need to manage devices.

Madeleine:

Very nice. So you’ve also made it possible to quickly see these relationships and the various possible solutions, because you mentioned earlier that – if you don’t do it this way – you get a lot of unnecessary information, it’s very complex, ownership transfer has to be solved and so on. So you now have all of that in one product, so to speak. You used L-IoT as a white-label product, which means your customers use phyHUB, and that’s how you’ve mapped this complexity in the product. It’s all in one, so to speak.

Yves:

Yes, it’s basically designed even more broadly. Not just as an update and device management platform, but covering the entire process from generating the software through to monitoring. It’s basically the complete management of a device, which has now evolved together with ML!PA. We came at it from practice and said: here, [probably: “this is a”] great basis. But for our products, so that it can be solved holistically, a few more features. And we’ve now implemented them together, making L-IoT, or phyHUB, even more comprehensive.

Madeleine:

So if you’re a manufacturer and you’re interested, definitely check it out. I’ll put it in the show notes. And if you’re – let me correct myself – if you’re a PHYTEC customer, there’s also the new solution, phyHUB. Check that out too; I’ll put it in the show notes as well. You can simply take a look. And I assume you’re open to conversations too. Or if someone has questions or simply says: hey, I’d just like to talk about how you did it – I assume you’re available for that.

Yves:

Yes, we do that anyway. It usually brings a lot, even if no business relationship comes out of it. As a product manager, I always like to hear what others are doing, and then you can exchange ideas. It’s more like that, and it still benefits both sides. So there’s no need to be shy. You can simply get in touch, and we’ll talk about the problems people have in this area.

Madeleine:

Okay, then I’ll put contacts in the show notes too, and as I said, if you’re interested: our user circle meets once a month, feel free to join. And we can continue the exchange there. Now, to wrap up today, let’s come to the learnings. Do you have any operational learnings or pitfalls you can share? Anything where you’d say: we’d do that again right away, or we’d never do it that way again? Or is there anything in the project that might be an early warning sign, where you’d say: hey, watch out!

Marvin:

In general, I think you can say that people really underestimate the effort. Yves can perhaps speak to that from his side or their side too. It’s really true that, first of all, you learn a great deal in the field. So that’s perhaps a learning I’d pass on, which Yves also just mentioned: test in the field early, talk to customers and partners early. And with PHYTEC we really have a good partner from whom we learn a lot and with whom we can further develop our solution on the points we’ve discussed.

Test a lot in the field, because you simply learn a lot about what the solution ultimately needs to do and what challenges there are, and then try to implement them quickly or take them on board and feed them into the implementation. You can develop a lot in theory, but in practice – generally speaking, I have to say – in practice you still run into lots of edge cases that you don’t even consider at the beginning.

Yves:

I’d agree with that. We also initially thought about doing and implementing it ourselves, and at some point, even at the theoretical level, we realized: okay, this is getting really complex. I think people underestimate it. The devil is in the details. And what was a learning for us – or for me personally when getting into this topic at all – is that you have to be flexible, that you can’t create a take-it-or-leave-it solution and think everyone will be fine with it.

The problems are too individual for that, especially in the embedded space. I mean, embedded thrives on being flexible, on being individual, on not being off the shelf. Otherwise I’d take an industrial PC, it’s ready to go, and that’s it. Instead, I have devices with very, very specific use cases and very specific interfaces. And the business logic and applications behind them are just as diverse. That’s why you need this flexibility.

And an important learning on our side was also that you have to make sure there’s no vendor lock-in. That customers still have the freedom, including the freedom to develop further themselves and say: no, right now, initially, with the CRA, it’s all overwhelming me. I don’t have the capacity to maintain software like crazy. So I’ll take PHYTEC for now to help me, and later I might build up the resources and say: okay, now I’ll stop using PHYTEC’s software maintenance service, but I’ll keep using the platform I chose back then, which also works well. I think you need this flexibility – or the ability to host the platform yourself and be independent.

Madeleine:

Well, is there anything you’d say you’d definitely never do that way again?

Yves:

What’s important to us – and we clarified this in our collaboration with ML!PA – is that we also have the rights to the system. That gives us a certain security for our customers: we can guarantee that the phyHUB platform will last and is backed by PHYTEC. That was very important to us. We’ve learned in the past how important that is, because this market can be difficult. You have to make sure you have a stable solution that won’t just disappear on you. Foundries.io, for example, was bought by Qualcomm, and just like that, the topic was over. Many people who were using Foundries.io are now left empty-handed.

Madeleine:

And that seems to be important for your customers too, who also want to use it independently, as you said earlier. So that matters as well.

Marvin:

Absolutely. That’s definitely also a very early learning, which we noticed early on in our collaboration with Knorr, among others. But really with every customer you talk to: they really don’t want to put themselves in that kind of dependency. Especially because of the point I made at the beginning: the assets live for 10 to 15 years. You may not be able to get to them that easily, or only at considerable cost if someone really has to drive out on-site to manually move the devices to another platform or install the software, new software. That’s why this issue of dependency is highly relevant for practically all customers.

Madeleine:

Very nice. As a final point for today, I’d be interested to know: where do you see the platform in the future? If we look into the crystal ball five years ahead: where do you think the platform will be, what’s still to come? How do you see the market? Do you have any thoughts on what’s coming your way in the future?

Marvin:

Ultimately, the biggest driver right now is clearly the Cyber Resilience Act. That means what’s currently driving customers is being able to manage devices throughout their entire lifecycle in order to install security updates and so on. The innovation aspect – retrospectively installing new functions on the devices via software – isn’t yet the really big topic from what we’re seeing.

But I believe – or we believe – that will change in the coming years, if you’re talking about five years, it will change over the next five years. That means it will become an important aspect that everything is increasingly software-controlled and that people want to unlock or transfer new functions retrospectively. Also with so much happening in AI: I think we’ll also see more local AI applications on devices in the future. Robotics, of course, but also other applications.

And then it becomes even more important to monitor the devices and to be able to control adjustments to detection, to the model, via software. And where we as a company want to support with L-IoT is compliance on the one hand, but innovation capability and scaling on the other. So over the next five years we also see a shift from very limited IoT applications – say, a prototype in a production hall – to a rollout across the entire operation. Simply to be able to produce faster, to become more efficient and to stay efficient.

Yves:

I believe that with the further development of AI, and especially AI on the edge, data transfer will be reduced significantly. I’ll be doing less AI in the cloud and more on the edge. But that naturally makes edge devices more relevant. And to keep edge devices up to date, models have to be swapped and software updates carried out.

Because of AI, the half-life of software versions has become even shorter, on top of the CRA and its requirements. Development cycles are so much faster. I can generate so much more new code and improvements. You can see how dramatically AI capabilities and large language models have grown from one year to the next. And of course that will increasingly affect edge devices too.

On the hardware side as well – we’re seeing this with our processors now – there are already AI IPs built in everywhere that can run models with acceleration, and things like that. Or additional chips attached externally that already deliver real performance. And they basically have to keep being fed with the latest models and optimizations. In this embedded hardware, you’re always limited in terms of resources, which is why you’re always trying to optimize.

And I believe the progress will simply bring an enormous amount. But that brings us back to the point: ultimately, I always have to stay in contact with my edge device and constantly communicate with it and update it in order to keep my products competitive.

Madeleine:

All the better that you’ve now created a scalable solution for the future that you can build on. Especially when you think about scaling and, as you just said, the new requirements that may still come in the future. Extremely interesting. I’d like to close the session for today. Thank you, Yves, for your time and for being here, and Marvin for your time too, and for presenting your project. I found it really interesting. We talked very concretely about customer requirements, the Cyber Resilience Act and the technical solution – I found that really exciting. And your learnings at the end, too.

And on the topic of AIoT, or the new buzzword, AI, I won’t go any deeper now. Maybe we’ll do another episode, I don’t know, an update in a few years or so. We’ll see. I’d find that interesting. I really enjoyed it today. If you want to learn more about AI: I did an episode on it, number [probably: “224”]. I spoke with the CPO of one of our partners, with Jürgen. They have a kind of data harmonization solution for asset management, or they’re building it now. And it was about what the AI agents need for mapping, so that new devices can also be connected to an asset management system like that. If you’re interested, give it a listen. But I’d now like to hand the last word over to you. Thank you very much for being with us today.

Yves:

Thank you too. And you did it very professionally. And the last episode, 224, that you just mentioned – it sounded as if you knew that off the top of your head. That’s really impressive.

Madeleine:

I cheated, I have to admit. I have our website, iotusecase.com, open right now and I’m on the podcast page and just had a look because it occurred to me. When you said that, I quickly checked. But I do know a lot of it by heart.

Yves:

Well, it’s great anyway – [probably: “you”] guided us through the interview really well, and I think what came out of it is great. And I think it gives listeners a rough picture, partly even in detail, of the challenges you face when you connect devices and want to make the whole thing CRA-compliant. I really enjoyed it, and I’d definitely like to do it again, especially on [probably: “AI on the edge”] – we’d have quite a bit to say about that too. We have a team working on it as well. We could definitely do that. Otherwise, thank you for listening, and Madeleine, thank you for guiding us so well.

Marvin:

Absolutely, I can only agree. Thank you very much, Madeleine. Well moderated, and I really enjoyed it too. I always think it’s good – the partnership with PHYTEC, which we’re now starting – that we were able to exchange ideas like this and present it together. We really enjoy working together. And I’m definitely looking forward to future discussions.

Madeleine:

Very nice. Take care, and with that I’d say: have a great rest of the week. Bye.

Yves:

Thanks, bye.