Planning service robots in a hospital, a utility, or another regulated facility? Then you are not just choosing a robot. You are adding an IT system to an environment with elevated security and reporting duties. KRITIS and NIS-2 do not demand a specific robot brand. They demand that you know where data lives, who has access, and how you respond when something goes wrong.
This shift is easy to miss. In procurement, the robot is what stands in the foreground: what can it carry, how reliably does it drive, what does it cost? From a regulatory perspective, though, the robot is only an endpoint. What matters is what sits behind it: the control software, the interfaces to doors and elevators, the data flows to vendor clouds, and the question of who carries responsibility when something fails. Thinking this through early avoids expensive retrofits later.
What KRITIS and NIS-2 are about
KRITIS regulation obliges operators of critical infrastructure to implement state-of-the-art security and to report significant incidents. The NIS-2 directive widens the set of affected entities and sets requirements for risk management, supply-chain security, incident reporting, and management accountability. The exact obligations depend on national transposition and on whether your facility falls within scope. That assessment is one to make with your security and legal owners.
For robot deployments the core is simple: a networked robot becomes part of your attack surface and your data processing. The same basic principles apply as for any other system in a regulated environment.
What stands out most is the broadened scope. NIS-2 covers considerably more entities than its predecessor, and it explicitly brings the supply chain into view. A robot operated or remotely maintained by an external service provider is precisely such a supply-chain component. Add to that the personal accountability of management: leadership can be held liable for failures in risk management. That lifts the question "how secure is this system, really?" out of the IT department and onto the board's agenda.
Which architecture decisions matter now
Four points decide, in practice, whether a robot project complicates your obligations or supports them:
- Data location and operating model. If control runs on-premise or even offline, operational data stays inside your environment. That reduces dependence on external services and simplifies the assessment of data flows.
- Access and traceability. Roles, permissions, and a traceable record of who triggered what are the basis for audits and incident handling.
- Network and segmentation. Robots, doors, and elevators should be connected in a controlled way, not flat into every network. A common integration layer makes those boundaries visible and governable.
- Vendor independence. If one supplier controls the whole chain, you inherit their risks and their reporting paths. A neutral layer between robots and your IT keeps control with you.
These four points are connected. Cloud-bound control not only complicates the assessment of data flows; it also shifts control over availability and updates to the vendor. A flat network connection makes commissioning easier but enlarges the attack surface and turns segmentation into expensive after-the-fact work. The sequence that is cheapest, both economically and in regulatory terms, is therefore almost always the same: settle the architecture first, then procure.
Common pitfalls in practice
In conversations with facilities, the same patterns recur. First, the silent cloud dependency: a robot works only as long as it stays connected to the vendor's cloud. Lose the connection, or have the vendor change its terms, and operation halts — a risk that weighs heavily in regulated environments. Second, missing logs: without a traceable record of who triggered which action, an incident is hard to reconstruct after the fact and therefore hard to report. Third, the blending of networks: robots that talk directly to clinical or operational core systems because it was simpler at commissioning. Such shortcuts come back to bite at the first audit.
None of these points is exotic. They are the robotics variant of requirements that have long been taken for granted in any other IT procurement. The difference: with robots the interfaces are physical — doors open, elevators move — and so the security question is at the same time a question of operational safety.
How Axiona helps
Axiona is the vendor-agnostic layer between robots and the outside world. It is built for encapsulated, auditable operation and can run on-premise or offline, depending on the operating model. You connect robots, doors, elevators, and third-party systems through adapters instead of hard-wiring them together. Access runs through roles and policies.
The adapter approach here is more than technical convenience. It makes the boundaries between systems explicit: every connection is named, controllable, and replaceable. A vendor can be swapped out without rebuilding the entire integration, and a single compromised device stays confined to its clearly defined area of effect. That visibility is exactly what you need to document data flows and contain incidents.
An important caveat: software does not make you KRITIS or NIS-2 compliant on its own. Compliance is an organizational process. Axiona is built to support that process rather than stand in its way, by keeping data location, access, and integration under your control. Responsibility for scope, reporting paths, and risk assessment stays with your organization — the architecture can ease that work, but it cannot replace it.
Evidence from real operation
The underlying technology emerged from the SMART FOREST 5G Clinics research project at Deggendorf Institute of Technology and has been in real operation since 2023 in two hospitals, the Arberlandklinik Viechtach and the Kliniken am Goldenen Steig in Freyung. There, service robots are coordinated with door and elevator integration, deployable on-premise. We have published the data-protection assessment of voice-controlled systems in hospitals together with researchers.
The difference between a demonstration and a dependable operation only shows over time. A system that has run in two houses in real clinical daily life since 2023 has met exactly the friction that pilot projects rarely surface: changing requirements, maintenance windows, exceptions in day-to-day work. That experience has fed back into the architecture — and it is the reason we are so consistent about keeping data location, access, and integration controllable.
Next step
If you are planning robotics in a regulated environment, the architecture view pays off before procurement. Talk to us about your project, or read more about our approach to sovereignty and security.