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.
Hinweis: Der CRA verlangt Sicherheitsmaßnahmen über den gesamten Produktlebenszyklus — nicht nur beim initialen Release.
Mit unserem CRA Gap-Analyse-Tool bewerten Sie in wenigen Minuten den Reifegrad Ihrer Produkte gegen die Anforderungen des Cyber Resilience Act – inklusive priorisiertem Maßnahmenbacklog, JSON-Export und Management-Report. Direkt im Browser, ohne Anmeldung.
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 ansehenDer CRA bündelt Produktpflichten, Umgang mit Schwachstellen, Lieferkettentransparenz und Informationspflichten gegenüber Nutzenden in vier zentralen Säulen.
Produktanforderung
Umgang mit Schwachstellen
(Dritt-)Komponenten & Lieferkette
Mindestinformation der Hersteller
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
Nicht-konforme Produkte riskieren Vertriebsbeschränkungen. Eine belastbare Nachweisführung schützt Ihre Produkt-Roadmap.
Klare Prozesse für Reporting, Updates und Remediation reduzieren regulatorische und operative Risiken signifikant.
Die Verknüpfung von ISMS, CSMS und Entwicklungsprozessen schafft Synergien statt zusätzlicher Bürokratie.
Konkrete Bausteine, wenn Sie den beschriebenen Vorsprung operationalisieren wollen:
Systematische Erfassung digitaler Produkte, Komponenten und Abhängigkeiten — inklusive maschinenlesbarer SBOM.
Kontinuierliche Identifikation, Bewertung und Behebung — aktiv ausgenutzte Schwachstellen sind binnen 24 Stunden zu melden.
Strukturierte Erfassung von Maßnahmen, Risikobewertungen und Nachweisen — die technische Dokumentation ist mindestens zehn Jahre aufzubewahren.
Entwicklungs- und Security-Teams kennen die 22 Secure-by-Design-Prinzipien des ENISA-Playbooks; Sicherheitskultur ist verankert.
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.
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).
Zuverlässige Belege, dass ein Angreifer die Schwachstelle ohne Erlaubnis des Systeminhabers ausgenutzt hat.
Vorfall, der die Fähigkeit des Produkts beeinträchtigt, Verfügbarkeit, Authentizität, Integrität oder Vertraulichkeit sensibler Daten oder Funktionen zu schützen — oder der Schadcode in das Produkt oder die Systeme der Nutzer bringt.
Unverzüglich, spätestens 24 Stunden nach Kenntnis — mit Angabe der Mitgliedstaaten, in denen das Produkt bereitgestellt wird.
Spätestens 72 Stunden nach Kenntnis: betroffenes Produkt, Art der Ausnutzung bzw. des Vorfalls, ergriffene und empfohlene Korrektur- und Abhilfemaßnahmen.
14 Tage nach Verfügbarkeit einer Korrektur- oder Abhilfemaßnahme (Schwachstelle) bzw. einen Monat nach der Meldung (Vorfall).
Aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle. Andere Schwachstellen, Cyberbedrohungen und Beinahe-Vorfälle können freiwillig gemeldet werden.
Unverzüglich: Frühwarnung spätestens 24 Stunden nach Kenntnis, Meldung nach 72 Stunden, danach der Abschlussbericht.
Über die zentrale ENISA-Meldeplattform an das koordinierende CSIRT des Mitgliedstaats der Hauptniederlassung — in Deutschland CERT-Bund im BSI — und zugleich an ENISA.
Betroffene Produkte und Versionen, Art und Schweregrad, ergriffene und empfohlene Maßnahmen. Zusätzlich sind betroffene Nutzer zu informieren.
Seit dem 11.09.2026 laufen alle CRA-Meldungen über die zentrale Meldeplattform (SRP) der ENISA. Unser Deep Dive zeigt, wie Sie die 24-Stunden-Frist zuverlässig halten — vom Zugang bis zum geprobten Meldepaket.
Die wesentlichen Anforderungen gelten für alle Produkte — risikobasiert umgesetzt. Mit der Kategorie steigt die Prüftiefe der Konformitätsbewertung. Die korrekte Einstufung Ihrer Produkte ist deshalb der erste entscheidende Schritt.
| Kategorie | Produktbeispiele | Worauf es ankommt | Bewertungsweg |
|---|---|---|---|
| ● Standard | Festplatten, Spiele, Bild- und Textverarbeitung, Saugroboter, vernetzte Haushaltsgeräte | Wesentliche Anforderungen risikobasiert erfüllen, technische Dokumentation, Updates über den gesamten Unterstützungszeitraum | Selbstbewertung durch den Hersteller (interne Kontrolle, Modul A) |
| ● Wichtig I | IAM/PAM, Browser, Passwortmanager, VPN, Router, Betriebssysteme, Smart-Home-Produkte mit Sicherheitsfunktion | Dieselben Anforderungen; Einstufung nach Kernfunktion begründen, Normenlage verfolgen | Selbstbewertung nur bei vollständig angewandten harmonisierten Normen oder EU-Zertifizierung — sonst benannte Stelle (Modul B+C oder H) |
| ● Wichtig II | Firewalls, IDS/IPS, Hypervisoren, Container-Runtimes, manipulationssichere Mikroprozessoren und -controller | Dieselben Anforderungen; Nachweise müssen einer externen Prüfung standhalten | Immer Drittprüfung: benannte Stelle (Modul B+C oder H) oder EU-Cybersicherheitszertifikat |
| ● Kritisch | Hardware mit Sicherheitsboxen, Smart-Meter-Gateways, Smartcards und Secure Elements | Dieselben Anforderungen; höchste Prüftiefe und lückenlose Nachweise | Europäisches Cybersicherheitszertifikat, sobald die Kommission es vorschreibt — bis dahin benannte Stelle wie bei Klasse II |
Bewertung Ihrer Produkte, Prozesse und Dokumentation im Hinblick auf die Anforderungen des CRA.
Beratung zur Implementierung sicherer Entwicklungsprozesse (Secure Development Lifecycle) und Einbindung von Bedrohungsanalysen (Threat Modeling).
Aufbau von Prozessen zur kontinuierlichen Schwachstellenüberwachung, Risikobewertung und Update-Bereitstellung.
Unterstützung bei der Erstellung der erforderlichen technischen Unterlagen, Konformitätserklärungen und Sicherheitsberichte.
Einführung klarer Abläufe für die Meldung und Behandlung von Sicherheitsvorfällen im Einklang mit den CRA-Vorgaben.
Trainings für Produktentwicklung, Management und Compliance-Teams, um die neuen regulatorischen Anforderungen nachhaltig umzusetzen.
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.
Ein systematischer Weg von der ersten Analyse bis zur dauerhaften Compliance-Sicherung.
Abgleich von Produktportfolio, SSDLC und Betriebsprozessen gegen CRA-Anforderungen inklusive Risikoklassifizierung.
Technische und organisatorische Maßnahmen nach Risiko, Fristen und Abhängigkeiten strukturieren.
SSDLC-Härtung, Threat Modeling, SBOM-Aufbau und Schwachstellenmanagement implementieren.
Technische Dokumentation, CE-Nachweise und Konformitätserklärung auditfähig aufbauen.
Security-Updates, Patch-Management und kontinuierliches Monitoring sicherstellen.
Wählen Sie Ihre Rolle, um die spezifischen Anforderungen und empfohlenen Prioritäten zu sehen.
Starten Sie mit Produktinventar, Risiko-Rating und SBOM-Grundlage. Danach SSDLC-Härtung, Incident-Meldewege und formalisierte Freigabeprozesse.
Jetzt beraten lassenDie Konformitätsstrategie hängt direkt von Ihrer Produktkategorie und dem notwendigen Bewertungsweg ab.
Von der Gap-Analyse bis zur Zertifizierungsbegleitung — wir unterstützen Sie in jeder Phase.
Bestandsaufnahme, Gap-Bewertung und priorisierte Roadmap für eine prüfungsfeste CRA-Umsetzung.
Kontinuierliche Identifikation, Priorisierung und Behebung von Sicherheitslücken im Produktlebenszyklus.
Integration des CSMS in bestehende Governance-Strukturen für nachhaltige Compliance und weniger Verwaltungsaufwand.
Security by Design in Architektur, Entwicklung, Test und Betrieb mit klaren Security Gates. Ein Kreislauf mit kontinuierlicher Wartung und Verbesserung.
Vorbereitung der Nachweispakete für CRA, IEC 62443 und ISO/SAE 21434 inklusive interner Audit-Simulation und Management-Review.
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.
Software Package Data Exchange — umfassend, formatflexibel und industrieweit etabliert.
Security-fokussiertes SBOM-Format mit starker CI/CD-Integration für Vulnerability-Pipelines.
Erkennen, bewerten und priorisieren von Risiken in Paketen, Abhängigkeiten und Lizenzen — inkl. Zuordnung zu bekannten CVEs.
Compliance nahtlos in die Pipeline: Anbindung an GitHub, GitLab, Jenkins u. a., damit SBOMs mit Builds mitlaufen.
Abbild komplexer Produktbäume (z. B. Gerät → Subsysteme → Firmware/Komponenten) für skalierbare Übersicht.
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.euSchutzmechanismen werden während der Entwicklung eingebettet — nicht nachträglich ergänzt. Zwei Kategorien:
Produkte werden mit der sichersten möglichen Konfiguration ausgeliefert — Nutzende benötigen keine technische Expertise für Basissicherheit. Zwei Kategorien:
Für jede Lebenszyklusphase definiert das Playbook konkrete Maßnahmen und einen minimalen Nachweis — damit Security auch in kleinen Teams nachweisbar verankert ist.
| Phase | Kern-Aktionen | Nachweis |
|---|---|---|
| Anforderungen | Produktkontext (Nutzende, Umgebungen, Daten), nicht verhandelbare Security-Defaults, Top-Risiken und Missbrauchsszenarien definieren | Security Context & Assumptions (1 Seite) + Security-Requirements-Checkliste |
| Design | Architekturdiagramm mit Trust Boundaries, leichtgewichtiges Threat Model für Top-5-10-Missbrauchsfälle, kritische Design-Controls festlegen | Architektur + Trust-Boundary-Diagramm + Top-Bedrohungen & Gegenmaßnahmen |
| Entwicklung | Secure Defaults in Code/Konfiguration, Dependency-Hygiene, Secrets schützen, SAST/SCA in CI/CD automatisieren, PR-Reviews für sicherheitskritische Änderungen | CI-Pipeline-Nachweis (Logs) + Secure-Coding-/PR-Checkliste |
| Test | SAST/DAST automatisiert, Default-Konfiguration validieren, gezielter Penetrationstest bei wesentlichen Änderungen | Release-Security-Checkliste (Pass/Fail + Ausnahmen) |
| Bereitstellung | Sicheres Provisioning, Least-Privilege-Runtime-Konfiguration, Security-Health-Monitoring, Updates als kontrolliertes Change Management | Bereitstellungs-Härtungs-Checkliste + Rollback-Plan |
| Wartung | Patch-SLAs, Vulnerability-Monitoring, Incident-Handling, EOL-Plan, sichere Datenlöschung und Credential-Widerruf | Vulnerability- und Patch-Prozess (1 Seite) + EOL-Notiz + aktualisiertes Risk Register |
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.
Die europäische Standardisierung ist für CRA-Umsetzung und Nachweisführung entscheidend.
Sektorübergreifende Standards und Grundanforderungen für Produkte und Dienstleistungen im digitalen Binnenmarkt.
Technische Sicherheitsanforderungen für elektronische Komponenten, Geräte und Industrieumgebungen.
Netzwerk- und Kommunikationsstandards für digitale Infrastruktur, Schnittstellen und Security-Protokolle.
CRA-Produktpflichten (Annex I, Lieferkette, Meldewege) lassen sich direkt auf IEC 62443 / ISO/SAE 21434 Strukturen mappen — ideal für integrierte Audits mit weniger Doppelarbeit.
Das CSMS steuert den Produktlebenszyklus und verzahnt CRA mit ISMS, Datenschutz und weiteren Vorgaben. Aufbau nach IEC 62443-2-1 und ISO/SAE 21434 Kapitel 5 bereitet Konformitätsnachweise vor.
Security Champions sind keine Ersatz-Security-Abteilung, sondern Advocates und erste Anlaufstelle im Team — mit klarer Einbindung in NIS2, CRA und (bei Medizinprodukten) MDR.
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.
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.
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 vereinbarenEin harmonisierter Ansatz von Produktdesign bis Betrieb reduziert Mehrfachaufwand, verbessert Audit-Effizienz und schafft konsistente Nachweise über mehrere Regulatoriken hinweg.
Tages-Curriculum: SSDLC, Compliance & Threat Modeling für Hersteller, Importeure und Händler.
Sofort einsetzbare Vorlagen — am Ende des Tages mit dabei.
Klare Einordnung Ihrer Produkte unter CRA-Geltungsbereich.
Risikobasierte Reihenfolge für die Umsetzung im Portfolio.
Konkreter Fahrplan für Entwicklung & Produktmanagement.
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). Medizinprodukte nach MDR/IVDR sind vom CRA ausgenommen — seine Secure-by-Design-Prinzipien sind trotzdem eine gute Referenz.
Threat Modeling verbindet Safety, Security und Compliance: nachvollziehbare Architektur, Trust Boundaries und Nachweise für Audits und benannte Stellen.
Architektur, Schnittstellen (Cloud, App, Klinik-IT), Datenflüsse, wichtige Assets.
Vertraulichkeit, Integrität, Verfügbarkeit; Einordnung zur Patientensicherheit.
u. a. STRIDE, Missbrauchsszenarien, Lieferkette.
Eintrittswahrscheinlichkeit und Auswirkung; Anknüpfung an ISO 14971.
Secure Boot, Authentisierung, Verschlüsselung, Logging, sichere Updates.
Traceability, Risikoakte, technische Dokumentation, Audit-Nachweise.
64 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.
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: 64 prüfbare MUST-Statements — gegliedert nach Kategorie und Reifegrad, gemappt auf die einschlägigen externen Frameworks.
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.
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?
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.
MFA, Least Privilege, Branch Protection.
Pipelines, Signaturen, Secrets, SBOM.
User Guides, Verifikation, Support.
Rollen, Beiträge, Reviewer-Vetting.
OSI-Lizenzen, DCO/CLA, IP-Klarheit.
Status-Checks, Tests, Sub-Projekte.
Design-Doku, Threat Modeling, APIs.
CVD, VEX, SCA, SAST-Policies.
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.
„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
Die OpenSSF Baseline ist explizit auf globale Frameworks gemappt — du dokumentierst einmal, lieferst mehrfach.
Insider-Tipp: Wenn dein Lieferant L2 erfüllt, hast du den Großteil des CRA-Lieferantennachweises bereits in der Tasche.
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.
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.
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.
Branch-Protection, signierte Releases, SBOM, SAST-Status — alles wird kontinuierlich aus Repo und Pipeline gezogen, klassifiziert und auf der Trust-Center-Page sichtbar gemacht.
Ein Ansprechpartner. Zwei Expertisen. Von der technischen Produktprüfung bis zum Cyber Security Management System — alles aus einer Hand.
Begleitet Sie persönlich durch Ihre CRA-Compliance — technisch wie organisatorisch.
Technische Prüfung Ihrer Produkte entlang des gesamten Entwicklungszyklus — vom Design bis zur Konformitätsbewertung nach CRA.
Aufbau tragfähiger Security-Strukturen im Unternehmen — vom Managementsystem bis zu den Meldepflichten gemäß CRA.
Von der CRA-Gap-Analyse bis zur Konformitätsbewertung – Ihr Partner für sichere und CE-konforme Produkte. Jetzt CRA-Experten buchen.
Erstberatung buchen
