Protecting Digital Products – Security Best Practices from XITASO

Today’s digital services – such as customer portals or IoT platforms – often come with potential security vulnerabilities. This doesn’t just affect your IT infrastructure, but also the trust your customers place in you – and ultimately, your entire business model.


To discuss this, I’ve invited Michael Buchenberg, Head of IT Security at XITASO. His team supports industrial companies in developing secure and future-ready digital products on a daily basis.


Since the topic of security often feels quite theoretical, today we’re taking a concrete look at real-world practice—using a project by DMG MORI with their CELOS X platform as an example.
We’ll cover how DMG MORI conducts penetration tests, what exactly is tested, and the role of concepts like DevSecOps. Plus, Michael shares practical best practices you can apply directly in your own operations.


As always, you can find all the details about the episode in the show notes or at www.iotusecase.com. 
Let’s go!

Hi Michael – great to have you here today. Welcome to the IoT Use Case Podcast! How are you? How are you doing?

Michael

Hi, thank you for having me! I’m doing great and looking forward to our conversation.

Perfect. Let’s start with your company, XITASO – where are you based?

Michael

We’re a German family-owned company headquartered in Augsburg, near Munich. We have 15 locations across Germany and one in Spain. I’m speaking to you today from sunny Augsburg.

Perfect. Today, we want to talk about the industrial sector and make the topic of security more tangible. Could you share what’s currently keeping you and your clients busy? It’s often about building future-ready IoT products around machines and industrial equipment. What recurring security topics are you seeing in your work?

Michael

Absolutely. It’s not just about security in the narrow sense – digitalization around machines is advancing steadily. At XITASO, we’re convinced that it’s essential to solving the challenges of today. At the same time, we place a strong emphasis on doing this securely.


We’re no longer just placing a machine on the shop floor that runs for the next 20 years. Connectivity is increasing, and software is becoming more important – for example, in the form of digital services that offer exciting features and added value for end customers.


At the same time, this creates new attack surfaces that didn’t exist in this form before. Especially in the IoT space, where connectivity and networking are key, there are plenty of opportunities – but also critical security considerations that we need to take seriously.

Exactly. You just mentioned that there are attack surfaces today that didn’t exist 15 years ago. Let’s walk through a practical example. You work with a wide range of clients – can you briefly explain which project we’ll be looking at today and what you did there specifically?

Michael

Gladly. As you already mentioned, most of our clients are from the mechanical and plant engineering sectors. But we also work with customers in the MedTech field. Often, our focus is on services or digital solutions related to products and machinery.


These days, we’re no longer just talking about physical products like a piece of sheet metal, but about networked systems with digital components – and security has to be a part of that conversation.

Cool. And today’s example is from DMG MORI, right?

Michael

Exactly. We’re talking about a project we did with DMG MORI. Many know them as a leading manufacturer of milling machines of all sizes. They’re expanding their digital portfolio around these machines by offering additional services – for example, to simplify setup processes or improve efficiency.


These digital services and tools are partly embedded in the machine and partly cloud-based – and of course, they need to be secure.


In this case, we were tasked with assessing the security of their platform called CELOS X. It’s a central hub for digital applications that create added value for users.
We performed a snapshot analysis: the product was already developed, software was running, various components were integrated, and there were cloud connections involved.


Our job was to answer the question: how secure is the system? In such a case, a penetration test is the go-to method – a targeted, simulated attack to identify vulnerabilities.

For context, if you’re listening: many of you probably know DMG MORI. As Michael said, they’re a global leader in high-precision machine tools – operating in 43 countries, with 116 sales and service locations, and 17 production plants.
CELOS X is a fascinating platform – I’ll link it in the show notes. I’ve known it for a while now. It supports a wide range of applications, like monitoring vibrations during machining.


It’s also about protecting the spindle and the machine from damage, overloads, or collisions. There are various use cases being implemented with it. If you’re curious, go check it out – it’s really impressive what DMG MORI is doing here.


Now, back to your project: you performed a so-called penetration test. Can you explain what that actually means? As I understand it, it’s basically a simulated hacker attack – is that accurate? What exactly did you do?

Michael

Yes, that’s actually a pretty good description. It’s about simulating an attack with good intentions. The advantage is that it’s very realistic – it reflects exactly how a real attacker would proceed.


Before we begin, we hold detailed preliminary discussions. We clearly define what will be tested and what won’t, what the goals are – and we make sure not to touch any components that should remain untouched, and that no damage will occur.


In this specific case, we spent about a week on-site at DMG MORI, sitting directly at the machine and testing across different attack vectors.
Typically, machines today are integrated into the shop floor and connected to the network. A classic attack scenario would be: an attacker first infects another system on the shop floor and then launches an attack on the machine from there.


Our task was to evaluate: how secure is the product, the system, or the machine against exactly these kinds of internal attacks?

So if I understood correctly, one of your goals was to identify potential entry points for attackers, right?


Did you also look at specific types of data? What were the main three or four targets you analyzed?

Michael

Exactly. One major focus is the data processed on such machines. This often includes live and production data collected through monitoring processes, which may be further processed and even transferred to the cloud.


These data sets contain valuable know-how – especially in Europe and particularly in Germany, where many hidden champions operate. We’re talking about critical process knowledge like temperatures, mixing ratios, or production workflows. That kind of intellectual property has high value and needs protection.
A second focus is protection from sabotage. If an attacker is able to shut down or manipulate a machine in a way that causes damage, it could result in downtime, costs, and delivery delays.


That has far-reaching consequences – and that’s exactly what our clients want to avoid.

Got it – so on one hand, you’re looking at where attackers could theoretically break in, and on the other hand, what kinds of data could be at risk.


In the IoT context, that’s typically data read from the controller via something like OPC UA, right?


So you probably analyze different parameters – and have the right experts on board?

Michael

Exactly, that’s a good example. Today’s systems typically have multiple interfaces – like OPC UA, MQTT, or HTTP. These interfaces need to be examined closely: how secure are they? What protection mechanisms are in place to ensure secure communication? And do those mechanisms actually work as intended?


That’s exactly what you can test in a practical hands-on test – and by the end, you have a pretty solid understanding of where your product currently stands in terms of security.

Yes, great. Many companies already operate some form of vulnerability management – some have their own IT departments, maybe even dedicated security experts, while others don’t.


What’s your experience: How do companies generally approach this topic when you’re not yet involved in the project?

Michael

That’s actually a really interesting question. We often see that IT security is considered for internal IT systems – like SharePoint or similar platforms.


But when it comes to products that are delivered to the customer, we often find that security isn’t taken into account to the same extent.


This makes it all the more important to factor it in – especially in light of new regulatory requirements like the Cyber Resilience Act or the EU’s NIS-2 directive, which now oblige companies to act and are pushing security further into focus.

[10:55] Challenges, potentials and status quo – This is what the use case looks like in practice

You mentioned that this is about digital products delivered to customers. Can you give an example of the new challenges that arise from this?


I’m thinking: new machines are out in the field, data is pulled from the control systems – through cloud platforms, whether on-prem or public cloud. What are typical issues in the IoT context?


Maybe it’s getting a bit nerdy, but I assume there’s also a lot of legacy code or old PLC programming still in use. Can you share an example?

Michael

We often see that machines have been developed or manufactured over many years – and they carry a lot of legacy code.

Especially with PLC programs, we frequently find code snippets that have been copied and reused for 15 or 20 years – from a time when IT security wasn’t really on the radar.


Back then, machines operated in isolation, without any external connectivity.

Now we’re integrating them into networks, extracting data and pushing it into the cloud. And that brings entirely new challenges.
Today, we have to think much more holistically: It’s no longer just about one machine – it’s about a complex interplay between machines, edge devices, multiple servers, databases, services, dashboards, and interfaces.


With the best of intentions and huge potential. We absolutely support that and work closely with our clients on it.


But: It also has to be secured. As soon as data isn’t just stored locally on the machine but is processed in the cloud or networked systems, new attack surfaces emerge. And those need to be understood and protected.

You just mentioned the Cyber Resilience Act.


As far as I know, it’s a new EU regulation aimed at ensuring that connected products – both software and hardware in the industrial environment – can be operated securely.


Manufacturers must provide proof that their products meet fundamental security requirements.


From your perspective, what are best practices when dealing with the Cyber Resilience Act?


Do you see it more as a regulatory requirement or as a real driver?


And how does it impact your work with clients?

Michael

The Cyber Resilience Act is definitely a driver.


In recent years, the EU issued many recommendations, but they were often not implemented in practice. Now, it’s taking a more concrete step with a binding regulation to build a secure digital infrastructure across Europe.


Especially in the context of IoT and Industrial IoT, the Act affects a wide range of products – simply because the level of connectivity is so high.


It sets out basic security requirements that must be met. On one hand, a product must be secure before it’s delivered to the customer. On the other, processes like vulnerability management are now mandatory.


This is an area many companies have not yet seriously addressed – especially in mechanical and plant engineering.
In the past, a machine was built mechanically and electrically, delivered, commissioned – and that was it.


Now, the Cyber Resilience Act demands that manufacturers take responsibility beyond delivery:
If a critical security vulnerability is discovered, the manufacturer must act and provide updates.


This calls for a completely new understanding of responsibility throughout the entire product lifecycle.

Yes, absolutely. I can imagine that, especially with IoT platforms or customer portals, topics like access control and handling sensitive data are a major concern. I assume there are also many fears on the customer side. Do you see that too?

Michael

Yes, definitely. Concerns and fears come up frequently – especially when highly sensitive and confidential data is involved, such as production know-how that’s being pushed to the cloud.


These concerns are totally valid. We see it as our responsibility to support and advise our clients on how to implement this securely.


Taking the step into the digital world with new services is important – but it has to be done in a way that you can confidently stand behind, even toward your own customers.

[16:08] Solutions, offerings and services – A look at the technologies used

Can you share a few best practices for how to properly conduct penetration tests? What does a test like this actually look like in practice? How do you typically work with your clients?

Michael

When it comes to penetration testing, the first thing is to clearly define the scope: What will be tested – and what won’t?
This is also important from a legal perspective. It must be crystal clear what’s part of the test.
Our experts use specialized tools and systematically work their way into the system. They check interfaces, look for known vulnerabilities, and analyze how different components interact.


What makes penetration testing so exciting is that it’s not just about technology – it also requires creativity. For example: What combination of factors could lead to unexpected outcomes?
Step by step, we assess whether we can gain access to the system and analyze: What data is available? Are there connections to other systems? Could we manipulate something or shut the system down?


In the end, there’s a comprehensive report with all our findings, including concrete recommendations and actions.


That’s particularly important to us: We don’t just want to point out vulnerabilities – we want to help our clients secure their systems sustainably.


To do that, we have targeted discussions with project managers, software architects, and development teams.

We clarify why a solution looks the way it does today, which measures are realistic – and how we can jointly create more resilient systems.

Interesting. So, the result for your customers is usually a security report? Or what does the final result of such a project look like?

Michael

Exactly – the final outcome is usually a very detailed report. It outlines exactly what was tested, what findings we uncovered, and what recommendations or actions we derived.


It typically includes an appendix with additional information – for example, how we conducted the tests, how to reproduce them, and what next steps the client can take to continuously improve their system’s security.

Got it. There’s a term we hear more and more often – “DevSecOps”, short for Development, Security, and Operations. What does that mean in your context? And should manufacturers be paying more attention to it? And what exactly is behind it?

Michael

Absolutely – in my opinion, that’s the next logical step.


We’ve now talked in detail about penetration testing. It’s definitely a very effective approach when you already have a finished product and want to evaluate how secure it is. You get a report and can build from there.


But it would be even better to identify potential security issues earlier – during the development phase.


That’s exactly what DevSecOps is about. It builds on the DevOps approach, which many already know: the close integration of development and operations to bring products to market faster and more smoothly – often with pipelines.

DevSecOps takes it a step further by integrating security directly into this process.

The goal is to build security into development from the very beginning – so that the final product can also be operated securely.
This means, for example, asking early on: Where do my security requirements actually come from?


If I’m developing a product – do I even know what threats it might be exposed to?


A very useful tool for this is a threat analysis:


What risks are we dealing with specifically? What attack vectors need to be considered?


From this, measures can be derived – like the requirement to encrypt data transmitted through certain interfaces.

And once I know that, I can implement it properly in the design and development process.

Okay, so ideally, as a machine builder, I’d involve your team – or other internal experts – early on.

Even before the IoT platform is fully built, I should take a close look at which components are in the field, whether outdated systems are still in use, and where potential security vulnerabilities could arise.


Would you say that’s accurate?

Michael

Absolutely. Ideally, I don’t just identify vulnerabilities – I prevent them from happening in the first place.

And do you help with that directly? Does that include, for example, code reviews where you sit down with teams and say: “You should take another look here – there is a potential vulnerability”? What does that look like in practice?

Michael

That’s one of the measures we use. During development, teams can review each other’s code, or we conduct a security review of the system architecture.


That way, we can identify blind spots or security-relevant issues that might otherwise go unnoticed.


The earlier such points are identified, the easier – and more cost-effective – it is to address them.


It’s much more efficient than discovering security flaws later during operation.

[22:02] Transferability, scaling and next steps – Here’s how you can use this use case

You’ve already worked on many projects and have a long list of reference customers.


Have you developed something like a knowledge base over time, where you know exactly what to watch out for?


Gerade im IoT-Kontext – ihr arbeitet ja mit Plattformen wie Azure, Bosch crtlX, AWS, STACKIT und vielen mehr. Does a clearer picture start to emerge over time?

Michael

Exactly – our colleagues deliberately build expertise in each of those technologies.

It’s a bit like the principle of “know your tools” – if I know exactly what I’m working with, I can use it properly. That helps a lot.


At the same time, we also work on highly customized solutions, which are often very unique.


Each time, we have to take a fresh look: Which systems are we communicating with?


Where is the data stored?

How do we ensure security?


Of course, we also rely on proven best practices.

I think it’s important to point this out again:


Even though this project strongly connects you with security expertise – your scope is actually much broader.


You offer services and develop custom software solutions – and security is just one part of your portfolio.

Michael

Exactly. We see ourselves as a digitalization partner – especially for the mechanical and plant engineering industry, but also for the MedTech sector.


Our goal is to implement digitalization together with our customers in a meaningful and secure way.


That includes software engineering, consulting, the development of digital twins – in short: a wide range of digital solutions.

Perfect!
If you’re interested: I’ll include Michael’s contact details in the show notes – and feel free to check out xitaso.com. You’ll find plenty of exciting projects and success stories with customers and partners – and security is just one part of their broader work.
One final question, which I find particularly interesting:


You’re also working closely with research institutions.


Are you currently looking for new partners? And if someone is listening – for example, a machine builder or component manufacturer – do you work in partnership with them too?

How does that collaboration typically look?

Michael

Yes, we have a very large research network – within our company alone, 25 people work exclusively in the field of research.


We’re active in various networks and collaborate closely with partners and customers – because we want our research to be grounded in real-world applications.


It gets particularly exciting when we can bring in specific use cases and real applications.


Right now, for example, we’re working on post-quantum secure algorithms in the field of security – a super exciting area.

Post-quantum…? I need to Google that real quick. What exactly is that about?

Michael

Basically, once quantum computers become practically usable, they will have a massive impact on today’s encryption standards and security mechanisms.


That’s why we’re already researching which algorithms will be secure enough in the future – and how we can integrate them into existing digital ecosystems, software solutions, and platforms.


It’s definitely a high-potential topic for the future.

And would you say that’s still a long way off, or is it already happening?

Michael

I think we’re still at the beginning – but it will become a very real issue in the next five to ten years.


That’s exactly why we’re already investing time into it today.

Which is probably also why you’re involved in research projects – with partners like Fraunhofer and others – to explore what’s coming in the future. Really exciting!


I’ll link that in the show notes. Maybe some of our listeners are interested in connecting with you.


Michael, thank you so much for your time today!

I found it incredibly insightful – especially the DMG MORI example helped to make this topic very tangible.


If you’re thinking, “This topic is relevant for me too – I’d love to connect or learn how to approach this as a machine builder,” then don’t hesitate to reach out to Michael.


Thanks again for being here! Maybe we’ll do another episode soon about some of the other exciting projects you’re working on.


I’ll give you the final word.

Michael

Thank you for having me!



Security is a fundamental building block for us – and a real enabler for digitalization.


If you have questions or want to exchange ideas, feel free to reach out. I’m always happy to connect and hear your feedback.

Take care and have a great week. Bye!

Michael

Thanks, same to you!