Cyber Resilience Act: Was seit 11. September wirklich gilt
VamiSec
31 views
CRA Reporting Obligation Since September 11, 2026: 24 Hours – But When Does It Start?
Since September 11, 2026, the reporting obligations of the Cyber Resilience Act (CRA) have been in effect. Manufacturers of products with digital elements must actively report exploited vulnerabilities and serious security incidents via ENISA's Single Reporting Platform – with an early warning within 24 hours.
Sounds manageable? In this reality check, we show what lies behind this seemingly small obligation: Without functioning vulnerability management, incident response processes, reporting channels for customers, and a clear overview of your own software components, meeting the deadline is virtually impossible. And: The clock doesn't start ticking only after a body officially confirms the incident.
In a conversation with Hilding Karlsson (VamiSec GmbH), we clarify, among other things:
✅ What has been mandatory since September 11th – and what will only apply from December 2027 onwards
✅ When the 24-hour reporting period begins
✅ Why not every CVE is reportable: "affected" + "actively exploited"
✅ The deadlines at a glance: Early warning (24 hours), notification (72 hours), final report
✅ How realistic implementation is for SMEs without their own CSIRT
✅ Emergency patch management: When tests should be skipped
✅ What to do if there is no longer a patch for an open-source component?
✅ Single Reporting Platform: Access, roles, representatives – and (still) no API
✅ The role of the BSI in Germany
✅ Differentiation from NIS2 and DORA: When and where do you report?
✅ SBOM: Why it's already practically necessary and how deep it needs to go
✅ Responsibility for open-source components and "End of Maintenance"
✅ CRA meets AI Act: What applies to products with AI functions?
⏱️ CHAPTERS
00:00 Intro
00:40 Getting started: Reality check on CRA reporting obligations
01:38 What has been in effect since September 11th
03:13 Misconception: Not all CRA is in effect yet
03:52 Vulnerability & Incident Management as a prerequisite
04:23 Keycloak example: SBOM obligations through the back door
05:29 Providing reporting channels for customers
06:26 When does the 24-hour clock start ticking?
07:10 CVE Flood vs. Actively Exploited Vulnerabilities
09:23 24-hour, 72-hour, Final Report – Realistic for SMEs?
11:15 Remediation Measures & Emergency Patch Management
13:16 No Patch Available: Orphaned Open-Source Components
14:27 Platform Unreachable – What Now?
16:54 Single Reporting Platform: Access, Roles, API
19:58 The Role of the BSI and Expected Reporting Figures
23:12 Interaction with NIS2 and DORA
25:50 SBOM: How Deep Should It Go?
29:57 CycloneDX, SPDX, and Dependency Track
30:28 SBOM Also for Open-Source License Compliance
31:27 Who Is Liable for Open-Source Components?
32:32 End of Maintenance & Exit Strategy
34:32 CRA Meets AI Act and Data Protection
36:37 Threat Modeling: New for Over 90% of Manufacturers
38:09 Outlook on the Next Session
📌 KEY KEY POINTS
The 24-hour reporting period begins upon knowledge of the incident – not after internal coordination.
A vulnerability must be reported if you are affected AND it is being actively exploited.
Without a component overview, there is no impact assessment – the SBOM is therefore already de facto mandatory, even though it will not formally apply until December 11, 2027.
Open source does not absolve the manufacturer of responsibility: The manufacturer is liable for the entire product.
If the platform is inaccessible: Document the reporting attempt, contact the national CSIRT in an emergency, and submit the documentation later.
🔗 FURTHER LINKS
VamiSec GmbH: https://vamisec.com
LinkedIn: vamisec
https://vamigrc.com/
Want to know if your products fall under the CRA and if your reporting processes are up to standard? Contact us.
🔔 Subscribe to the channel so you don't miss the next Reality Checks – next time we'll delve deeper into End of Maintenance, AI security, and threat modeling.
Note: This video is for general information purposes only and does not constitute legal advice.
#CyberResilienceAct #CRA #ReportingObligation #SBOM #Cybersecurity #ENISA #BSI #NIS2 #VulnerabilityManagement #IncidentResponse #ProductSecurity #Compliance #CEO
Cyber Resilience Act: Was seit 11. September wirklich gilt
VamiSec
31 views
CRA Reporting Obligation Since September 11, 2026: 24 Hours – But When Does It Start?
Since September 11, 2026, the reporting obligations of the Cyber Resilience Act (CRA) have been in effect. Manufacturers of products with digital elements must actively report exploited vulnerabilities and serious security incidents via ENISA's Single Reporting Platform – with an early warning within 24 hours.
Sounds manageable? In this reality check, we show what lies behind this seemingly small obligation: Without functioning vulnerability management, incident response processes, reporting channels for customers, and a clear overview of your own software components, meeting the deadline is virtually impossible. And: The clock doesn't start ticking only after a body officially confirms the incident.
In a conversation with Hilding Karlsson (VamiSec GmbH), we clarify, among other things:
✅ What has been mandatory since September 11th – and what will only apply from December 2027 onwards
✅ When the 24-hour reporting period begins
✅ Why not every CVE is reportable: "affected" + "actively exploited"
✅ The deadlines at a glance: Early warning (24 hours), notification (72 hours), final report
✅ How realistic implementation is for SMEs without their own CSIRT
✅ Emergency patch management: When tests should be skipped
✅ What to do if there is no longer a patch for an open-source component?
✅ Single Reporting Platform: Access, roles, representatives – and (still) no API
✅ The role of the BSI in Germany
✅ Differentiation from NIS2 and DORA: When and where do you report?
✅ SBOM: Why it's already practically necessary and how deep it needs to go
✅ Responsibility for open-source components and "End of Maintenance"
✅ CRA meets AI Act: What applies to products with AI functions?
⏱️ CHAPTERS
00:00 Intro
00:40 Getting started: Reality check on CRA reporting obligations
01:38 What has been in effect since September 11th
03:13 Misconception: Not all CRA is in effect yet
03:52 Vulnerability & Incident Management as a prerequisite
04:23 Keycloak example: SBOM obligations through the back door
05:29 Providing reporting channels for customers
06:26 When does the 24-hour clock start ticking?
07:10 CVE Flood vs. Actively Exploited Vulnerabilities
09:23 24-hour, 72-hour, Final Report – Realistic for SMEs?
11:15 Remediation Measures & Emergency Patch Management
13:16 No Patch Available: Orphaned Open-Source Components
14:27 Platform Unreachable – What Now?
16:54 Single Reporting Platform: Access, Roles, API
19:58 The Role of the BSI and Expected Reporting Figures
23:12 Interaction with NIS2 and DORA
25:50 SBOM: How Deep Should It Go?
29:57 CycloneDX, SPDX, and Dependency Track
30:28 SBOM Also for Open-Source License Compliance
31:27 Who Is Liable for Open-Source Components?
32:32 End of Maintenance & Exit Strategy
34:32 CRA Meets AI Act and Data Protection
36:37 Threat Modeling: New for Over 90% of Manufacturers
38:09 Outlook on the Next Session
📌 KEY KEY POINTS
The 24-hour reporting period begins upon knowledge of the incident – not after internal coordination.
A vulnerability must be reported if you are affected AND it is being actively exploited.
Without a component overview, there is no impact assessment – the SBOM is therefore already de facto mandatory, even though it will not formally apply until December 11, 2027.
Open source does not absolve the manufacturer of responsibility: The manufacturer is liable for the entire product.
If the platform is inaccessible: Document the reporting attempt, contact the national CSIRT in an emergency, and submit the documentation later.
🔗 FURTHER LINKS
VamiSec GmbH: https://vamisec.com
LinkedIn: vamisec
https://vamigrc.com/
Want to know if your products fall under the CRA and if your reporting processes are up to standard? Contact us.
🔔 Subscribe to the channel so you don't miss the next Reality Checks – next time we'll delve deeper into End of Maintenance, AI security, and threat modeling.
Note: This video is for general information purposes only and does not constitute legal advice.
#CyberResilienceAct #CRA #ReportingObligation #SBOM #Cybersecurity #ENISA #BSI #NIS2 #VulnerabilityManagement #IncidentResponse #ProductSecurity #Compliance #CEO