Termin vereinbaren

Sichere Software- und Produktentwicklung

Secure Software Development von der ersten Codezeile bis zum Feldeinsatz: Secure Coding, sicherer Entwicklungsprozess (SSDLC), Pipeline- und Lieferkettensicherheit, Produktsicherheit nach Produkttyp – CRA, IEC 62443, UN R155/R156 mit ISO/SAE 21434, MDR/IVDR.

Stand: Oktober 2026 · Valeri Milke, ISO 27001 & ISO 42001 Lead Auditor

Sichere Software- und Produktentwicklung (Secure Software Development) bedeutet, Sicherheitsanforderungen über den gesamten Lebenszyklus eines Produkts nachweisbar umzusetzen – vom Design über Code, Build und Release bis zur Schwachstellenbehandlung im Feld. Das maßgebliche Regelwerk hängt vom Produkttyp ab: Hard- und Software mit digitalen Elementen fällt unter den Cyber Resilience Act (CRA), auch Industriekomponenten; für sie gilt die Normenreihe IEC 62443 als Stand der Technik, für Maschinen ab dem 20. Januar 2027 zusätzlich die Maschinenverordnung. Fahrzeuge benötigen für die Typgenehmigung UN R155 und R156, meist mit ISO/SAE 21434 umgesetzt. Für Medizinprodukte gelten MDR und IVDR, mit IEC 81001-5-1 als Bezugspunkt. Typgenehmigte Fahrzeuge und Medizinprodukte sind vom CRA ausgenommen, weil eigenes Sektorrecht gilt.

Themen & Wissensseiten

Jedes Thema führt zu einer eigenen Wissensseite mit Vertiefung, Praxisleitfäden und den passenden Leistungen.

Produktsicherheit nach Produkttyp

Welche Cybersicherheitsanforderungen gelten, entscheidet der Produkttyp. Die vier Produkttypen im Überblick – mit Geltungsbereich, maßgeblichen Normen und Stichtagen; wo eigenes Sektorrecht greift, tritt der CRA zurück.

CRA – Produkte mit digitalen Elementen

Branchenübergreifende EU-Pflichten für Hersteller vernetzter Hard- und Software – von Planung und Entwicklung bis zur Schwachstellenbehandlung über den gesamten Lebenszyklus.

Produkte
Hard- und Software mit digitalen Elementen – vom Smart-Home-Gerät über Router und Betriebssysteme bis zur App
Regelwerk & Normen
Cyber Resilience Act; harmonisierte Normen (Reihen EN 40000 und ETSI EN 304) in Arbeit, noch keine im Amtsblatt; ENISA-Meldeplattform
Stichtage
In Kraft 10.12.2024 · Regeln für Benannte Stellen 11.06.2026 · Meldepflicht 11.09.2026 · volle Geltung 11.12.2027

IEC 62443 – Industrie & OT

Internationale Normenreihe für sichere Entwicklungsprozesse, Komponenten und Systeme der industriellen Automatisierung – freiwillig, aber anerkannter Stand der Technik und Basis künftiger harmonisierter CRA-Normen.

Produkte
Komponenten und Systeme der industriellen Automatisierung (OT), Steuerungen und Maschinen – für Hersteller, Integratoren und Betreiber
Regelwerk & Normen
IEC 62443-4-1 (Entwicklungsprozess), -4-2 (Komponenten), -3-3 (Systeme), -2-1 (Betreiber); CRA; Maschinenverordnung
Stichtage
Maschinenverordnung ab 20.01.2027 · Anpassung von EN IEC 62443-4-1/-4-2 an den CRA in Arbeit

Fahrzeuge – UN R155/R156 & ISO/SAE 21434

Cybersicherheit ist Voraussetzung der Typgenehmigung: Fahrzeughersteller brauchen ein zertifiziertes Cybersecurity-Managementsystem (CSMS) und ein geregeltes Software-Update-Management.

Produkte
Pkw, Busse und Lkw (M, N), bei Software-Updates auch Anhänger (O); neue Typen von Zwei-/Dreirädern und Quads (L) ab 11.12.2027
Regelwerk & Normen
UN R155 (CSMS), UN R156 (Software-Updates), ISO/SAE 21434 als Engineering-Standard; vom CRA ausgenommen
Stichtage
R155: neue Typen seit 06.07.2022, alle Neuzulassungen seit 07.07.2024 (Großserie) · R156: Bestandstypen seit 07.07.2026

Medizinprodukte – MDR & IVDR

IT-Sicherheit gehört zu den grundlegenden Sicherheits- und Leistungsanforderungen von MDR und IVDR – nachzuweisen vor dem Inverkehrbringen und fortzuführen über Marktüberwachung und Instandhaltung im Feld.

Produkte
Medizinprodukte und In-vitro-Diagnostika einschließlich Software als Medizinprodukt; vom CRA ausgenommen
Regelwerk & Normen
MDR/IVDR, MDCG 2019-16 Rev. 1, IEC 81001-5-1 (anerkannter Bezugspunkt, nicht harmonisiert), AI Act für KI-Medizinprodukte, Data Act für vernetzte Produkte
Stichtage
MDR seit 26.05.2021 · IVDR seit 26.05.2022 · AI-Act-Hochrisiko-Pflichten für KI-Medizinprodukte ab 02.08.2028
Beratung · AI Code Security

Wenn Regeln nicht mehr reichen: Code-Sicherheit im KI-Zeitalter

Regelbasierte Scanner finden zuverlässig Syntaxfehler. Gebrochene Autorisierung, Geschäftslogik und falsch angenommene Berechtigungen haben dagegen keine Signatur. Wir bringen Regeln, KI-Reasoning und Exploit-Validierung in eine Ordnung, die Ihr Team betreiben kann.

  • Layer 1–3 Scanning-Architektur
  • AI-SAST einführen und kalibrieren
  • Exploit-Validierung
  • Ownership & Remediation
  • Nachweise für CRA und NIS2
AI Code Security ansehen

Beratungsleistung — die Wissensseiten oben bleiben frei zugänglich.

Deep Dives

Vertiefende Wissensseiten zu den Themen, die aktuell die meisten Fragen aufwerfen — mit verifizierten Quellen und konkreten Maßnahmen.

KI-Risikomanagement Medizin

Wie Kliniken, Praxen und Labore KI-Systeme sicher betreiben: Betreiberpflichten nach dem AI Act im Zusammenspiel mit der MDR, geteilte Verantwortung mit dem Anbieter, ein Bedrohungsmodell für medizinische KI, Risikobewertung und belastbare Nachweise.

Zur Wissensseite

Instandhaltung Medizinprodukte

Wie Hersteller und Kliniken vernetzte Medizinprodukte im Feld sicher halten: mit Inventar und SBOM, klinisch begründeter Triage, Patches als kontrollierter Änderung, geordneter Schwachstellenmeldung und abgestimmten Meldewegen.

Zur Wissensseite

Data Act & Medizinprodukte

Wie Hersteller den gesetzlich geforderten Zugang zu Gerätedaten so gestalten, dass Patientensicherheit, Gesundheitsdaten und Geschäftsgeheimnisse geschützt bleiben – mit Bedrohungsmodell, Penetrationstest und integriertem Managementsystem.

Zur Wissensseite

Slopsquatting & Coding-Agenten

KI-Modelle schlagen Pakete vor, die es nicht gibt — und Angreifer können genau diese Namen registrieren. Coding-Agenten installieren mit Terminal-Zugriff, was sie für richtig halten. Dieser Deep Dive verbindet Typo- und Slopsquatting in npm und PyPI mit einem Sicherheitsmodell für Coding-Agenten und ihren Harness: Angriffskette, fünf Schutzschichten, Pflichten aus CRA, NIS2 und DORA, Self-Assessment und CISO-Whitepaper.

Zur Wissensseite

Automotive Threat Matrix

Wie die Auto-ISAC-Matrix Angreiferverhalten am Fahrzeug beschreibt – und wie sie TARA nach ISO/SAE 21434, den Nachweis nach UN R155, OWASP-Testkataloge und das Vehicle SOC auf eine gemeinsame Sprache bringt.

Zur Wissensseite

Secure Coding

Wie Sie Schwachstellen systematisch vermeiden: die aktuelle Landkarte aus CWE Top 25 und OWASP Top 10:2025, ASVS 5.0 als Anforderungsrahmen und die Praktiken, die im Entwicklungsalltag den Unterschied machen.

Zur Wissensseite
FAQ

Häufige Fragen zur Produktsicherheit nach Produkttyp

Welches Regelwerk gilt für welches Produkt – und wo greift der Cyber Resilience Act nicht? Kurze Antworten auf Fragen, die Hersteller und Verantwortliche für Regulatory Affairs häufig stellen.

Gilt der Cyber Resilience Act für Medizinprodukte?

Nein. Produkte, die unter die MDR oder die IVDR fallen, sind vom Cyber Resilience Act ausgenommen. Ihre Cybersicherheit regeln die beiden Medizinprodukte-Verordnungen; als Bezugspunkte dienen die Leitlinie MDCG 2019-16 Rev. 1 und die Norm IEC 81001-5-1, die bislang nicht harmonisiert ist. Software und Geräte ohne medizinische Zweckbestimmung – etwa allgemeine Klinik-IT – können dagegen sehr wohl unter den CRA fallen.

Gilt der CRA für Autos und Fahrzeugkomponenten?

Für typgenehmigte Pkw, Busse, Lkw und Anhänger nicht: Sie fallen unter die EU-Typgenehmigung, die Cybersicherheit über UN R155 und Software-Updates über UN R156 regelt. Die Ausnahme erfasst in der Regel auch Systeme und Bauteile, die für solche Fahrzeuge typgenehmigt werden. Seit 2025 sind per delegiertem Rechtsakt zudem Zwei- und Dreiräder sowie Quads ausgenommen; für neue Typen dieser Klasse gilt UN R155 ab dem 11. Dezember 2027. Nachrüstprodukte, Ladetechnik oder Apps außerhalb der Typgenehmigung können dagegen unter den CRA fallen. Ebenfalls im CRA bleiben Fahrräder mit Pedalantrieb der Klasse L1e.

Ist IEC 62443 Pflicht?

Nein, IEC 62443 ist eine internationale Normenreihe und kein Gesetz. Sie gilt jedoch als Stand der Technik für industrielle Komponenten und wird derzeit für den CRA aufbereitet – unter anderem durch Anpassungen von EN IEC 62443-4-1 und -4-2 sowie produktspezifische Profile. Die Vermutung, die gesetzlichen Anforderungen zu erfüllen (Konformitätsvermutung), entsteht erst, wenn eine harmonisierte Fassung im Amtsblatt der EU zitiert ist; Stand Oktober 2026 ist das nicht der Fall.

Ab wann gilt die CRA-Meldepflicht, und wo wird gemeldet?

Seit dem 11. September 2026 müssen Hersteller aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle über die zentrale Meldeplattform der ENISA (Single Reporting Platform) an das zuständige nationale CSIRT melden. Die Fristen: Frühwarnung binnen 24 Stunden, Meldung binnen 72 Stunden, Abschlussbericht spätestens 14 Tage nach Bereitstellung einer Korrektur, bei Vorfällen binnen eines Monats nach der Meldung. Die Pflicht gilt auch für Produkte, die schon vor dem Stichtag in Verkehr gebracht wurden.

Was ist der Unterschied zwischen UN R155 und ISO/SAE 21434?

UN R155 ist eine verbindliche Typgenehmigungsvorschrift: Ohne zertifiziertes Cybersecurity-Managementsystem (CSMS) erhält ein Fahrzeugtyp keine Genehmigung. ISO/SAE 21434 ist dagegen der Engineering-Standard, mit dem Hersteller und Zulieferer die geforderten Prozesse umsetzen, etwa die Bedrohungs- und Risikoanalyse (Threat Analysis and Risk Assessment, TARA). Die Norm ist nicht gesetzlich vorgeschrieben, aber der übliche Nachweisweg; Lücken wie den Bedrohungskatalog der R155 decken Hersteller gesondert ab.

Gibt es schon harmonisierte Normen für den CRA?

Noch nicht. Der Normungsauftrag der Kommission umfasst 41 horizontale und produktspezifische Normen. Nach einem Änderungsentwurf, der Stand Oktober 2026 nicht angenommen ist, sollen erste horizontale Normen bis Ende Oktober 2026 und produktspezifische bis Ende Dezember 2026 vorliegen. Solange keine Fassung im Amtsblatt zitiert ist, gibt es keine Konformitätsvermutung: Hersteller begründen die Erfüllung der Anforderungen eigenständig, und wichtige Produkte der Klasse I benötigen dann eine Benannte Stelle.

Machen Sie Sicherheit zum Teil Ihrer Entwicklung

Im Erstgespräch ordnen wir Ihren SSDLC-Reifegrad ein — und zeigen, welche Maßnahmen in Pipeline, Code und Produktzulassung den größten Hebel haben.