IEC 62443-4-1 in der Praxis: vom dokumentierten Prozess zum belegbaren Nachweis
Acht Practices, vier Reifegrade — was IEC 62443-4-1 vom Gerätehersteller verlangt und warum ein dokumentierter Prozess im Audit noch kein Nachweis ist.
IEC 62443-4-1 ist die Norm, die am häufigsten zitiert und am seltensten belegt wird. Fast jeder Hersteller, der Feldgeräte in industrielle Anlagen liefert, hat ein Prozesshandbuch, das sich auf sie beruft. Deutlich weniger können im Audit zeigen, dass der beschriebene Prozess für ein konkretes Produkt auch tatsächlich stattgefunden hat.
Dieser Artikel ordnet ein, was die Norm verlangt, wie ihre Reifegrade zu lesen sind — und an welcher Stelle der Übergang vom Dokument zum Nachweis in der Praxis reißt.
Prozess, nicht Produkt
62443-4-1 beschreibt keine Eigenschaft eines Geräts. Sie beschreibt den Entwicklungsprozess, mit dem ein Hersteller Sicherheit systematisch erzeugt: wie Anforderungen entstehen, wie entworfen, implementiert, geprüft, freigegeben und über die Lebensdauer gepflegt wird.
Die technischen Eigenschaften des Geräts stehen in der Schwesternorm 62443-4-2 — dort, wo die sieben Foundational Requirements und die Security Levels leben. Beide Normen greifen ineinander: 4-1 sorgt dafür, dass die Anforderungen aus 4-2 nicht zufällig erfüllt werden, sondern reproduzierbar. Wer die beiden verwechselt, argumentiert im Audit an der Frage vorbei, die gerade gestellt wird. Wie sich die beiden Perspektiven konkret unterscheiden, zeigt der Artikel zur Reife-Lücke zwischen 4-1 und 4-2.
Die acht Practices
Die Norm gliedert den sicheren Entwicklungslebenszyklus in acht Practices. Sie sind die Struktur, an der jedes Assessment entlanggeht:
| # | Practice | Worum es geht |
|---|---|---|
| 1 | Security Management (SM) | Rollen, Kompetenzen, Prozessverankerung, Zulieferkomponenten |
| 2 | Specification of Security Requirements (SR) | Sicherheitsanforderungen inklusive Betriebsumgebung und Bedrohungsmodell |
| 3 | Secure by Design (SD) | Architektur, Defense in Depth, Designreviews |
| 4 | Secure Implementation (SI) | Sichere Codierrichtlinien, Implementierungsreviews |
| 5 | Security Verification & Validation Testing (SVV) | Funktionale Prüfung, Schwachstellen- und Penetrationstests |
| 6 | Management of Security-related Issues (DM) | Umgang mit gemeldeten und gefundenen Schwachstellen |
| 7 | Security Update Management (SUM) | Bereitstellung, Qualifizierung und Auslieferung von Updates |
| 8 | Security Guidelines (SG) | Dokumentation für sichere Integration, Betrieb, Außerbetriebnahme |
Die Reihenfolge ist keine Phasenfolge. SM, DM, SUM und SG laufen dauerhaft; SR, SD, SI und SVV hängen am jeweiligen Entwicklungsvorhaben. Diese Unterscheidung erklärt einen großen Teil der Befunde in der Praxis: Die produktbezogenen Practices sind meist ordentlich belegt, die dauerhaften verlieren nach dem Launch ihre Spur.
Vier Reifegrade — und was sie wirklich messen
Zu jeder Practice gehört ein Reifegrad. Die Skala folgt der aus dem CMMI bekannten Logik:
- ML 1 — Initial: Die Tätigkeit findet statt, aber ad hoc und personenabhängig.
- ML 2 — Managed: Es gibt einen definierten Ablauf, ausgeführt von geschultem Personal mit Ergebnissen, die jemand nachvollziehen kann.
- ML 3 — Defined (Practiced): Der Ablauf ist organisationsweit verbindlich und wird über Produkte hinweg gleich angewandt.
- ML 4 — Improving: Der Prozess wird gemessen und auf Basis dieser Messung verbessert.
Der Sprung, an dem die meisten Organisationen hängen, ist ML 1 → ML 2, und er ist kein Dokumentationsproblem. ML 2 verlangt nicht, dass ein Ablauf beschrieben ist, sondern dass sein Ergebnis für ein konkretes Produkt vorliegt. Ein Prozesshandbuch erzeugt keinen Reifegrad — die Artefakte tun es.
Die drei Lücken, die im Audit auffallen
Der Prozess gilt, aber nicht für dieses Produkt. Das Handbuch beschreibt Designreviews; für die Baureihe, um die es gerade geht, existiert kein Reviewprotokoll. Formal ML 3, belegbar ML 1.
Die Anforderung existiert, aber ohne Spur zur Maßnahme. Eine Sicherheitsanforderung ist notiert, aber keine Aktivität weist nach, dass sie im Produkt angekommen ist. Das ist die Lücke, die zwischen 4-1 und 4-2 klafft — und die der Reifecheck als Kennzahl abbildet.
Der freigegebene Stand ist nicht mehr identifizierbar. Nach der Freigabe wurde die Analyse weiterbearbeitet, die Anforderungsliste ergänzt, das Dokument umbenannt. Zwei Jahre später lässt sich nicht mehr zeigen, welche Fassung der Freigabe zugrunde lag.
Alle drei Befunde haben dieselbe Wurzel: Der Prozess ist beschrieben, aber seine Ergebnisse sind nicht an das Produkt und seine Version gebunden.
Vertiefung im Cluster
- Die Reife-Lücke: was 4-1 fordert und was 4-2 im Gerät nachweist
- SBOM ohne Zweitprozess: die Stückliste aus derselben Quelle wie der Build
- Konzept- und Designphase: Ergebnisse und Übergaben, die ein Audit übersteht
- CRA-Fristen 11.09.2026 und 11.12.2027 — was bis wann belegbar sein muss
Der Bezug zum Cyber Resilience Act
Der CRA nennt IEC 62443-4-1 nicht. Er verlangt aber, dass eine Cybersicherheits-Risikobewertung durchgeführt wird, dass sie über alle Lebensphasen in die Umsetzung einfließt und dass die grundlegenden Anforderungen aus Annex I auf ihre Ergebnisse zurückführbar sind. Genau diese Rückführbarkeit ist das, was ein nach 4-1 gelebter Prozess erzeugt.
Wer den Prozess bereits belegbar betreibt, muss für den CRA keine zweite Welt aufbauen — sondern vor allem zeigen, dass die vorhandene bis zum Nachweis durchgehalten wird. Zur Einordnung, welche Pflicht wann greift, siehe den Fristen-Artikel.
Dieser Artikel ist eine fachliche Einordnung, kein Rechtsrat und keine Zertifizierungsaussage. Normzitate bitte am Originaldokument prüfen.
Teil A des Reifecheck: Prozessreife über acht Practices.
Der TRA-Reifecheck zeigt in wenigen Minuten, wo Ihr Nachweis heute steht — Prozessreife, Umsetzungsabdeckung und die Lücke dazwischen.