Viele Unternehmen behandeln NIS-2 und CRA als zwei separate Baustellen. Die Rechtsabteilung kümmert sich um die eine, die IT um die andere. Das Problem: Beide Gesetze sind die regulatorische Antwort der EU auf ein strukturelles Problem — fehlende Cyber Supply Chain Security in der Industrie. Und sie greifen am selben Punkt — genau dort, wo die wenigsten hinschauen: wenn ein Mikrocontroller programmiert wird.
Das ist kein IT-Problem. Es ist ein Fertigungsproblem. Und es hat eine Deadline. Die Europäische Kommission hat das mit dem Tech Sovereignty Package vom 3. Juni 2026 bestätigt: Auch der neue Chips Act II sieht weitreichende Informationspflichten entlang der Lieferkette vor — und erhöht damit den Dokumentationsdruck auf alle Hersteller vernetzter Produkte weiter.
Was verlangt NIS-2 von Ihrer Lieferkette?
NIS-2 verpflichtet Unternehmen in kritischen Sektoren — darunter Automotive, Maschinenbau und Industrieelektronik — zu nachweisbaren Sicherheitsmaßnahmen entlang der gesamten Lieferkette. Das bedeutet konkret: Wer nicht belegen kann, dass seine Zulieferer sicher handeln, haftet selbst. Audits, Dokumentation und lückenlose Traceability sind keine Kür — sie sind Pflicht.
Was verlangt der Cyber Resilience Act von Ihrem Produkt?
Der CRA geht einen Schritt weiter und greift direkt ins Produkt. Ab September 2026 gilt die Meldepflicht für aktiv ausgenutzte Schwachstellen — innerhalb von 24 Stunden an ENISA. Ab Dezember 2027 greift die vollständige Konformitätspflicht: Secure by Design, vollständige SBOM, Lifecycle-Verantwortung. Strafen bis zu 15 Mio. Euro oder 2,5% des weltweiten Jahresumsatzes machen Untätigkeit teuer.
Der blinde Fleck liegt in der Fertigung
NIS-2 und CRA stellen dieselbe Grundfrage — nur aus zwei Richtungen. NIS-2 fragt: Können Sie nachweisen, dass Ihre Lieferkette vertrauenswürdig ist? CRA fragt: Können Sie nachweisen, dass Ihr Produkt vertrauenswürdig ist? Die Antwort auf beide Fragen beginnt am selben Punkt: wenn ein Mikrocontroller programmiert wird. Wer diesen Moment nicht kontrolliert und dokumentiert, kann weder die eine noch die andere Frage belegen.
Das gemeinsame Instrument heißt Chain of Trust.
Was ist eine Chain of Trust — und warum brauchen Sie sie für beide Gesetze?
Eine Chain of Trust ist die lückenlose, kryptografisch gesicherte Nachweiskette darüber, was mit einem Bauteil passiert ist — vom ersten Kontakt mit Schlüsselmaterial und Firmware bis zum fertigen, programmierten Produkt. Jeder Schritt wird dokumentiert, jede Übergabe belegt. Für NIS-2 ist sie der Nachweis, dass Ihre Lieferkette integer ist — von der Komponente bis zur Auslieferung. Für CRA ist sie der Nachweis, dass Ihr Produkt integer ist — von der Programmierung bis zum Ende des Lifecycles. Beides lässt sich nicht trennen. Und beides lässt sich mit einem einzigen durchgehenden Ansatz erfüllen.
Wo reißt die Chain of Trust heute?
Genau das verlangen CRA und BSI TR-03183 — und implizit auch NIS-2. Und genau das fehlt, wenn Firmware unsicher übertragen, manuell geflasht und ohne Programmiernachweis verbaut wird. Die Chain of Trust reißt still, unsichtbar — und meistens bemerkt man es erst, wenn ein Auditor fragt.
Warum eine Firewall die Chain of Trust nicht ersetzt
Die meisten Unternehmen haben eine Firewall. Viele haben ein ISMS. Beides schützt das Netzwerk — aber nicht den Moment, in dem das Produkt entsteht. Cybersicherheit beginnt nicht beim ersten Netzwerkpaket. Sie beginnt, wenn der MCU programmiert wird — also bevor das Produkt überhaupt existiert. Wer diesen Moment nicht kontrolliert und kryptografisch dokumentiert, hat eine Lücke in seiner Chain of Trust, die kein nachgelagertes Sicherheitssystem schließen kann. Eine Firewall schützt, was bereits im Netz ist. Die Chain of Trust sichert, was ins Netz kommt.
Chain of Trust braucht drei Ebenen
btv technologies ist nicht automatisch Normadressat dieser Gesetze — aber btv steht an genau den Prozessschritten, an denen Nachweise entstehen, die Kunden für ihre eigene Compliance brauchen. Und btv ist der einzige Partner, der diese Nachweiskette end-to-end abdeckt: von der Packaging Unit in der Lieferkette bis zum einzelnen Bauteil nach der Programmierung. Nicht als Compliance-Dienstleister, sondern weil Transparenz die Grundlage jeder Zusammenarbeit ist.
Lieferkette: TAK schafft Traceability auf Packaging-Unit-Ebene
NIS-2 verlangt Transparenz über Zulieferer und Komponenten — nachweisbar. Das TAK®-Modell von btv technologies trackt alle relevanten Daten ohnehin: Herkunft, Charge, Bewegung und Verbleib jeder Packaging Unit entlang der gesamten Lieferkette. Kunden, die mit btv zusammenarbeiten, haben diese Daten bereits — und können sie ohne Mehraufwand für ihre NIS-2-Nachweispflichten nutzen. Transparenz ist bei btv kein Zusatzservice. Sie ist die Arbeitsgrundlage.
Lagerung: Jede Packaging Unit bleibt lückenlos dokumentiert
Eingelagerte Komponenten sind ein regulatorisch unterschätztes Risiko — denn auch hier greift die Nachweispflicht. btv geht über IEC 62435 hinaus und dokumentiert jede Packaging Unit vollständig: vom Eingang über jeden Zwischenschritt — Bestromung, Repacking, Qualitätsprüfung — bis zur Ausgabe. Alle Vorgänge sind rückverfolgbar, alle Daten abrufbar. Als TISAX-zertifizierter Partner erfüllt btv dabei auch die Anforderungen der Automobilindustrie an Informationssicherheit entlang der Lieferkette. Wer seine Bestände bei btv lagert, hat Traceability für NIS-2 und CRA bereits eingebaut — ohne ein eigenes System dafür aufzubauen.
Programmierung: btv SEEL® — hochsicher und lückenlos nachvollziehbar
btv SEEL® ist ein hochsicheres Programmierverfahren: Schlüssel, Firmware und Zertifikate sind ausschließlich im RAM verfügbar und werden nie persistent gespeichert — kein Zugriff auf Inhalte, keine Angriffsfläche. Gleichzeitig wird jede Bewegung des Bauteils getrackt: welches Bauteil welche Firmware und welches Zertifikat erhalten hat, ist auf Seriennummernebene dokumentiert und jederzeit abrufbar. Das ist kein Sonderfeature — das ist btv-Standard. Wer mit btv programmiert, hat CRA-konforme SBOM, BSI TR-03183-Nachweis und Recall-Readiness in 24 Stunden bereits inklusive.
Was passiert, wenn der Programmierprozess selbst kompromittiert wird? Falsche Firmware im Feld, gestohlenes geistiges Eigentum, ein Sicherheitsnachweis, der im Audit nicht standhält — das sind keine theoretischen Szenarien. btv SEEL® setzt genau hier an: Der Kunde erhält nicht nur einen Nachweis darüber, was programmiert wurde — sondern die Gewissheit, dass der Vorgang selbst nicht kompromittierbar war. Das ist der Unterschied zwischen Dokumentation eines Prozesses und Integrität eines Prozesses.
btv SEEL® im Detail: Prozessintegrität und Nachweis in einem
Wann müssen Sie handeln?
Die Meldepflicht nach CRA startet in weniger als vier Monaten. NIS-2 ist seit Oktober 2024 nationales Recht. Und die neue EU-Produkthaftungsrichtlinie macht klar: Wer im Haftungsfall Charge, Softwarestand und Lieferhistorie nicht rekonstruieren kann, riskiert nicht einen gezielten Rückruf — sondern einen vollständigen.
Was ist der erste konkrete Schritt?
Der schnellste Weg zur Klarheit: eine strukturierte Lückenanalyse. Wo reißt Ihre Chain of Trust heute? Lieferkette, Lagerung oder Programmierung — oder alle drei? btv beantwortet diese Frage in einem 30-minütigen Gespräch mit konkreten Handlungsempfehlungen.
