Termin vereinbaren
EU Cyber Resilience Act

EU Cyber Resilience Act (CRA) – Von der CRA-Gap-Analyse bis zur Konformitätsbewertung

Von der CRA-Gap-Analyse bis zur Konformitätsbewertung — Ihr Partner für sichere und CE-konforme Produkte.

Wir unterstützen Hersteller, Importeure und Händler bei der CRA-Compliance über den gesamten Produktlebenszyklus: Security by Design, Security by Default, Schwachstellenmanagement, Incident-Meldeprozesse und belastbare Nachweisführung.

0h
Meldefrist (kritisch)
0.2026
Meldepflicht aktiv
0.2027
Vollständige Anwendbarkeit
0 Schritte
zur CRA-Readiness

Hinweis: Der CRA verlangt Sicherheitsmaßnahmen über den gesamten Produktlebenszyklus — nicht nur beim initialen Release.

CRA Compliance — auf einen Blick

  • Security by Design & Security by Default
  • Meldepflichten und Vorfallprozesse
  • CE-Konformitätsbewertung für nicht-kritisch und kritisch
  • Synergien mit ISO 27001, IEC 62443 und SAE 21434
  • SBOM — Transparenz über Komponenten & Abhängigkeiten
  • Post-Market Schwachstellenmanagement
Security by Design
CE-Nachweisführung
Incident Management
Supply Chain Security
SBOM & Komponenten
ISO 27001 · IEC 62443
Webinar · VamiSec

Praxis-Session mit Valeri Milke und Hilding Karlsson

CRA in der Praxis: Product Security Lifecycle mit CI/CD, SBOM und AI-BOM

Status: Aufzeichnung (bereits stattgefunden) · Laufzeit ca. 1:28h

Diese Session zeigt den Weg von Security Requirements und Threat Modeling bis zu umsetzbaren DevSecOps-Controls in der Pipeline.

Mit konkreten Beispielen zu SAST, SCA, SBOM, Quality Gates, IaC-Checks und kontinuierlichem Vulnerability Management.

Webinar auf YouTube ansehen
CRA Kompakt

CRA in a Nutshell: Wie Sie Produkte cybersicher aufstellen

Der CRA bündelt Produktpflichten, Umgang mit Schwachstellen, Lieferkettentransparenz und Informationspflichten gegenüber Nutzenden in vier zentralen Säulen.

01

Produktanforderung

02

Umgang mit Schwachstellen

03

(Dritt-)Komponenten & Lieferkette

04

Mindestinformation der Hersteller

01

Produktanforderung

  • Angemessenes Cybersicherheitsniveau auf Basis einer Risikobewertung
  • Cybersicherheit in Entwicklung und Produktion (Security-by-Design)
  • Sichere Standardkonfiguration (Security-by-Default)
  • Schutz von Vertraulichkeit, Integrität und Verfügbarkeit
02

Umgang mit Schwachstellen

  • Meldungen zu Schwachstellen annehmen und regelmäßige Sicherheitstests
  • Angemessener Umgang mit identifizierten Schwachstellen
  • Kostenlose Sicherheitsupdates mit Benutzerinformation
  • Öffentliche Information zu Schwachstellen und Abhilfe
03

(Dritt-)Komponenten & Lieferkette

  • Software Bill of Materials (SBOM) für Transparenz der Komponenten
  • Sorgfaltspflicht bei Nutzung von Drittkomponenten
  • Nachverfolgung und Weiterleitung möglicher Schwachstellen an Lieferanten
04

Mindestinformation der Hersteller

  • Anlaufstelle für Informationen zu Schwachstellen
  • Produktidentifikation (Typ, Version u. a.)
  • Angaben zur bestimmungsgemäßen Verwendung
  • Zugänglichkeit der EU-Konformitätserklärung und ggf. SBOM
Warum jetzt handeln

CRA-Umsetzung ist ein Wettbewerbsfaktor, nicht nur eine Pflicht

Unternehmen, die frühzeitig starten, profitieren von besserer Risikotransparenz, stabileren Entwicklungsprozessen und schnellerer Marktzulassung. Späte Umsetzung erzeugt dagegen hohen Projekt- und Nachweisdruck.

Marktzugang sichern

Governance-Risiken steuern

Effizienz durch Integration

Marktzugang sichern

Nicht-konforme Produkte riskieren Vertriebsbeschränkungen. Eine belastbare Nachweisführung schützt Ihre Produkt-Roadmap.

Governance-Risiken steuern

Klare Prozesse für Reporting, Updates und Remediation reduzieren regulatorische und operative Risiken signifikant.

Effizienz durch Integration

Die Verknüpfung von ISMS, CSMS und Entwicklungsprozessen schafft Synergien statt zusätzlicher Bürokratie.

Frühstart

Der Vorsprung der Early Adopters

Konkrete Bausteine, wenn Sie den beschriebenen Vorsprung operationalisieren wollen:

0+

Vollständige Asset-Inventare

Systematische Erfassung digitaler Produkte, Komponenten und Abhängigkeiten.

0+

Vulnerability Management

Kontinuierliche Identifikation, Bewertung und Behebung mit klaren Reaktionszeiten.

0+

Dokumentationsprozesse

Strukturierte Erfassung von Maßnahmen, Risikobewertungen und Compliance-Nachweisen.

0%

Team-Schulungen

Entwicklungs- und Security-Teams kennen Secure-by-Design; Sicherheitskultur ist verankert.

Timeline und Fristen

EU CRA Timeline und Fristen

Diese Meilensteine definieren, wann Unternehmen ihre technischen, organisatorischen und regulatorischen Pflichten für CRA-konforme Produkte vollständig nachweisbar erfüllen müssen.

Klicken Sie auf einen Meilenstein für Details.

11.09.2026 — Meldepflichten aktiv

  • 24h Early Warning bei aktiv ausgenutzten Schwachstellen und schweren Vorfällen
  • 72h detaillierte Benachrichtigung mit Bewertung und Gegenmaßnahmen
  • Abschlussbericht innerhalb von 14 Tagen (Schwachstellen) / 1 Monat (Vorfälle)
  • Nationale Behörde und ENISA als Empfänger
Meldepflichten · Art. 14

Meldefristen und Inhalte nach CRA

CRA-Reporting ist keine reine Erweiterung des internen Incident Managements, sondern eine regulatorische Fristenarchitektur. Hersteller tragen Beweis- und Bewertungspflicht, wann ein Meldeauslöser vorliegt.

Kernaussage:Hersteller tragen Beweis- und Bewertungspflicht, wann ein Meldeauslöser vorliegt und wann die Frist beginnt — ab dem Moment der Awareness (hinreichende Sicherheit über den Vorfall).

Aktiv ausgenutzte Schwachstelle

Bestätigte aktive Ausnutzung einer Sicherheitslücke im Produkt mit digitalen Elementen.

Schwerwiegender Sicherheitsvorfall

Sicherheitsbeeinträchtigung des Produkts — Auswirkung auf Vertraulichkeit, Integrität oder Verfügbarkeit.

DetectionInitial AssessmentReasonable CertaintyReporting TriggerFrist beginnt
0Stunden
Schritt 01

Early Warning

Erstmeldung nach Eintritt der Meldepflicht — unverzüglich nach Kenntnis.

0Stunden
Schritt 02

Benachrichtigung

Vertiefende Zwischenmeldung mit Fakten, Bewertung und Gegenmaßnahmen.

0d / 1 Monat
Schritt 03

Final Report

Abschließender Bericht. Folgefristen je nach Auslöser (Schwachstelle / Vorfall).

Was melden?

Ausgenutzte Lücken, produktrelevante Vorfälle und risikorelevante Schwachstellen nach gesetzlicher Definition.

Wann melden?

Unverzüglich — erste Meldefrist in der Praxis oft bis zu 24 Stunden nach Kenntnis.

An wen melden?

Nationale Behörde, ENISA, ggf. CSIRT-Ecosystem bei kritischen Lagen.

Inhalt der Meldung

Sachverhalt, Produkte/Versionen, Risikobewertung, eingeleitete Gegenmaßnahmen.

Produkt-Risikoklassen

Konformitätslogik nach Produktkategorie.

Die Anforderungen steigen mit Kritikalität und Risikoprofil. Die korrekte Einstufung Ihrer Produkte ist der erste entscheidende Schritt.

Standard
25% Anforderungstiefe
Wichtig Klasse I
55% Anforderungstiefe
Wichtig Klasse II
78% Anforderungstiefe
Kritisch
100% Anforderungstiefe
KategorieProduktbeispieleAnforderungenBewertungsweg
StandardSmartphones, Steuer-Software, Saugroboter, vernetzte EndgeräteAnnex-I-Anforderungen, Basis-Risikobewertung, Update- & SupportkonzeptSelbsterklärung mit technischer Dokumentation
Wichtig IIAM/PAM, Browser, Passwortmanager, VPN, Router, Smart-HomeSecurity by Design/Default, durchgängiges VM, dokumentierte SSDLC-ProzesseErweiterte Nachweisführung und normative Orientierung
Wichtig IIFirewalls, IDS/IPS, Hypervisoren, Container-Runtimes, SicherheitschipsStrengere technische und organisatorische Kontrollen, belastbare AuditspurFormalisiertes Bewertungsverfahren, häufig Drittstellenbezug
KritischSmart-Meter-Gateways, kryptografische SicherheitshardwareHöchste Sicherheitsanforderungen, umfassende Tests und Compliance-NachweiseVerpflichtende Bewertung durch benannte Stellen (CABs)
Bewertungsverfahren

Baumusterprüfung (Modul B+C)

  • Ziel: Das Baumuster erfüllt die CRA-Cybersicherheitsanforderungen
  • Drittstelle bewertet das Produktmuster mit hohem Prüftiefgang
  • Jede wesentliche Änderung erfordert neue Drittstellenbewertung
  • Zeitintensiv bei vielen externen Nachprüfungen

Qualitätssicherungssystem (Modul H)

  • Ziel: Das QS-System stellt dauerhaft CRA-Konformität sicher
  • Drittstelle bewertet das Managementsystem statt Einzelmuster
  • System fängt wesentliche Änderungen fortlaufend ab
  • Ein System kann mehrere Produktlinien abdecken

Security by Design —
über den gesamten Lebenszyklus.

Der CRA verlangt Sicherheitsmaßnahmen nicht nur beim Release, sondern kontinuierlich — von der Entwicklung bis zum End-of-Life.

Unsere Leistungen

Für Ihre CRA-Compliance

Gap-Analyse & Compliance-Check

Bewertung Ihrer Produkte, Prozesse und Dokumentation im Hinblick auf die Anforderungen des CRA.

Integration von Security by Design

Beratung zur Implementierung sicherer Entwicklungsprozesse (Secure Development Lifecycle) und Einbindung von Bedrohungsanalysen (Threat Modeling).

Vulnerability- und Patch-Management

Aufbau von Prozessen zur kontinuierlichen Schwachstellenüberwachung, Risikobewertung und Update-Bereitstellung.

Dokumentation & Nachweisführung

Unterstützung bei der Erstellung der erforderlichen technischen Unterlagen, Konformitätserklärungen und Sicherheitsberichte.

Incident-Response & Meldeprozesse

Einführung klarer Abläufe für die Meldung und Behandlung von Sicherheitsvorfällen im Einklang mit den CRA-Vorgaben.

Schulungen & Awareness

Trainings für Produktentwicklung, Management und Compliance-Teams, um die neuen regulatorischen Anforderungen nachhaltig umzusetzen.

Digitales Tool

CRA Navigator: schneller Einstieg mit klaren Ergebnissen

Mit Fristen und Meldewegen im Blick ordnet der CRA Navigator Ihren Umsetzungsstand ein und liefert strukturierte nächste Schritte — ideal vor detaillierter Projektplanung oder Audit-Vorbereitung.

  • CRA Assessment zur Einordnung relevanter Anforderungen
  • Quick Gap Analysis für strukturelle Prozesslücken
  • Ergebnisreport mit klaren Handlungsempfehlungen
  • Ideal als Startpunkt vor detaillierter Projektplanung
CRA Navigator starten →
Vorgehensweise

5 Schritte zur belastbaren CRA-Readiness

Ein systematischer Weg von der ersten Analyse bis zur dauerhaften Compliance-Sicherung.

1

Gap-Analyse und Produktmapping

Abgleich von Produktportfolio, SSDLC und Betriebsprozessen gegen CRA-Anforderungen inklusive Risikoklassifizierung.

2

Priorisierter Maßnahmenplan

Technische und organisatorische Maßnahmen nach Risiko, Fristen und Abhängigkeiten strukturieren.

3

Technische Umsetzung & SSDLC-Härtung

SSDLC-Härtung, Threat Modeling, SBOM-Aufbau und Schwachstellenmanagement implementieren.

4

Dokumentation & Nachweisführung

Technische Dokumentation, CE-Nachweise und Konformitätserklärung auditfähig aufbauen.

5

Post-Market & Dauerbetrieb

Security-Updates, Patch-Management und kontinuierliches Monitoring sicherstellen.

Rollen im CRA

Pflichten nach Ihrer Rolle in der Lieferkette

Wählen Sie Ihre Rolle, um die spezifischen Anforderungen und empfohlenen Prioritäten zu sehen.

Kernpflichten für Hersteller

  • Technische Dokumentation, CE-Nachweise und Konformitätserklärung auditfähig halten
  • Security-by-Design und -Default im SSDLC implementieren und nachweisen
  • Schwachstellenmeldungen annehmen und Security-Updates kostenfrei bereitstellen
  • SBOM aufbauen und kontinuierlich aktuell halten

Empfohlene Prioritäten

Starten Sie mit Produktinventar, Risiko-Rating und SBOM-Grundlage. Danach SSDLC-Härtung, Incident-Meldewege und formalisierte Freigabeprozesse.

Jetzt beraten lassen
CE-Konformitätsbewertung

Ansatz für nicht-kritische und kritische Produkte

Die Konformitätsstrategie hängt direkt von Ihrer Risikoklasse und dem notwendigen Bewertungsweg ab.

Nicht-kritische Produkte

Eigenverantwortete CE-Nachweise

  • Technische Dokumentation nach CRA-Anforderungen aufbauen
  • EU-Konformitätserklärung und CE-Kennzeichnung vorbereiten
  • Security-by-Design, Updates und Vulnerability-Prozesse nachweisen
  • Auditfähige Evidenzen für Behörden und Kunden strukturieren
Kritische Produkte

Vorbereitung auf Drittstellenverfahren

  • Anforderungen für benannte Stellen / externe Prüfpfade vorbereiten
  • Prüfobjekte und Nachweise frühzeitig mit Produktteams abstimmen
  • Teststrategie inkl. Penetrationstests und Sicherheitsreviews konsolidieren
  • Dokumentations- und Auditpakete für den Konformitätsprozess finalisieren
Konformitätsprozess Schritt für Schritt
  1. 1

    Vorbereitung & Gap-Analyse

    • Bewertung bestehender Produkte und Entwicklungsprozesse
    • Abgleich mit CRA Annex I — Lücken identifizieren und priorisieren
  2. 2

    Technische Prüfung

    • Penetrationstests und Schwachstellenanalysen
    • Nachweise zu SBOM, Patch-Management und Logging
  3. 3

    Dokumentation & Nachweisführung

    • Technische Dokumentation (Security Concept, Risk Assessment)
    • Unterstützung bei der EU-Konformitätserklärung und Normennachweisen
  4. 4

    Konformitätsbewertung & Zertifizierung

    • Begleitung Selbstbewertung, Modul B+C oder Modul H
    • CE-Kennzeichnung und Marktüberwachung, Schnittstelle zu CABs
Dienstleistungen

Leistungsportfolio zur CRA-Compliance

Von der Gap-Analyse bis zur Zertifizierungsbegleitung — wir unterstützen Sie in jeder Phase.

Gap-Analyse & Beratung

Bestandsaufnahme, Gap-Bewertung und priorisierte Roadmap für eine prüfungsfeste CRA-Umsetzung.

Schwachstellenmanagement

Kontinuierliche Identifikation, Priorisierung und Behebung von Sicherheitslücken im Produktlebenszyklus.

CSMS / ISMS-Integration

Integration des CSMS in bestehende Governance-Strukturen für nachhaltige Compliance und weniger Verwaltungsaufwand.

Secure Development Lifecycle

Security by Design in Architektur, Entwicklung, Test und Betrieb mit klaren Security Gates. Ein Kreislauf mit kontinuierlicher Wartung und Verbesserung.

Anforderungen

Security Requirements Engineering, orientiert an IEC 62443.

Audit- und Zertifizierungsvorbereitung

Vorbereitung der Nachweispakete für CRA, IEC 62443 und SAE 21434 inklusive interner Audit-Simulation und Management-Review.

  • Technische Dokumentation und EU-Konformitätserklärung
  • Penetrationstests und Schwachstellenanalysen
  • Auditvorbereitung und Schnittstelle zu CABs
  • CE-Kennzeichnung und Marktüberwachungsunterstützung
Transparenz & Lieferkette

SBOM: Grundstein der CRA-Compliance

Ein Software Bill of Materials (SBOM) listet Komponenten und Abhängigkeiten wie eine Zutatenliste. Für die CRA ist das ein zentraler Transparenzbaustein: SPDX und CycloneDX decken gängige Anforderungen ab.

ISO/IEC 5962 · Standard

SPDX

Software Package Data Exchange — umfassend, formatflexibel und industrieweit etabliert.

  • ISO/IEC 5962 — international standardisiert
  • Umfassend und formatflexibel (JSON, YAML, RDF)
  • Breit unterstützt in Toolchains und CI/CD-Systemen
OWASP-Projekt · Security-fokussiert

CycloneDX

Security-fokussiertes SBOM-Format mit starker CI/CD-Integration für Vulnerability-Pipelines.

  • OWASP-Projekt mit Security-Fokus
  • Ideal für CI/CD und Vulnerability-Pipelines
  • Geeignet für automatisierte Compliance-Checks

Komponentenanalyse

Erkennen, bewerten und priorisieren von Risiken in Paketen, Abhängigkeiten und Lizenzen — inkl. Zuordnung zu bekannten CVEs.

CI/CD-Integration

Compliance nahtlos in die Pipeline: Anbindung an GitHub, GitLab, Jenkins u. a., damit SBOMs mit Builds mitlaufen.

Inventar-Hierarchien

Abbild komplexer Produktbäume (z. B. Gerät → Subsysteme → Firmware/Komponenten) für skalierbare Übersicht.

ENISA Playbook · CRA Annex I

Security by Design & Security by Default — die 22 Prinzipien.

Wie ENISA verbindliche Sicherheitsprinzipien des Cyber Resilience Act in zwei klare Säulen gliedert. Vier Kategorien, 22 konkrete Anforderungen.

Jedes der 22 Playbooks enthält: Zielsetzung · Checkliste · Mindestnachweise · Freigabe-Gate — strukturiert für kleine Teams ohne dedizierte Security-Spezialisten. TLP-CLEAR, frei zugänglich unter

enisa.europa.eu
ENISA Playbook22PrinzipienCRA Annex I Mapping

Security by Design14

Schutzmechanismen werden während der Entwicklung eingebettet — nicht nachträglich ergänzt. Zwei Kategorien:

Architektonische Grundlagen6
  • Vertrauensgrenzen (Trust Boundaries) und Threat Modeling
  • Prinzip der minimalen Rechte (Least Privilege)
  • Starke Identitäts- und Authentifizierungsarchitektur
  • Minimierung der Angriffsfläche
  • Mehrschichtige Verteidigung (Defense in Depth)
  • Offenes Design (kein Security through Obscurity)
Operative Integrität8
  • Lifecycle-Management
  • Nutzendenzentriertes Design
  • Secure-Coding-Praktiken
  • Logging, Monitoring und Alerting
  • Konfigurations- und Änderungsmanagement
  • Incident Response und Wiederherstellung
  • Vulnerability- und Patch-Management
  • Lieferkettenkontrollen

Security by Default8

Produkte werden mit der sichersten möglichen Konfiguration ausgeliefert — Nutzende benötigen keine technische Expertise für Basissicherheit. Zwei Kategorien:

Standard-Härtung — Auslieferungszustand so restriktiv wie möglich4
  • Minimierung aktivierter Standarddienste
  • Restriktiver Initialzugriff (keine admin/admin-Credentials)
  • Sichere Kommunikation als Standard (TLS 1.3, kein HTTP-Fallback)
  • Eindeutige Geräteidentität und Secrets als Standard
Geführter Schutz — Nutzende aktiv führen4
  • Verpflichtendes Security-Onboarding
  • Automatisierte Wartung und Updates
  • Transparente Sicherheitslage
  • Sichere Wiederherstellung und Eigentums-Lifecycle
Produktlebenszyklus

Security-Aktivitäten je Phase (KMU-Leitfaden).

Für jede Lebenszyklusphase definiert das Playbook konkrete Maßnahmen und einen minimalen Nachweis — damit Security auch in kleinen Teams nachweisbar verankert ist.

PhaseKern-AktionenNachweis
AnforderungenProduktkontext (Nutzende, Umgebungen, Daten), nicht verhandelbare Security-Defaults, Top-Risiken und Missbrauchsszenarien definierenSecurity Context & Assumptions (1 Seite) + Security-Requirements-Checkliste
DesignArchitekturdiagramm mit Trust Boundaries, leichtgewichtiges Threat Model für Top-5-10-Missbrauchsfälle, kritische Design-Controls festlegenArchitektur + Trust-Boundary-Diagramm + Top-Bedrohungen & Gegenmaßnahmen
EntwicklungSecure Defaults in Code/Konfiguration, Dependency-Hygiene, Secrets schützen, SAST/SCA in CI/CD automatisieren, PR-Reviews für sicherheitskritische ÄnderungenCI-Pipeline-Nachweis (Logs) + Secure-Coding-/PR-Checkliste
TestSAST/DAST automatisiert, Default-Konfiguration validieren, gezielter Penetrationstest bei wesentlichen ÄnderungenRelease-Security-Checkliste (Pass/Fail + Ausnahmen)
BereitstellungSicheres Provisioning, Least-Privilege-Runtime-Konfiguration, Security-Health-Monitoring, Updates als kontrolliertes Change ManagementBereitstellungs-Härtungs-Checkliste + Rollback-Plan
WartungPatch-SLAs, Vulnerability-Monitoring, Incident-Handling, EOL-Plan, sichere Datenlöschung und Credential-WiderrufVulnerability- und Patch-Prozess (1 Seite) + EOL-Notiz + aktualisiertes Risk Register

Wie VamiSec Sie dabei unterstützt

Das ENISA Playbook beschreibt was umzusetzen ist — VamiSec begleitet Sie beim wie: strukturiert, effizient und mit nachweisbaren Artefakten für Audits, CE-Konformität und Behörden.

Playbook-Reifegrad besprechen
  • Gap-Analyse gegen alle 22 ENISA-Prinzipien
  • Technische Dokumentation und CRA-Annex-I-Mapping
  • Release-Gate-Integration in Ihre Entwicklungsprozesse
  • Schulungen zu Threat Modeling und Secure Coding
Normung und Standardisierung

Fortschritt zentraler Normungsarbeiten im CRA-Umfeld

Die europäische Standardisierung ist für CRA-Umsetzung und Nachweisführung entscheidend.

CEN

Allgemeine Normung

Sektorübergreifende Standards und Grundanforderungen für Produkte und Dienstleistungen im digitalen Binnenmarkt.

CENELEC

Elektrotechnische Normung

Technische Sicherheitsanforderungen für elektronische Komponenten, Geräte und Industrieumgebungen.

ETSI

Telekommunikation

Netzwerk- und Kommunikationsstandards für digitale Infrastruktur, Schnittstellen und Security-Protokolle.

IEC 62443 (u. a. 4-1 / 4-2)

  • Secure Development Lifecycle (SDL)
  • Threat- und Risikoanalyse, Security Requirements
  • Sichere Implementierung, Vulnerability- & Patch-Prozesse

Strukturprinzipien (Schnittmenge)

  • Lifecycle-Orientierung
  • Kontinuierliches Schwachstellenmanagement
  • Nachweisbare Dokumentation und Security-by-Design

CRA im Normenabgleich

CRA-Produktpflichten (Annex I, Lieferkette, Meldewege) lassen sich direkt auf IEC 62443 / SAE 21434 Strukturen mappen — ideal für integrierte Audits mit weniger Doppelarbeit.

Governance

Cyber Security Management System (CSMS)

Das CSMS steuert den Produktlebenszyklus und verzahnt CRA mit ISMS, Datenschutz und weiteren Vorgaben. Aufbau nach IEC 62443-2-1 und SAE 21434 Kapitel 5 bereitet Konformitätsnachweise vor.

Aufbau & Integration

01
  • CSMS nach IEC 62443-2-1 / SAE 21434 Kap. 5
  • Einbindung in ISMS (ISO 27001 / 42001)
  • Governance, Rollen und Verantwortlichkeiten
  • Anbindung an Risiko-, Change- und Vulnerability-Management

Prozess- & Policy-Design

02
  • Unternehmensspezifisches Cyber-Security-Policy-Framework
  • Security-by-Design/Default in Entwicklung und Produktion
  • Klare Review-, Audit- und Dokumentationsprozesse

Nachweis & Audit

03
  • Mapping der CSMS-Controls auf CRA Annex I
  • Vorbereitung externer Audits und Zertifizierungen
  • Nachweisführung gegenüber Kunden, Behörden und benannten Stellen
Organisation

Security Champion im Entwicklungsteam

Security Champions sind keine Ersatz-Security-Abteilung, sondern Advocates und erste Anlaufstelle im Team — mit klarer Einbindung in NIS2, CRA und (bei Medizinprodukten) MDR.

Kein Ersatz für Security — sondern …

  • Nichtder alleinige Security-Experte oder die Security-Abteilung
  • Nichtallein verantwortlich für jede Sicherheitsentscheidung
  • SondernSecurity Advocate und Brücke zu Security & Compliance
  • SondernErste Ansprechperson im Team und Multiplikator für Awareness

Im Team · In der Organisation

Im Team: Security in Sprints, Code- und Design-Reviews, Schulung und Awareness.

In der Organisation: Anforderungen übersetzen, Feedback und Reporting, Risiken eskalieren, Community der Champions pflegen.

Security & Compliance
Security ChampionAdvocate & Bridge
Dev Team
Sprints
Code Reviews
Regulatory Context
NIS2CRAMDR
Erfolgsfaktoren: Management-Support · Training & Tools · dedizierte Zeit (z. B. 10–20 %) · feste Einbettung in die Teams

Unternehmen, die CRA, NIS2 und AI Act nicht isoliert betrachten, sondern in ein integriertes Managementsystem überführen, erzielen mehr Effizienz, bessere Auditfähigkeit und stärkere Resilienz.

Valeri Milke · CEO VamiSec GmbH
Praxisschulung

CRA Schulung für Management, IT und Produktteams

Kompakte und anpassbare Trainings zu CRA-Anforderungen, Rollen, Secure-by-Design, SBOM, Threat Modeling, Lieferkette und Haftung — mit praxisnahen Templates für den direkten Einsatz.

Schulungstermin vereinbaren
Synergien

CRA / IEC 62443 / SAE 21434 integriert denken

Ein harmonisierter Ansatz von Produktdesign bis Betrieb reduziert Mehrfachaufwand, verbessert Audit-Effizienz und schafft konsistente Nachweise über mehrere Regulatoriken hinweg.

  • Management-Support · Training & Tools
  • Dedizierte Zeit (z. B. 10–20 %)
  • Feste Einbettung in die Teams
Praxis-Tagesschulung

Cyber Resilience Act (CRA) — Secure Product Development in der Praxis

Tages-Curriculum: SSDLC, Compliance & Threat Modeling für Hersteller, Importeure und Händler.

1 Tag · ~7 hInklusive TemplatesInhouse oder remote
01

Europäische Cybersecurity- & Datenstrategie

  • Cybersecurity-Strategie der EU
  • Europäische Datenstrategie
  • CRA, Produkthaftung & Marktüberwachung
  • Abgrenzung zu NIS2, DORA & AI Act
02

Cyber Resilience Act (CRA) im Überblick

  • Anwendungsbereich & Ziele
  • Betroffene Produkte & Software
  • Rollen & Verantwortlichkeiten
  • Hersteller · Importeure · Händler
03

Zentrale CRA-Anforderungen

  • Cybersecurity-Mindeststandards
  • Secure-by-Design & Secure-by-Default
  • Schwachstellenmanagement & Disclosure
  • Update- & Patchpflichten
  • Dokumentations- & Nachweispflichten
  • Konformitätsbewertung & CE-Bezug
04

Technische Umsetzung in der Praxis

  • Secure Software Development Lifecycle (SSDLC)
  • CI/CD-Pipelines & Security Gates
  • SBOM (inkl. Tooling) & Open Source
  • Rechtskonforme Entwicklungsprozesse
05

Risikoanalyse & Threat Modeling

  • CRA-konforme Risikoanalyse
  • TARA-Vorlagen (Threat Analysis & Risk Assessment)
  • Attack Trees & Bedrohungsszenarien
06

CRA in der Lieferkette

  • CRA-Pflichten in der Lieferkette
  • Supplier Questionnaires (Software & Komponenten)
  • Haftung, Sanktionen & persönliche Verantwortung
Inklusive

Secure Development Templates

Sofort einsetzbare Vorlagen — am Ende des Tages mit dabei.

  • Secure Product Development Policy
  • Secure Coding & SSDLC-Richtlinien
  • TARA & Risk-Assessment-Templates
  • Attack Tree-Vorlagen
  • Supplier Questionnaires (CRA)

Was Sie nach dem Tag konkret tun können

1

CRA-Betroffenheitsprüfung

Klare Einordnung Ihrer Produkte unter CRA-Geltungsbereich.

2

Priorisierung nach Produkt & Risiko

Risikobasierte Reihenfolge für die Umsetzung im Portfolio.

3

Umsetzungs-Roadmap

Konkreter Fahrplan für Entwicklung & Produktmanagement.

Zielgruppe
GeschäftsleitungProduktverantwortlicheEntwicklung & DevOpsCompliance, Legal & Einkauf
Schulung anfragen
Do's and Don'ts

Praktische Leitlinien für CRA-Compliance

Do's

  • Security by Design und Security by Default im SSDLC verankern
  • Dokumentation laufend pflegen und evidenzbasiert strukturieren
  • Risikobewertungen regelmäßig durchführen und aktualisieren
  • Schwachstellen priorisiert patchen und Nachtests dokumentieren
  • CRA frühzeitig mit bestehenden Standards und Prozessen verzahnen

Don'ts

  • Incident-Reporting verzögern oder ohne Testprozess belassen
  • Kritische Risikoklassifizierungen nur informell behandeln
  • Veraltete oder bekannte verwundbare Komponenten ignorieren
  • Drittparteien und Lieferkette ohne Sicherheitskriterien steuern
  • Audit- und Nachweisanforderungen erst kurz vor Fristen starten
Vertiefung · Medizinprodukte

Threat Modeling für Medizinprodukte

Optional für Teams mit MDR-/SaMD-Bezug: strukturierte Bedrohungsanalyse mit regulatorischer Einordnung (MDR Annex I / GSPR, ISO 14971, IEC 62304, IEC 81001-5-1, CRA Secure-by-Design).

Threat Modeling verbindet Safety, Security und Compliance: nachvollziehbare Architektur, Trust Boundaries und Nachweise für Audits und benannte Stellen.

Schritt 01

Systemkontext

Architektur, Schnittstellen (Cloud, App, Klinik-IT), Datenflüsse, wichtige Assets.

Schritt 02

Assets & Schutzziele

Vertraulichkeit, Integrität, Verfügbarkeit; Einordnung zur Patientensicherheit.

Schritt 03

Bedrohungen

u. a. STRIDE, Missbrauchsszenarien, Lieferkette.

Schritt 04

Risikoanalyse

Eintrittswahrscheinlichkeit und Auswirkung; Anknüpfung an ISO 14971.

Schritt 05

Security Controls

Secure Boot, Authentisierung, Verschlüsselung, Logging, sichere Updates.

Schritt 06

Verifikation & Dokumentation

Traceability, Risikoakte, technische Dokumentation, Audit-Nachweise.

STRIDE — klicken Sie eine Kategorie für Details
SSpoofing: z. B. gestohlene klinische Zugangsdaten. Schutz: starke Authentisierung, MFA, Sitzungsmanagement.

Produkte cybersicher —
von der Entwicklung bis zum End-of-Life.

Der CRA macht Cybersicherheit zur Pflicht für alle digitalen Produkte auf dem EU-Markt.

FAQ

Häufig gestellte Fragen

OSPS Baseline · Open Source Project Security

Open-Source-Sorgfalt. CRA-konform und auditfähig.

62 Controls, 8 Kategorien, 3 Reifegrade — automatisch gemappt auf CRA Annex I, NIS2, ISO/IEC 18974, SSDF und SLSA. Ein Framework, eine Sprache, eine prüfbare Posture.

  • 8
    Kategorien · von Access Control bis Vulnerability Management
  • 3
    Reifegrade · Grundhygiene, Standardpraxis, High Assurance
  • 62
    Controls · jeder mit Mapping & Audit-Evidenz
  • 11+
    externe Frameworks gemappt · CRA · NIS2 · SSDF · ISO
Framework

Ein Mindeststandard für die Sicherheitshaltung von Open-Source-Projekten.

Die OpenSSF OSPS Baseline ist eine Sammlung konkreter Sicherheits-Anforderungen, die ein Open-Source-Projekt erfüllen sollte, um eine starke Sicherheitshaltung nachzuweisen. Statt vager Best Practices: 62 prüfbare MUST-Statements — gegliedert nach Kategorie und Reifegrad, gemappt auf die einschlägigen externen Frameworks.

Was es ist

Ein Set messbarer Controls — nicht ein Best-Practice-Wunschzettel.

Jeder Control ist als MUST formuliert, mit Anforderung, Empfehlung und konkreter Maturity-Zuordnung. Vom MFA-Zwang auf sensiblen Repo-Aktionen bis zur signierten Release-Manifest-Pflicht — alles prüfbar, alles in Code-Review, CI/CD oder Dokumentation verankert.

  • 62 MUST-Controls, gestaffelt über drei Reifegrade
  • Acht thematische Kategorien — von Zugriff bis Vulnerability Management
  • Mappings zu CRA, NIS2, SSDF, NIST 800-161, ISO/IEC 18974, SLSA, OpenSSF Scorecard, PCI DSS
Wofür es gut ist

Die Brücke zwischen Open-Source-Realität und Regulatorik.

CRA, NIS2 und der SSDF sprechen über Software Supply Chain — aber nicht in der Sprache von Maintainern. Die OSPS Baseline übersetzt: Was bedeutet „signed releases" konkret im Repo? Was ist „CVD policy with timeframe"? Welcher Reifegrad ist für mein Projekt angemessen?

  • Hersteller mit OSS im Produkt: nutzbarer Nachweis für CRA Art. 13 Lieferketten-Sorgfalt
  • Maintainer & Foundations: ein einheitlicher, externer Maßstab statt Self-Assessment-Wildwuchs
  • Konsumenten: ein gemeinsames Vokabular für Vendor- und Komponenten-Bewertungen
Struktur

Acht Kategorien — ein Bauplan für sichere Projekte.

Die Baseline gliedert ihre Controls in acht Domänen, die den Lebenszyklus eines Open-Source-Projekts abdecken. Jede Domäne adressiert eine konkrete Klasse von Bedrohungen — und jede wirkt über alle drei Reifegrade hinweg.

AC

Access Control

MFA, Least Privilege, Branch Protection.

BR

Build & Release

Pipelines, Signaturen, Secrets, SBOM.

DO

Documentation

User Guides, Verifikation, Support.

GV

Governance

Rollen, Beiträge, Reviewer-Vetting.

LE

Legal

OSI-Lizenzen, DCO/CLA, IP-Klarheit.

QA

Quality

Status-Checks, Tests, Sub-Projekte.

SA

Security Assess.

Design-Doku, Threat Modeling, APIs.

VM

Vuln. Management

CVD, VEX, SCA, SAST-Policies.

Reifegrad-Modell

Drei Stufen — vom Hygienefaktor zur Hochsicherheit.

Die Baseline kennt drei Reifegrade. Jede Stufe ergänzt die vorherige und reflektiert, wieviel Verantwortung ein Projekt seinen Konsumenten gegenüber trägt. Wer L3 erfüllt, erfüllt automatisch auch L1 und L2.

L3

High Assurance

20 Kontrollen
L2

Standardpraxis

18 Kontrollen
L1

Grundhygiene

24 Kontrollen
L3Für Projekte mit hoher Sicherheitsverantwortung.
  • Threat Modeling, VEX, SBOM, signierte Releases
  • Reviewer-Vetting & 4-Augen-Prinzip
  • Automatisierte SCA & SAST mit harten Gates
L2Ab 2 Maintainern und einer kleinen, festen Nutzerbasis.
  • Eindeutige Versionen, Changelogs, signierte Artefakte
  • CVD-Policy, private Vuln-Reports, Tests im CI
  • Design-Doku & API-Beschreibungen
L1Pflichtprogramm für jedes Repository.
  • MFA, Branch Protection, Least Privilege
  • User Guides, Lizenz, Security-Kontakte
  • Keine Secrets im Repo, keine Binaries im VCS

„Der Reifegrad ist keine Note — er ist die Antwort auf die Frage, wieviel Verantwortung ein Projekt seinen Konsumenten gegenüber trägt."

OSPS Baseline · Maintainer Guidance
Regulatorische Landkarte

Eine Baseline, viele Audits.

Die OpenSSF Baseline ist explizit auf globale Frameworks gemappt — du dokumentierst einmal, lieferst mehrfach.

Framework
Beschreibung
Baseline-Controls
EU CRA
Cyber Resilience Act 2024/2847 — voll wirksam ab 11.12.2027
AC-01, BR-06, VM-01, DO-03, SA-03
NIS2
EU-Direktive für wesentliche & wichtige Einrichtungen
GV-01, AC-02, VM-01, SA-03 (CSF-Mapping)
ISO/IEC 18974
OpenChain Security Assurance
QA-02, VM-01, DO-04, GV-03
NIST SSDF
Secure Software Development Framework (SP 800-218)
BR-01, BR-06, PW.1.2, PS.1, PS.2
PCI DSS 4.0.1
Payment Card Industry Standard
AC-01, BR-07, QA-06, VM-05

Insider-Tipp: Wenn dein Lieferant L2 erfüllt, hast du den Großteil des CRA-Lieferantennachweises bereits in der Tasche.

Approach

Vom Self-Assessment zur kontinuierlichen Evidenz.

Die Baseline ist ein Maßstab, kein Werkzeug. VamiGRC macht sie messbar: jeder Control wird als OSCAL-Profil hinterlegt, Evidenz-Anker gesetzt, Gap-Findings im Risk Register geführt — und die Cross-Framework-Coverage automatisch berechnet.

01

Gap-Analyse — alle 62 Controls.

VamiAudit prüft Repository, CI/CD-Konfiguration, Dokumentation und Release-Pipeline gegen die Baseline. Findings landen mit Owner und SLA im Risk Register — kein Excel.

OSCAL ProfileVamiAuditRisk Register
02

Cross-Framework Coverage.

Jede gelöste Baseline-Anforderung erfüllt gleichzeitig CRA-, NIS2-, SSDF- und ISO-Klauseln. Die Coverage-Matrix zeigt es auditfähig — implement once, satisfy many.

CRANIS2SSDFISO 18974
03

Continuous Evidence.

Branch-Protection, signierte Releases, SBOM, SAST-Status — alles wird kontinuierlich aus Repo und Pipeline gezogen, klassifiziert und auf der Trust-Center-Page sichtbar gemacht.

SBOMSLSATrust Center

Ganzheitliche CRA-Compliance

Ein Ansprechpartner. Zwei Expertisen. Von der technischen Produktprüfung bis zum Cyber Security Management System — alles aus einer Hand.

Valeri Milke
Ihr Ansprechpartner

Valeri Milke

Begleitet Sie persönlich durch Ihre CRA-Compliance — technisch wie organisatorisch.

Produktsicherheit
Technische Produktsicherheit

Technische Prüfung Ihrer Produkte entlang des gesamten Entwicklungszyklus — vom Design bis zur Konformitätsbewertung nach CRA.

  • Threat Modeling & Security-by-Design
  • Source Code Reviews
  • Security-Testing in CI/CD (SAST, SCA)
  • Penetrationstests
  • Konformitätsbewertung nach CRA
CSMS & Prozesse
CSMS, Organisation & Prozesse

Aufbau tragfähiger Security-Strukturen im Unternehmen — vom Managementsystem bis zu den Meldepflichten gemäß CRA.

  • Aufbau & Implementierung des CSMS
  • SSDLC-Prozesse & Security-Governance
  • Incident Management & PSIRT
  • Meldepflichten nach CRA (24 h / 72 h)
  • CRA-Compliance-Strategie

CRA-Compliance rechtzeitig sicherstellen

Von der CRA-Gap-Analyse bis zur Konformitätsbewertung – Ihr Partner für sichere und CE-konforme Produkte. Jetzt CRA-Experten buchen.

Erstberatung buchen