Elektronik-Hardwareentwicklung für Kommunikationssysteme: Ihre Verzögerungsursachen wurden gemessen, nur nicht von der Community, die Durchlaufzeit maß.
Das Wichtigste in Kurzform
- Die Ursachen auf der Standardliste, also unklare Anforderungen, schwache bereichsübergreifende Kommunikation, dünne Vorarbeit im Front End, treffen für Hardware zu. Sie wurden an physischen Produkten belegt, bevor sie an Software belegt wurden. Gupta und Wilemon veröffentlichten 1990 zu technologiebasierten Produkten; der Standish CHAOS Report wurde für 1994 erhoben. Wer argumentiert, diese Liste sei ein Import aus der Software, hat die Chronologie verdreht.
- Das Problem ist nicht die Liste. Das Problem ist, dass die Liste aus einer von vier Forschungsgemeinschaften schöpft, die die Entwicklung physischer Produkte untersucht haben, und nicht aus derjenigen, die Durchlaufzeit gemessen hat. Krishnan und Ulrich haben rund 200 Arbeiten aus den Jahren 1988 bis 1998 gesichtet, ausdrücklich beschränkt auf physische Güter, und fanden ein Feld vor, das in Communitys zerfiel, die nicht miteinander sprachen. Die eine führt ihre Kennzahlen mit „Project success“ an und nennt organisatorische Abstimmung und Teameigenschaften als kritische Erfolgsfaktoren. Die andere führt ihre Kennzahlen mit „Efficiency“ an, listet dort die Durchlaufzeit und nennt Lieferanten- und Materialauswahl sowie die Gestaltung der Fertigungsfolge (Krishnan und Ulrich, Management Science 47(1), 2001). Die populäre Liste hat die erste geerbt und von der zweiten nur das Projektmanagement, das sie als Termindisziplin liest und nicht als Flusssteuerung.
- Der am besten gemessene Verzögerungsmechanismus in der Hardware ist eine Warteschlange, kein Missverständnis. In einem Fahrzeugentwicklungsprogramm lief die administrative Durchlaufzeit einer technischen Änderung über mehrere Wochen, mehrere Monate und in Extremfällen über ein Jahr, während die eigentliche Bearbeitung der Änderung typischerweise zwei Wochen nicht überschritt (Terwiesch und Loch, Journal of Product Innovation Management 16(2), 1999, DOI 10.1111/1540-5885.1620160). Sie können die bereichsübergreifende Kommunikation vollständig in Ordnung bringen und dieses Verhältnis dabei nicht angerührt haben.
- Bauteilabkündigungen laufen nach einer Uhr, die außerhalb Ihres Unternehmens gestellt wird, und die Untergrenze der Norm liegt niedrig. Der JEDEC-Standard zur Abkündigung verlangt sechs Monate Vorlauf für letzte Bestellungen und zwölf Monate bis zur letzten Auslieferung. Als AMD am 1. Januar 2024 neun CPLD- und FPGA-Familien abkündigte, gewährte das Unternehmen 180 und 362 Tage, also zwei Tage weniger als sechs Monate und vier weniger als zwölf, und in den Bauteiltabellen steht in der Ersatzspalte „No direct replacement“ (AMD, Product Discontinuation Notice XCN23009).
- Drei regulatorische Termine fallen zwischen den 11. September und den 15. November 2026, eine Spanne von neun Wochen, und alle drei sind im Register nachprüfbar: die Meldepflichten des Cyber Resilience Act zum 11. September 2026, die Produktgestaltungspflicht des Data Act zum 12. September 2026 und die Streichung von sechs überholten Funk- und EMV-Normfassungen aus der Liste im Amtsblatt zum 15. November 2026. Keiner davon ist verhandelbar, und keiner taucht in irgendeinem klassischen Verzögerungsmodell auf.
- Was dieser Beitrag nicht leistet: Er sagt Ihnen nicht, welcher Anteil Ihres Kalenders auf Verifikation und Zertifizierung entfällt, weil dazu niemand eine belastbare Messung veröffentlicht hat. Die Zahl, die in dieser Branche am häufigsten zitiert wird, dass rund die Hälfte aller Produkte den ersten EMV-Test nicht besteht, ließ sich auf kein akkreditiertes Labor, keine Normungsorganisation und keine begutachtete Studie zurückführen. Einzelheiten stehen im Abschnitt darüber, was niemand gemessen hat.
Ein Hardwareprogramm gerät in Verzug, jemand setzt eine Retrospektive an, und die Befunde kommen zurück: Die Anforderungen waren instabil, die Schnittstellen zwischen den Teams schlecht definiert, der Terminplan optimistisch. Diese Befunde stimmen fast immer. Sie reichen fast immer auch nicht aus, und das liegt nicht daran, dass das Team eine schlechte Retrospektive gefahren hätte. Es liegt daran, dass das diagnostische Vokabular, das ihm zur Verfügung stand, von einer Forschungsgemeinschaft zusammengetragen wurde, die nie das gemessen hat, was den Kalender tatsächlich verbraucht hat.
In diesem Beitrag geht es darum, wo der Rest dieses Vokabulars liegt, wenn Projektverzögerungen in der Hardwareentwicklung erklärt werden sollen. Alles Folgende ist aus Primärquellen belegt, soweit Primärquellen existieren; wo sich eine viel zitierte Zahl auf keine zurückführen ließ, steht das so da, statt überdeckt zu werden. Drei solcher Fälle kommen vor, und sie gehören zu den nützlicheren Teilen des Textes.
Inhalt: Die Ursachen stimmen · Die andere Community · Die Warteschlange · Die Bauteiluhr · Drei Termine · EN 18031 · Was niemand gemessen hat · Was steuerbar ist · Checkliste · Häufige Fragen · Fazit · Autor · Offenlegung · Methodik · Bildnachweise
Der häufigste Rahmungsfehler in dieser Diskussion besteht darin, die Standardliste der Ursachen für Entwicklungs- und Projektscheitern als Artefakt des Software-Projektmanagements zu behandeln, das nachträglich auf die Hardware geschraubt wurde. Diese Vorstellung sollte man früh beerdigen, denn sie ist bei den Jahreszahlen falsch, und ein technisches Publikum merkt das.
Gupta und Wilemon befragten Manager, die technologiebasierte Produkte entwickelten, und berichteten von vier Bereichen, die die Entwicklungsleistung bestimmen: Rückhalt durch die Geschäftsleitung, frühe Einbindung der Fachbereiche, Verfügbarkeit und Steuerung der Ressourcen sowie ein organisatorisches Umfeld, das Teamarbeit trägt. Veröffentlicht wurde das 1990 (California Management Review 32(2)). Cooper und Kleinschmidt untersuchten 103 Neuproduktprojekte in der Chemieindustrie und identifizierten als wichtigsten Treiber der Termintreue ein bereichsübergreifendes, dediziertes, verantwortliches Team mit starker Leitung, gefolgt von solider Vorarbeit vor der eigentlichen Entwicklung (JPIM 11(5), 1994, DOI 10.1016/0737-6782(94)90028-0). Eisenhardt und Tabrizi untersuchten 72 Projekte in 36 Unternehmen der weltweiten Computerindustrie (Administrative Science Quarterly 40(1), 1995, DOI 10.2307/2393701). Zirger und Hartley untersuchten gezielt Elektronikunternehmen (IEEE Transactions on Engineering Management 43(2), 1996). Griffin maß Entwicklungszeiten in 21 Bereichen von 11 Unternehmen aus fünf Branchen (Journal of Engineering and Technology Management 14, 1997). Crawford hatte bereits 1992 argumentiert, dass Beschleunigung eigene versteckte Kosten trägt, darunter einen Rückzug aus lernintensiver Innovation und dünnere Vorarbeit im Front End (JPIM 9(3), 1992).
Chemie. Automobile. Computer. Elektronik. Das waren physische Produkte, und diese Arbeiten liegen vor dem Standish CHAOS Report, der für 1994 erhoben wurde und 365 IT-Führungskräfte zu 8.380 Softwareanwendungen befragte.
Ein Ergebnis aus diesem Bestand verdient mehr Aufmerksamkeit, als es bekommt, weil es die Erwartungen richtig setzt, wie viel all das überhaupt einbringt. Zirger und Hartley prüften zwölf Beschleunigungstechniken gegen die Entwicklungszeit in Elektronikunternehmen. Nur vier standen in dem angenommenen Zusammenhang signifikant mit der Entwicklungszeit. Die schnelleren Entwickler hatten bereichsübergreifende, dedizierte Teams, behandelten Time-to-Market als ausdrückliches Ziel und überlappten Entwicklungsaktivitäten.
Acht von zwölf standen also nicht in der angenommenen Beziehung zur Entwicklungszeit. Was den Rest eines Elektronikterminplans bestimmt, stand nicht auf dieser Liste, und darum geht es im Rest dieses Beitrags.
2001 veröffentlichten Krishnan und Ulrich in Management Science eine Übersicht über die Literatur zur Produktentwicklung. Sie filterten rund 400 Arbeiten auf etwa 200 herunter, deckten Zeitschriften der Jahre 1988 bis 1998 ab und stellten unmissverständlich fest, dass sie ihre Aufmerksamkeit der Entwicklung physischer Güter widmen. Ihre Tabelle 1 vergleicht vier akademische Communitys, die an dieser Literatur arbeiteten: Marketing, „Organizations“, Engineering Design und „Operations Management“. Die beiden letztgenannten Etiketten stammen von den Autoren selbst: „Organizations“ steht für die organisationswissenschaftliche Sicht, „Operations Management“ für die Sicht der Produktions- und Ablaufforschung. Zwei dieser vier erklären, wie eine korrekte Ursachenliste den Kalender trotzdem verfehlen kann.
Die Tabelle beginnt damit, was jede Community unter einem Produkt versteht. Für „Organizations“ gilt: „Ein Produkt ist ein Artefakt, das aus einem organisatorischen Prozess hervorgeht.“ Für „Operations Management“: „Ein Produkt ist eine Abfolge von Entwicklungs- und/oder Produktionsprozessschritten.“ Das sind nicht zwei Beschreibungen eines Gegenstands. Das sind Beschreibungen zweier verschiedener Gegenstände, und sie erzeugen verschiedene Fragen.
Es folgen die Leistungskennzahlen. Die Spalte „Organizations“ beginnt mit „Project success“, darunter technische Leistung und Innovationsgrad. Die Spalte „Operations Management“ beginnt mit „Efficiency“, darunter Gesamtkosten, Servicegrad, Kapazitätsauslastung und die Durchlaufzeit, die in dieser Spalte der Tabelle steht und in keiner anderen.
Auch die kritischen Erfolgsfaktoren folgen. Für „Organizations“: organisatorische Abstimmung, Teameigenschaften. Für „Operations Management“: Lieferanten- und Materialauswahl, Gestaltung der Fertigungsfolge, Projektmanagement.
Die Aufspaltung selbst ist dokumentiert. Was hier daraus folgt, ist Schlussfolgerung: Niemand hat die Operations-Seite unterdrückt, aber sie publizierte in anderen Zeitschriften und vor anderen Gutachtern, und uns ist keine Studie bekannt, die nachzeichnet, welche dieser Communitys das Vokabular der industriellen Projektretrospektive geliefert hat. Die Übereinstimmung zwischen der linken Spalte und der gebräuchlichen Liste ist eng, und als genau das wird sie hier angeboten: als Übereinstimmung, nicht als nachgewiesene Abstammung.
Stellt man die beiden Listen nebeneinander, wird die Auslassung ohne weiteres Argument sichtbar. Alles links betrifft Menschen und wie sie organisiert sind. Rechts betreffen zwei der drei Punkte Bauteile und Fertigungsfolge; der dritte, Projektmanagement, ist der eine Punkt, den die populäre Liste tatsächlich geerbt hat, und sie hat ihn als Termindisziplin geerbt statt als Flusssteuerung. Eine Retrospektive, die aus der linken Liste plus einem Gantt-Diagramm gebaut ist, kann vollständig richtig sein und trotzdem nie bei einer Frage nach einem Bauteil ankommen.
Dass die Operations-Community Kalenderzeit an Hardware untersucht hat, steht nicht in Frage. Clark und Fujimoto betitelten ihre Studie von 1989 mit „Lead Time in Automobile Product Development: Explaining the Japanese Advantage“, und ihr erklärter Rahmen prüft die Wirkung von Produktinhalt, Projektumfang und organisatorischer Leistungsfähigkeit auf die Entwicklungsdurchlaufzeit (Journal of Engineering and Technology Management 6, 1989). Zahlen zum Anteil der Neuteileentwicklung, den Lieferanten tragen, kursieren breit mit dieser Arbeit als Beleg; im hier zugänglichen Material stehen sie nicht und werden deshalb nicht wiederholt.
Wenn Sie eine einzige Quelle wollen, die erklärt, warum Hardwareänderungen Monate brauchen, während die Arbeit Tage dauert, dann ist es die Untersuchung technischer Änderungen (Engineering Change Orders) von Terwiesch und Loch an der Klimaanlage eines Fahrzeugprogramms.
Ihr Befund aus dem Feld: Der administrative Prozess um eine technische Änderung kann mehrere Wochen, mehrere Monate und in Extremfällen sogar über ein Jahr dauern, während die eigentliche Bearbeitungszeit der Änderung typischerweise zwei Wochen nicht überschreitet (JPIM 16(2), 1999, DOI 10.1111/1540-5885.1620160). Sie benennen fünf Ursachen, und nur eine davon ist das, was eine Retrospektive ein Kommunikationsproblem nennen würde: ein komplexer Freigabeprozess, sich aufschaukelnde Folgeänderungen, knappe Kapazität und Stau, Rüstvorgänge und Losbildung sowie organisatorische Themen.
Knappe Kapazität, Stau, Rüstvorgänge und Losbildung sind Begriffe aus der Warteschlangentheorie. Sie beschreiben ein Flussproblem, und Flussprobleme werden über den Fluss gelöst: gebündelte Kapazität, kleinere Lose, ausgeglichene Auslastung, weniger Freigabestationen. Nichts davon ist ein Abstimmungsworkshop, und nichts davon taucht auf, wenn die Vorlage der Retrospektive nur die Abstimmungsspalte enthält. Die Begleitarbeit derselben Autoren modelliert den Effekt formal und berichtet, dass technische Änderungen zwischen einem Drittel und der Hälfte der Entwicklungskapazität binden (Loch und Terwiesch, JPIM 16(2), 1999, DOI 10.1111/1540-5885.1620145).
Das ist die allgemeine Gestalt von Hardwareverzug. Es folgen die drei konkreten Warteschlangen, in denen ein Programm der Elektronik-Hardwareentwicklung für Kommunikationssysteme steht, geordnet danach, wie wenig Kontrolle Sie darüber haben.
Die Bauteilabkündigung ist in der Hardware der klarste Fall eines Terminereignisses, das vollständig außerhalb des Projekts entsteht und durch nichts beschleunigt werden kann, was das Team tut.
Das maßgebliche Dokument ist der JEDEC-Standard zur Abkündigung, JESD48C. Er verlangt vom Lieferanten, den Kunden ab der Mitteilung sechs Monate für letzte Bestellungen und zwölf Monate bis zur letzten Auslieferung einzuräumen (JEDEC, JESD48C, Abschnitt 3.1). Zwei Eigenschaften dieses Standards wiegen schwerer als die Zahlen. Er ist freiwillig, und die Einhaltung wird nicht auditiert: Das Dokument selbst hält fest, dass Konformität nur behauptet werden darf, wenn alle Anforderungen erfüllt sind, aber niemand prüft das nach. Und seine Definition von „Kunde“ erfasst diejenigen, die innerhalb der vergangenen zwei Jahre unter einer Benachrichtigungsvereinbarung gekauft haben, was ein langlebiges Industrieprogramm, das in seltenen Losen beschafft, stillschweigend ausschließen kann.
So sieht diese Untergrenze aus, wenn ein Lieferant sich darauf setzt.
Am 1. Januar 2024 gab AMD die Abkündigungsmitteilung XCN23009 heraus, die neun CPLD- und FPGA-Familien umfasst, darunter die CPLDs XC9500XL und CoolRunner II sowie die FPGAs Spartan II, Spartan 3, 3A, 3AN, 3E und 3ADSP. Als Grund wurden rückläufige Stückzahlen und die Tragfähigkeit der Zulieferung genannt. Der Last Time Buy (LTB) wurde auf den 29. Juni 2024 gelegt, die letzte Auslieferung auf den 28. Dezember 2024. Das sind 180 und 362 Tage ab der Mitteilung, gegen ein JEDEC-Minimum von sechs und zwölf Monaten: zwei Tage zu wenig am ersten Tor, vier Tage zu wenig am zweiten. In den Bauteiltabellen dieser Mitteilung steht in der Spalte für das Ersatzteil „No direct replacement“ (AMD, XCN23009 v1.0).
Um diesen konkreten Fall herum liegt ein breiteres Muster, das man mit angehängten Einschränkungen berichten sollte. Der Lifecycle-Datenanbieter Z2Data zählte für 2025 621.909 Herstellerteilenummern, die das Lebensende erreichten, und berichtete, dass 323.286 davon, also rund 52 Prozent, überhaupt keine Product Change Notification trugen (Z2Data, März 2026). Diese Zahl stammt aus einer kommerziellen Datenbank, deren Methodik nicht offengelegt ist, von einem Anbieter mit eigenem Interesse am Befund, und sie zählt Teilenummern, nicht Design-ins. Behandeln Sie den genauen Prozentsatz als Richtungsangabe. Die Richtung wird durch frühere Auswertungen desselben Anbieters gestützt, und die betriebliche Folgerung überlebt den Vorbehalt: Der Benachrichtigungsmechanismus, den JESD48C beschreibt, ist kein verlässliches Frühwarnsystem.
Das Versorgungsbild darunter ist zu nichts zurückgekehrt, was man normal nennen möchte, und es ist auch keine Krise. In der Umfrage der Electronic Components Industry Association vom Februar 2026 fiel der Anteil der Befragten, die steigende Lieferzeiten bei Halbleitern meldeten, von 52 Prozent im Januar auf 39 Prozent im Februar, aber nur 5 Prozent meldeten sinkende Lieferzeiten (ECIA Industry Pulse, Februar 2026). Verlangsamung ist keine Umkehr. Unter dem Marktsignal liegt eine strukturelle Untergrenze, die keine Nachfragelage beseitigt: Die ECIA setzt die Waferfertigung mit bis zu zwölf Wochen sowie Assembly und Test mit vier bis acht Wochen an, innerhalb eines Gesamtzyklus, den sie mit rund 26 Wochen vom Rohmaterial bis zum fertigen Chip beziffert (ECIA, Understanding Semiconductor Lead Times).
Die Folge auf der Entwurfsseite wurde einmal gemessen, auf dem Höhepunkt der Knappheit. In einer Ende 2021 durchgeführten Befragung von 530 Ingenieuren berichteten 74 Prozent von verschobenen Produktionsterminen, 64 Prozent gaben an, nach Bauteilverfügbarkeit statt nach Präferenz zu entwerfen, und 55 Prozent hatten eine Leiterplatte neu aufgelegt, weil ein eingeplantes Bauteil nicht lieferbar war (Avnet Insights, März 2022). Das ist eine nicht zufallsbasierte Stichprobe aus dem Kundenbestand eines Distributors in der schlimmsten je erfassten Phase, und sie ist als Obergrenze zu lesen, nicht als aktuelle Rate. Sie ist zugleich die einzige Quantifizierung dieser Art, die wir finden konnten.
Zu den architektonischen Folgen des Entwerfens nach Verfügbarkeit statt nach Präferenz, besonders in der kundenspezifischen Hardwareentwicklung für industrielle Kommunikationssysteme, in der ein Kommunikationsprozessor, ein FPGA-Design oder ein aufgelötetes Modul im Spiel ist, stehen die Abwägungen in unserem Beitrag zu industrieller Kommunikationshardware im Jahr 2026.
Die dritte Warteschlange ist die ohne jede Verhandlung, weil die Gegenseite ein Gesetzgeber ist. Drei Pflichten mit Bezug zur Kommunikationshardware werden zwischen dem 11. September und dem 15. November 2026 wirksam, eine Spanne von neun Wochen. Alle drei Termine unten wurden im Register aus dem Text des Amtsblatts gelesen.
11. September 2026: Meldepflichten nach dem Cyber Resilience Act. Die Verordnung (EU) 2024/2847 gilt vollständig ab dem 11. Dezember 2027, doch Artikel 71 Absatz 2 nimmt zwei frühere Termine heraus: „Artikel 14 gilt jedoch ab dem 11. September 2026, und Kapitel IV (Artikel 35 bis 51) gilt ab dem 11. Juni 2026.“ (Verordnung (EU) 2024/2847). Artikel 14 verpflichtet den Hersteller, aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle dem koordinierenden CSIRT und der ENISA zu melden. Artikel 69 Absatz 3 verschließt den naheliegenden Ausweg: Diese Pflichten gelten auch für Produkte, die vor dem 11. Dezember 2027 in Verkehr gebracht wurden. Das absorbiert kein Entwicklungszyklus von 2027. Es verlangt, dass bis zum 11. September 2026 eine Überwachungs- und Meldefähigkeit besteht.
12. September 2026: Produktgestaltung nach dem Data Act. Die Verordnung (EU) 2023/2854 gilt seit dem 12. September 2025, ihre zentrale Hardwarepflicht trägt jedoch ein um ein Jahr späteres Datum: „Die Verpflichtung gemäß Artikel 3 Absatz 1 gilt für vernetzte Produkte und die mit ihnen verbundenen Dienste, die nach dem 12. September 2026 in Verkehr gebracht wurden.“ Artikel 3 Absatz 1 verlangt: „Vernetzte Produkte werden so konzipiert und hergestellt und verbundene Dienste werden so konzipiert und erbracht, dass die Produktdaten und verbundenen Dienstdaten – einschließlich der für die Auslegung und Nutzung dieser Daten erforderlichen relevanten Metadaten – standardmäßig für den Nutzer einfach, sicher, unentgeltlich in einem umfassenden, strukturierten, gängigen und maschinenlesbaren Format und, soweit relevant und technisch durchführbar, direkt zugänglich sind.“ (Verordnung (EU) 2023/2854). Das ist eine Gestaltungspflicht, die das Datenmodell, das Logging auf dem Gerät und die Freilegung von Schnittstellen berührt, und sie wird, gemessen am Cyber Resilience Act, systematisch zu wenig diskutiert.
15. November 2026: sechs Normfassungen verlieren ihre Fundstelle. Der Durchführungsbeschluss (EU) 2025/893 ändert die Liste der harmonisierten Normen zur Funkanlagenrichtlinie (RED). Sein Artikel 2 bestimmt: „Nummer 2 des Anhangs gilt ab dem 15. November 2026.“, und Nummer 2 streicht sechs Zeilen aus der Liste. Damit entfällt die Konformitätsvermutung für überholte Fassungen, darunter EN 301 893 V2.1.1 für 5-GHz-Funkzugangssysteme, EN 301 908-3 V13.1.1 und EN 301 908-13 V13.2.1 für IMT-Geräte sowie EN 301 489-52 V1.2.1 für die elektromagnetische Verträglichkeit im Mobilfunk (Durchführungsbeschluss (EU) 2025/893). Ein Projekt, das Funkprüfberichte gegen eine gestrichene Fassung hält, hat kein Dokumentationsproblem. Es hat eine Nachprüfung, und Nachprüfungen werden in den Kalender eines anderen gebucht.
| Termin | Rechtsakt | Was er verlangt | Wen es trifft |
|---|---|---|---|
| 11. September 2026 | Verordnung (EU) 2024/2847, Artikel 14 | Aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle dem koordinierenden CSIRT und der ENISA melden | Hersteller, auch für bereits in Verkehr gebrachte Produkte (Artikel 69 Absatz 3) |
| 12. September 2026 | Verordnung (EU) 2023/2854, Artikel 3 Absatz 1 | Vernetzte Produkte so konzipieren und herstellen, dass Produktdaten dem Nutzer standardmäßig in maschinenlesbarem Format zugänglich sind | Vernetzte Produkte, die nach diesem Termin in Verkehr gebracht werden |
| 15. November 2026 | Durchführungsbeschluss (EU) 2025/893, Anhang Nummer 2 | Sechs überholte Normfassungen verlieren ihre Fundstelle im Amtsblatt, darunter EN 301 893 V2.1.1, EN 301 908-3 V13.1.1, EN 301 908-13 V13.2.1 und EN 301 489-52 V1.2.1 | Jeder Entwurf, dessen Konformitätsvermutung auf einer gestrichenen Fassung beruht: Nachprüfung |
| 11. Dezember 2027 | Verordnung (EU) 2024/2847, Hauptpflichten | Vollständiges Regime des Cyber Resilience Act mit Konformitätsbewertung nach Produktklasse | Anhang III Klasse I nennt Router, Modems für die Internetanbindung und Switches |
Die ersten drei Zeilen sind die kurzfristigen Termine; die vierte ist der unten behandelte Horizonttermin. Jeder Termin und jede Artikelangabe in dieser Tabelle wurde am 8. August 2026 im Amtsblatt aus dem Text des Rechtsakts gelesen.
Hinter diesen dreien liegt der Termin, der alles regiert, was jetzt entworfen wird. Die Hauptpflichten des Cyber Resilience Act gelten ab dem 11. Dezember 2027. Für ein Programm der Kommunikationshardware mit einem Zyklus von zwei bis drei Jahren geht ein Produkt, das heute auf dem Reißbrett liegt, genau in dieses Regime hinein. Und der Rechtsakt benennt die Produkte dieser Leserschaft ausdrücklich: Anhang III, Klasse I, Nummer 12 lautet „Router, Modems für die Internetanbindung und Switches“. Daneben stehen in derselben Klasse „Netzmanagementsysteme“, „physische und virtuelle Netzschnittstellen“, „Mikroprozessoren mit sicherheitsrelevanten Funktionen“ und „Mikrocontroller mit sicherheitsrelevanten Funktionen“, ebenso ASICs und FPGAs mit sicherheitsrelevanten Funktionen.
Eine Korrektur lohnt sich, weil sie in die andere Richtung geht: Router, Modems und Switches sind wichtige Produkte nach Anhang III, nicht kritische Produkte nach Anhang IV. Anhang IV ist kurz: Hardwaregeräte mit Sicherheitsboxen, Smart-Meter-Gateways und ähnliche Geräte für fortgeschrittene Sicherheitszwecke sowie Smartcards oder ähnliche Geräte einschließlich sicherer Elemente. Eine höhere Einstufung zu behaupten, als die Verordnung zuweist, ist ein Fehler, den ein Systemarchitekt bemerkt. Unser früherer Leitfaden zum EU Cyber Resilience Act (englischsprachig) behandelt die Wege der Konformitätsbewertung im Detail.
Die Cybersicherheitsanforderungen der Funkanlagenrichtlinie gelten seit dem 1. August 2025. Die Delegierte Verordnung (EU) 2022/30 hatte ursprünglich den 1. August 2024 gesetzt; die Delegierte Verordnung (EU) 2023/2444 ersetzte das durch „Sie gilt ab dem 1. August 2025.“ (Delegierte Verordnung (EU) 2023/2444). Das ist ein alter Hut.
Was Projekte weiterhin erwischt, ist die Gestalt der harmonisierten Normen, die zu ihrer Unterstützung geschrieben wurden. EN 18031-1, -2 und -3 wurden im Januar 2025 im Amtsblatt gelistet, aber mit Einschränkungen, und diese Einschränkungen sind eng, spezifisch und werden durch Entwurfsentscheidungen bestimmt, nicht durch Dokumentation.
Die tragende Einschränkung lautet, aus dem Anhang des Durchführungsbeschlusses (EU) 2025/138: „Diese harmonisierte Norm begründet keine Vermutung der Konformität mit der grundlegenden Anforderung gemäß Artikel 3 Absatz 3 Unterabsatz 1 Buchstabe d der Richtlinie 2014/53/EU, wenn dem Nutzer bei Anwendung der Nummern 6.2.5.1 und 6.2.5.2 erlaubt ist, kein Passwort festzulegen bzw. zu verwenden.“ Eine zweite Einschränkung nimmt allen Abschnitten der Normen, die mit „rationale“ (Begründung) oder „guidance“ (Leitlinie) betitelt sind, die Konformitätsvermutung (Durchführungsbeschluss (EU) 2025/138).
Überlegen Sie, wo diese Entscheidung tatsächlich fällt. Ob ein Gerät es einem Installateur erlaubt, das Setzen eines Passworts zu überspringen, ist eine Entscheidung über Onboarding und Provisionierung, früh getroffen, meist von demjenigen, dem der Inbetriebnahmeablauf gehört, und oft mit der Bequemlichkeit im Außendienst begründet. Sie wird nicht als Compliance-Entscheidung protokolliert. Als solche taucht sie erst viel später auf, an der Stelle, an der die Konformitätsvermutung greifen sollte und nicht greift.
Das ist das allgemeine Muster dieses Beitrags in Reinform: dieselbe Fehlerklasse, die die klassische Literatur benannt hat, spät entdeckt, physisch entdeckt und über eine Warteschlange behoben, die Ihnen nicht gehört. Was ein Projekt dagegen tun kann, ist strukturell: Die Anforderungen an die Produkt-Security müssen der Architektur zugewiesen werden, bevor der Provisionierungsablauf feststeht, statt hinterher auditiert zu werden. Die Abfolge der Tore von der Validierung bis zur Serienreife von Elektronikprodukten steht in unserem Beitrag zu Kommunikationshardware bis zur Serie.
Diesen Abschnitt gibt es, weil drei Zahlen, die in dieser Branche frei zirkulieren, die Prüfung nicht überstanden haben, und das zu sagen ist nützlicher, als sie zu wiederholen.
Der Anteil des Kalenders eines Hardwareprogramms, der auf Verifikation und Zertifizierung entfällt. Eine Quelle mit offengelegter Methode scheint es nicht zu geben. Das ist die Zahl, die den Streit entscheiden würde, um den es in diesem Beitrag geht, und sie ist nie veröffentlicht worden. Der nächstliegende benachbarte Datenpunkt ist ein Benchmark-Bericht, in dem 65 Prozent der Befragten aus der Elektronik angaben, das Erstellen und Einreichen von Zertifizierungsunterlagen werde komplexer: ein Wahrnehmungsmaß, kein Kalendermaß, und aus einer vom Anbieter gesponserten Studie (Lifecycle Insights, 2021).
Die Behauptung, rund die Hälfte aller Produkte falle beim ersten EMV-Test durch. Wir konnten das auf kein akkreditiertes Labor, keine Normungsorganisation und keine begutachtete Studie zurückführen. Die Spur führt zu einem Anbieter-Whitepaper von etwa 2007, dessen kanonische URL nicht mehr auflöst, und eine Prüfung durch Dritte dokumentiert, dass Werte von 50 Prozent, über 90 Prozent und 97 Prozent alle derselben Quelle zugeschrieben wurden, ohne Methodik, ohne Stichprobengröße und ohne Produktsegmentierung (Prüfung der Behauptung durch EMI Software). Dieser Prüfer verkauft EMV-Simulationssoftware und hätte kommerziell einen Vorteil davon, dass Fehlschläge im ersten Anlauf im ersten Anlauf häufig sind, was die Richtung seiner Skepsis erwähnenswert macht, statt sie abzuwerten. Das zugrunde liegende Phänomen, dass EMV-Fehlschläge im ersten Anlauf im ersten Anlauf häufig und teuer sind, ist real, und jede Hardwaregruppe hat es erlebt. Die Zahl ist trotzdem kein Beleg.
Die Dauer einer Zweitquellenqualifizierung. Es wurde keine begutachtete oder von einem Verband veröffentlichte Messung gefunden. Die prominenteste kursierende Zahl wird einer Benchmarking-Studie der Semiconductor Industry Association zugeschrieben, die es nicht zu geben scheint: Die Seite, die sie trägt, nennt nur den Namen der Organisation, verlinkt auf deren Startseite und führt weder Studientitel noch Datum, Autor, Stichprobe oder Methodik. Verwandte Zahlen auf derselben Seite tragen denselben Mangel. Das ist gerade deshalb erwähnenswert, weil Bauteilsubstitution inzwischen ein Routinevorgang ist.
Zwei weitere Leerstellen sind zu benennen. Es gibt keine veröffentlichte Zahl der für die Cybersicherheitsanforderungen der Funkanlagenrichtlinie benannten notifizierten Stellen, die wir hätten beschaffen können, weil die NANDO-Datenbank in eine clientseitige Anwendung überführt wurde, die die Abfrage nicht offenlegt. Und es gibt keinen methodisch offengelegten Datensatz zu Wartezeiten akkreditierter Labore in der EU. Beide Lücken werden häufig mit selbstbewussten Behauptungen über Engpässe gefüllt. Wir haben keine anzubieten.
Aus den Belegen oben folgen drei Dinge, geordnet nach Hebelwirkung.
Behandeln Sie Bauteillanglebigkeit als Spezifikation, denn die Anbieter veröffentlichen unterschiedliche. Texas Instruments beschreibt typische Produktlebenszyklen von 10 bis 15 Jahren und gibt 12 Monate für eine letzte Bestellung plus 6 Monate bis zur letzten Lieferung an, ein Fenster von 18 Monaten, das das Unternehmen als länger als den Branchenstandard bezeichnet (TI, Produktlebenszyklus und Qualitäts-FAQ). Microchip nennt ein Fenster von 12 Monaten und berichtet, in den Jahren 2022 und 2023 jeweils rund 0,2 Prozent der Produkte abgekündigt zu haben, mit der Zusage, Produkte mit Geschäftsaktivität in den vergangenen drei Jahren nicht abzukündigen, vorbehaltlich der Fertigbarkeit (Microchip, Produktlanglebigkeit). Das sind Selbstauskünfte ohne Audit. Es sind zugleich echte, beim Design-in wählbare Unterschiede, und sie zu wählen ist billiger, als sie nachzurüsten.
Greifen Sie die Warteschlange an, nicht die Abstimmung. Wenn Terwiesch und Loch recht haben und die Durchlaufzeit die Bearbeitungszeit um eine Größenordnung übersteigt, dann ist der Terminhebel mit der größten Wirkung in einem Hardwareprogramm die Reduktion von Freigabestationen, Losbildung und Konkurrenz um knappe Spezialisten, nicht ein weiterer Schnittstellenworkshop. Das ist im eigenen Haus messbar, ohne auf einen veröffentlichten Benchmark zu warten: Erfassen Sie die verstrichene Zeit und die reine Bearbeitungszeit Ihrer eigenen technischen Änderungen und vergleichen Sie beide.
Prognostizieren Sie aus einer Referenzklasse, nicht aus dem Plan. Flyvbjergs Arbeiten zu Optimismusverzerrung, strategischer Fehldarstellung und Reference-Class-Forecasting lassen sich als Methode sauber auf ein Programm auf Vorstandsebene übertragen (Flyvbjerg, Project Management Journal 45(2), 2014). Seine Zahlen nicht: Seine Analyseeinheit ist ein Projekt ab einer Milliarde US-Dollar, und er stellt in derselben Arbeit fest, Megaprojekte seien „eine völlig andere Art von Projekt“ und nicht bloß vergrößerte Versionen kleinerer. Nehmen Sie die Methode, lassen Sie die Basisraten.
Ein Befund verdient hier einen Platz, weil er gegen eine Geschichte läuft, die Hardwareteams gern über sich erzählen. Die NASA hat 231 verifizierte Hardwarefehler aus einem großen Flugzeugprogramm ausgewertet und fand, dass Fehler aus der Anforderungsphase die größte Einzelkategorie bildeten, mit 66 gegenüber 61 aus der Konstruktion. Dieselbe Studie maß den Kostenanstieg nach Phase und fand für Hardware Faktoren von 1, 8, 16, 21 und 29 gegenüber Softwarevergleichswerten von 1, 5 bis 7, 10 bis 26, 50 bis 177 und 100 bis 1000, mit dem Schluss, dass Hardwarekorrekturen kostenseitig gnädiger ausfallen als Softwarekorrekturen (Stecklein et al., NASA JSC / INCOSE, 2004).
Beide Hälften davon sind unbequem. Anforderungsqualität zählt in der Hardware so viel wie überall sonst, die Abstimmungsspalte war also nie falsch. Und die vertraute Eskalationskurve 1:10:100, gewöhnlich auf Barry Boehms Software Engineering Economics (1981) und dessen Auswertung von Softwareprojekten der 1970er Jahre zurückgeführt, überzeichnet die Hardwarekosten in späten Phasen. Das Problem der Hardware ist nicht, dass jede Korrektur unverhältnismäßig mehr kostet. Es ist, dass die Uhr langsamer läuft und die Warteschlange jemand anderem gehört. Für Programme, in denen dieser Unterschied gesteuert und nicht diskutiert werden muss, ist genau das der Kern dessen, was Hardwareentwicklung für Kommunikationssysteme richtig machen muss.
Nein, und der Beitrag, der Ihnen das erzählt hat, lag falsch. Diese Ursachen wurden über die 1990er Jahre an physischen Produkten belegt, an Chemie, Automobilen, Computern und Elektronik, und im entscheidenden Fall liegt die Hardwarepublikation vier Jahre vor der Softwarepublikation. Die Fehleranalyse der NASA stellt Anforderungsfehler auch in einem reinen Hardwareprogramm der Zahl nach an die erste Stelle. Die haltbare Aussage ist enger: Die populäre Liste schöpft aus der Forschungsgemeinschaft, die Projekterfolg über organisatorische Abstimmung gemessen hat, und nicht aus der, die Durchlaufzeit über Lieferanten- und Materialauswahl und über die Fertigungsfolge gemessen hat.
Nach den verfügbaren Belegen die Reduktion der Wartezeit im Änderungsprozess. Terwiesch und Loch fanden administrative Durchlaufzeiten von mehreren Wochen bis über ein Jahr gegen Bearbeitungszeiten von zwei Wochen oder weniger. Kein anderer berichteter Mechanismus in der Hardwareliteratur zeigt eine Lücke dieser Größe, und es ist einer der wenigen, den ein Unternehmen ohne fremde Mitwirkung messen und angehen kann.
Teilweise, und darin liegt die Falle. Die Hauptpflichten gelten ab dem 11. Dezember 2027, und Produkte, die vorher in Verkehr gebracht wurden, werden nur erfasst, wenn sie danach wesentlich verändert werden. Artikel 69 Absatz 3 erstreckt die Meldepflichten des Artikels 14 jedoch auf bereits in Verkehr gebrachte Produkte, und Artikel 14 selbst beginnt am 11. September 2026. Meldepflichten für aktiv ausgenutzte Schwachstellen lassen sich daher nicht auf den nächsten Entwicklungszyklus verschieben.
Das hängt davon ab, ob Ihr Entwurf unter eine der eingeschränkten Klauseln in der Fundstelle der EN 18031 im Amtsblatt fällt. Wird die harmonisierte Norm vollständig angewendet und greift keine Einschränkung, entsteht die Konformitätsvermutung. Greift eine Einschränkung, und der Passwortfall ist der häufige, entsteht sie für diese Anforderung nicht, und die Konformität muss auf einem anderen Weg nachgewiesen werden. Wie viel Kapazität an notifizierten Stellen dafür besteht, können wir Ihnen nicht sagen, weil sich seit der NANDO-Umstellung keine Zahl aus dem Register beschaffen lässt.
Darauf hat niemand eine belastbare Antwort veröffentlicht. Wir haben nach begutachteten, von Verbänden veröffentlichten und von Normungsorganisationen stammenden Daten gesucht und keine gefunden, und die meistzitierte kursierende Zahl wird einer Studie zugeschrieben, die es nicht zu geben scheint. Schätzen Sie die Dauer aus Ihrer eigenen Qualifizierungshistorie und behandeln Sie jede externe Zahl, die man Ihnen zeigt, als unbelegt, bis ihre Methodik vorliegt.
Nach den jüngsten Primärdaten, die wir verifizieren konnten, nicht, und strukturell ebenfalls nicht. Im Februar 2026 war der Anteil der Befragten, die steigende Halbleiterlieferzeiten meldeten, auf 39 Prozent gefallen, von 52 Prozent einen Monat zuvor, aber nur 5 Prozent meldeten Rückgänge. Unter jeder Marktlage liegt ein Zyklus von der Fertigung bis ins Regal von rund 26 Wochen, den keine Nachfragelage verkürzt.
Die Retrospektive, die sagt, Ihr Hardwareprogramm sei in Verzug geraten, weil die Anforderungen instabil und die Teams nicht abgestimmt waren, liegt nicht falsch. Sie schöpft aus echter Forschung, die an echter Hardware betrieben wurde. Sie arbeitet nur aus einer der vier Forschungsgemeinschaften, die Krishnan und Ulrich benennen, und Kommunikationshardware verbringt ihren Kalender in den Anliegen einer anderen: in der Lieferanten- und Materialauswahl, in der Fertigungsfolge, in den Warteschlangen, die zwei Wochen Arbeit in sechs Monate verstrichene Zeit verwandeln.
Die praktische Folge ist ein Zielwechsel. Die Kosten je Korrektur steigen in der Hardware weniger steil, als die geborgte Softwarekurve nahelegt; die Jagd nach vermiedenen Fehlerkosten hat also weniger Hebel, als es scheint. Die Verluste liegen in der verstrichenen Zeit, und der größere Teil davon ist Warten, nicht Arbeiten. Drei dieser Wartezeiten tragen bereits ein Datum: den 11. September, den 12. September und den 15. November 2026. Das sind die, um die Sie heute planen können. Für den Rest, die noch nicht herausgegebene Abkündigung und den noch nicht gebuchten Nachprüftermin, planen Sie, indem Sie Puffer dort einbauen, wo die Uhr jemand anderem gehört, und indem Sie Ihre eigenen Warteschlangen messen, bevor die Warteschlange eines anderen Sie misst.
Teleconnect entwickelt und fertigt Kommunikationshardware gewerblich und hat ein unmittelbares wirtschaftliches Interesse am Gegenstand dieses Beitrags, einschließlich der oben genannten Leistungen in Hardware-, Firmware- und Leiterplattendesign. Der Beitrag nennt kein eigenes Produkt als Abhilfe für einen der Befunde.
Teleconnect ist Mitglied im HomeGrid Forum. Zwei Mitarbeiter unseres Unternehmens leiten gemeinsam dessen Task Force für industrielles IoT. Diese Mitgliedschaft hat keinen Einfluss auf die hier bewerteten Normen und Verordnungen, von denen keine durch dieses Forum verwaltet wird.
Die regulatorischen Termine in diesem Beitrag betreffen Pflichten, die für unsere eigenen Produkte ebenso gelten wie für die unserer Kunden. Wo dieser Beitrag berichtet, dass sich eine Zahl nicht verifizieren ließ, steht dieser Befund ohne Rücksicht darauf, ob eine verifizierte Zahl unsere kommerzielle Position gestützt hätte.
Alle europarechtlichen Angaben wurden am 8. und 9. August 2026 aus dem Text des jeweiligen Rechtsakts im Amtsblatt gelesen. Die in diesem Beitrag zitierten Vorschriften sind der amtlichen deutschen Fassung des Amtsblatts der Europäischen Union entnommen, abgerufen am 9. August 2026; es handelt sich nicht um Rückübersetzungen aus der englischen Sprachfassung. EUR-Lex beantwortet automatisierte Anfragen mit einer HTTP-202-Abfrage, weshalb die Seiten mit einer echten Browser-Engine geladen und die operativen Artikel aus dem gerenderten Text transkribiert wurden. Die Rechtsakte sind: Verordnung (EU) 2024/2847 (Cyber Resilience Act), Artikel 71 Absatz 2 für die Geltungstermine, Artikel 69 für die Übergangsbestimmungen und die Anhänge III und IV für die Produktklassen; Verordnung (EU) 2023/2854 (Data Act), Artikel 3 Absatz 1 für die Gestaltungspflicht und der Schlussartikel für den Geltungsbeginn; Delegierte Verordnung (EU) 2022/30 und Delegierte Verordnung (EU) 2023/2444 für den Geltungsbeginn der Cybersicherheitsanforderungen der Funkanlagenrichtlinie; Durchführungsbeschluss (EU) 2025/138 für die Fundstelle der EN 18031 und deren Einschränkungen, zitiert aus dem Anhang; und Durchführungsbeschluss (EU) 2025/893, Artikel 2 und Anhang Nummer 2, für die zum 15. November 2026 wirksamen Streichungen.
Die Literatur zur Produktentwicklung wird nach dem veröffentlichten Bestand zitiert. Wo nur ein Abstract oder eine Sekundärbeschreibung statt des Volltextes verfügbar war, wird nicht wörtlich zitiert und die Aussage auf dem Niveau formuliert, das die zugängliche Quelle trägt. Das betrifft Cooper und Kleinschmidt (1994), Gupta und Wilemon (1990), Crawford (1992), Zirger und Hartley (1996), Griffin (1997) sowie Clark und Fujimoto (1989). Gupta und Wilemon wird keine gerankte Liste von Verzögerungsursachen zugeschrieben, weil diese Tabelle nicht zu beschaffen war, und Zirger und Hartley aus demselben Grund keine Varianzaufklärung, sondern nur die Zahl der Techniken, die ihr Abstract als signifikant ausweist. Krishnan und Ulrich (2001) wurde für die zitierte Passage und die zitierte Tabelle direkt aus dem vom Autor bereitgestellten PDF gelesen, einschließlich der Zeilenbezeichnungen, der vier Community-Namen und der zitierten Inhalte der Zeilen Perspective on Product, Typical Performance Metrics und Critical Success Factors, alle aus Tabelle 1 transkribiert statt zusammengefasst. Die Aussage, dass die Durchlaufzeit in einer Spalte dieser Tabelle steht und in keiner anderen, ist eine Lesung aller vier Spalten. Zitate aus englischsprachiger Fachliteratur sind hier von uns ins Deutsche übertragen; die Bezeichnungen der Communitys und der Kennzahlenzeilen aus Tabelle 1 bleiben in der Originalsprache, weil sie als Etiketten der Autoren fungieren. Der Standish CHAOS Report wird nur nach Umfang und Stichprobe beschrieben; seine Zahlen werden nicht verwendet, aus Gründen, die in der begutachteten Kritik von Eveleens und Verhoef (IEEE Software 27(1), 2010) sowie Jørgensen und Moløkken-Østvold (Information and Software Technology 48(4), 2006) dokumentiert sind.
Herstellerangaben stammen aus dem Dokument des Herstellers selbst, nicht aus einem Distributorenkatalog oder einer Zusammenfassung Dritter: AMD-Mitteilung XCN23009 v1.0, JEDEC JESD48C sowie die veröffentlichten Langlebigkeitsprogramme von Texas Instruments und Microchip. Zwei dieser Originale werden von einem anderen Host als dem Herausgeber ausgeliefert, die AMD-Mitteilung von einem Dokumentenserver eines Distributors und JESD48C aus der öffentlichen Bibliothek eines Halbleiterherstellers. Das Dokument ist in beiden Fällen das unveränderte PDF des Herausgebers, und genau darauf kommt es hier an; eine von Dritten gehostete Paraphrase würde nicht genügen, weshalb die Langlebigkeitszahlen von NXP unten entfallen. Aussagen von Anbietern über die eigene Praxis sind als solche gekennzeichnet und nicht auditiert. Zwei Quellen tragen ein offengelegtes kommerzielles Interesse und sind an der Verwendungsstelle gekennzeichnet: die Abkündigungszählungen von Z2Data, deren Methodik nicht veröffentlicht ist, und der Benchmark-Bericht von Lifecycle Insights, der von einem Anbieter gesponsert ist. Die Avnet-Befragung ist eine nicht zufallsbasierte Stichprobe aus dem Kundenbestand eines Distributors auf dem Höhepunkt der Knappheit von 2021.
Nicht verifizierbar und daher nicht verwendet: jede Durchfallquote im ersten EMV-Anlauf; jede Messung des Kalenderanteils eines Hardwareprogramms, der auf Verifikation und Zertifizierung entfällt; jede Dauer einer Zweitquellenqualifizierung; jede Zahl der für die Cybersicherheitsanforderungen der Funkanlagenrichtlinie benannten notifizierten Stellen; jede Wartezeit akkreditierter Labore. Eine Angabe von 2,9 Layoutschleifen zu je 44.000 US-Dollar kursiert breit und ließ sich nicht mit dem Benchmark-Bericht in Übereinstimmung bringen, dem sie zugeschrieben wird und der ganz andere Größen ausweist; sie wird nicht verwendet. Anteile der Neuteileentwicklung, die Lieferanten in Japan, Europa und den Vereinigten Staaten tragen, werden häufig Clark und Fujimoto (1989) zugeschrieben; im hier zugänglichen Bestand stehen sie nicht und werden ebenfalls nicht verwendet. Der Geltungsbeginn der Maschinenverordnung (EU) 2023/1230 unterliegt einer ungeklärten Abweichung zwischen dem ursprünglichen Amtsblatttext und den nach der Berichtigung von 2023 berichteten Terminen; da diese Verordnung Kommunikationshardware als solche nicht regelt, wird sie ausgelassen statt unsicher wiedergegeben. Die Langlebigkeitszusagen von NXP fanden sich bei der Vorbereitung nur auf einer Spiegelung Dritter und werden daher nicht zitiert, obwohl das Programm nach unserem Kenntnisstand aktuell ist.