Dein Labor ist kein Rechenzentrum – und genau da liegt das Problem

Es war kein Hackerangriff. Keine Ransomware. Kein sophistizierter Zero-Day-Exploit. Es war ein IT-Mitarbeiter, der einen Rechner neu gestartet hat. Ganz normal. Nach Checkliste. Wie jeden Dienstag. Nur dass dieser Rechner keinen Excel-Report gesteuert hat, sondern einen Backofen in einem biotechnischen Unternehmen. Der musste danach über mehrere Tage kontrolliert heruntergefahren – und dann wieder hochgefahren werden. Schaden: mehrere hunderttausend Euro.

Diesen Fall hat mir Marc Porr im aktuellen ChaosHacker Talk erzählt, und er ist leider keine Ausnahme. Er ist das Symptom eines grundlegenden Denkfehlers, der sich durch die gesamte Labordigitalisierung zieht.

Das Labornetz ist kein Büronetz

Wenn IT-Abteilungen auf Laborumgebungen treffen, passiert meistens folgendes: Man sieht einen Rechner. Ein Rechner ist ein IT-Asset. IT-Assets werden nach IT-Policy behandelt. Updates, Reboots, zentrale Administration, Zwei-Faktor-Auth, 60-Zeichen-Passwort – alles korrekt. Alles nach ISO 27001.

Das Problem: Dieser Rechner ist kein Büro-PC. Er ist Teil einer Prozesssteuerung. Er ist das Nervensystem eines Laborgeräts, das vielleicht gerade einen mehrstündigen Fermentationslauf steuert, eine Zellkultur temperiert oder einen Hochleistungsspromatographen kalibriert.

„Wir werfen alte Geräte mit neuen Geräten zusammen, mit schlecht spezifizierten Schnittstellen, wenig Standards, irgendwelchen Cloud-Diensten – rühren kräftig durch und nennen das Digitalisierung.“— Marc Porr, ChaosHacker Talk

Die CIA-Triade – aber in umgekehrter Reihenfolge

In der IT-Security kennt jeder die CIA-Triade: Confidentiality (Vertraulichkeit), Integrity (Integrität) und Availability (Verfügbarkeit). In klassischen Unternehmens-IT-Umgebungen gilt die Priorität oft genau in dieser Reihenfolge: Erst die Daten schützen, dann deren Korrektheit sichern, und irgendwo dahinter kommt die Frage, ob das System läuft.

In der Operational Technology – also in allem, was physische Prozesse steuert – dreht sich diese Priorität um:

Was bedeutet das konkret? Ein IT-Admin, der nach Best Practice handelt und den Steuerrechner für einen Bioreaktor um 2:00 Uhr nachts in ein Update-Fenster packt, macht technisch gesehen nichts falsch. Er hat nur das falsche mentale Modell vom System, das er betreut.

💡 Was ist GxP?

GxP steht als Sammelbegriff für regulatorische Anforderungen in den Life Sciences: GMP (Good Manufacturing Practice), GLP (Good Laboratory Practice), GCP (Good Clinical Practice) u.a. Der entscheidende Punkt: Systeme, die in GxP-Umgebungen eingesetzt werden, müssen validiert sein – d.h. dokumentiert nachweisbar, dass sie das tun, was sie sollen. Das betrifft nicht nur die Software selbst, sondern auch die IT-Infrastruktur darunter.

Das Problem: GxP verlangt Datenintegrität und Nachvollziehbarkeit. IT-Security verlangt Härtung und Updates. Beides zusammen ist lösbar – aber nur, wenn man beide Welten kennt.

NIS2: Der Druck von außen kommt jetzt

Wer das Thema noch als „interne Laborphilosophie“ abgetan hat, wird durch die aktuelle Regulierungswelle aufgeweckt. Das NIS2-Umsetzungsgesetz ist seit Dezember 2025 in Deutschland in Kraft – ohne Übergangsfrist.

Was viele unterschätzen: Der Schwellenwert wurde drastisch abgesenkt. Bisher waren im Pharmabereich nur sehr große Unternehmen KRITIS-pflichtig. Jetzt greift die Regelung bereits ab 50 Mitarbeitenden oder 10 Millionen Euro Jahresumsatz. Das trifft den Mittelstand direkt. Und: NIS2 betrachtet ausdrücklich sowohl IT- als auch OT-Systeme – also auch die Steuerrechner im Labor.

Was NIS2 für Pharma- und Biotech-Labs bedeutet:

Hersteller pharmazeutischer Produkte und Betreiber von Laboren gelten unter NIS2 als „wichtige Einrichtungen“. Das bedeutet: verpflichtende Risikoanalysen, Meldepflichten bei Vorfällen – und persönliche Haftung der Geschäftsleitung. Ein Rechner-Reboot, der einen Prozess killt, ist dann nicht nur ein Produktionsausfall, sondern potenziell ein meldepflichtiger Sicherheitsvorfall.

Zwei Scheinlösungen, die nicht funktionieren

In der Praxis begegne ich immer wieder zwei Reflexreaktionen, wenn das Thema auf den Tisch kommt – und Marc Porr hat beide im Gespräch präzise seziert:

• 1„Der Geräteverantwortliche ist zuständig.“Klingt logisch: Der Laborant kennt sein Gerät. Aber der Geräteverantwortliche ist kein Fachinformatiker für Systemintegration. Er kann nicht gleichzeitig Netzwerksegmentierung verstehen, OT-Security-Konzepte umsetzen und wissen, wann ein Zertifikat abläuft. Das ist keine Kritik – es ist schlicht eine andere Aufgabe.
• 2„IT-Abteilung macht das.“Die IT-Abteilung behandelt den Steuerrechner wie jeden anderen PC. Weil sie keinen anderen Kontext hat. Der Laborant mit dem 250.000-Euro-Chromatographen darf dann keine Adminrechte haben – und parkt das Gerät, weil die Software ohne lokale Rechte nicht startet.

Die Lösung liegt weder beim einen noch beim anderen, sondern in einem dritten Profil, das Marc Porr in der Episode beschreibt: Menschen, die beide Sprachen sprechen. LabIT. OT-Engineers, die im Laborkontext denken können. Diese Profile existieren – in der Produktionsautomatisierung, in der Leittechnik, in kritischen Infrastrukturen. Sie sind nur bisher kaum ins Labor gelangt.

Was das Labor von der Energieversorgung lernen kann

Marc hat seinen Background nicht nur in Biotech-Laboren, sondern auch in echter kritischer Infrastruktur: Systeme, die dafür sorgen, dass Strom aus der Steckdose kommt, Wasser fließt, Gas geliefert wird. In dieser Welt sind die Probleme, über die wir im Labor gerade erst nachzudenken beginnen, seit Jahrzehnten Realität.

Netzwerksegmentierung? Standard. Trust Boundaries? Definiert. OT-spezifisches Sicherheitskonzept getrennt vom Corporate-IT-Netz? Selbstverständlich. Die Konzepte sind da. Das Wissen ist vorhanden. Es muss nur in die Laborwelt übertragen werden.

Genau dafür engagiert sich Marc u.a. im Board of Directors von SiLA (Standardization in Lab Automation) – einem Standardisierungsgremium, das versucht, OT-Konzepte in die Laborautomatisierung zu übersetzen. Weil das Rad nicht neu erfunden werden muss – es muss nur eingebaut werden.

„Das Labor hat einen Geburtsfehler: Es ist zu neu. Wir haben die Zeit versäumt, von anderen Disziplinen zu lernen – bevor wir alles durchdigitalisiert haben.“— Marc Porr, ChaosHacker Talk

Und dann ist da noch die Frage der Entscheidungen

Am Ende des Gesprächs haben wir einen Punkt berührt, der über das Technische hinausgeht. Marc brachte es auf den Punkt: Viele Organisationen sind so gut darin geworden, Entscheidungen durch Absicherungsschleifen zu ersetzen, dass am Ende keine echte Entscheidung mehr getroffen wird.

Eine Entscheidung beinhaltet per Definition Unsicherheit. Wer so lange analysiert, bis alle Risiken eliminiert sind, trifft keine Entscheidung mehr – er verzögert. Und im regulierten Labor, wo jede Änderung dokumentiert, validiert und auditiert werden muss, ist diese Lähmung besonders virulent.

Das Gegenmittel ist keine tollkühne Risikofreude. Es ist eine Fehlerkultur, die Entscheidungen unter Unsicherheit als normal begreift – und Systeme baut, die Fehler früh sichtbar machen, statt sie nachträglich vertuschen zu müssen.

Was bleibt

Labordigitalisierung ist kein IT-Projekt. Sie ist auch kein GxP-Projekt. Sie ist beides gleichzeitig – plus OT-Security, plus organisatorische Transformation, plus die Fähigkeit, unter Regulierungsdruck trotzdem Entscheidungen zu treffen.

Wer das mit Standard-IT-Denke angehen will, wird scheitern. Leise, teuer und am besten ohne Zeugen – wenn nicht gerade jemand zuschaut, wie ein Backofen nach einem Reboot kaltläuft.

Die Episode mit Marc Porr läuft gerade. Hört rein. Und dann fragt euch: Wer spricht in eurem Labor beide Sprachen?
https://youtu.be/2PdNo3EgmN4