CRA-01 — EU Cyber Resilience Act

Zero Day

A vulnerability drops in your shipped product. The CRA reporting clock starts now.

THREAT LEVEL: GREEN

You are the Product Security Lead at Kastos IoT, a 340-employee Dutch company that manufactures smart building access control systems — hardware panels, a companion mobile app, and a cloud management platform. Your flagship product, the Kastos K400, is CE-marked and deployed across 2,800 commercial buildings in 14 EU member states. It is Tuesday, 14 December 2027 — three days after the CRA's full application date. A security researcher has just emailed your PSIRT inbox.

Kastos IoT — 340 employees, €62M revenue, HQ Rotterdam
K400 smart access panel: hardware + mobile app + cloud backend
CE-marked under CRA self-assessment (default category) in September 2027
SBOM generated for v3.2 firmware — top-level dependencies documented
PSIRT established 8 months ago. Vulnerability disclosure policy published
CRA vulnerability reporting obligation active since 11 September 2026

Mission Briefing

How This Works

This is a choose-your-own-adventure scenario. You’ll make real decisions that a Product Security Lead faces during a zero-day vulnerability — and your choices determine your final ops rating.

RAG Triage Activity

First, classify a queue of vulnerabilities by severity. This unlocks the live incident feed.

Three Decisions

Each decision is scored. Your choices determine a percentage-based ops rating. Wrong calls create cascading consequences.

Response Rating

Final score maps to five levels: Level 1 (Critical) → Level 2 (Deficient) → Level 3 (Adequate) → Level 4 (Effective) → Level 5 (Exemplary).

Legal References

Article references appear throughout — click them to read the relevant CRA article.

--:--:-- GREEN CRA-01: Zero Day

Situation Feed

Activity

Morning Vulnerability Queue

Practice round — not scored. Your score comes from the three decisions.

Tuesday, 08:15 CET — Your PSIRT queue has 4 items from the overnight period. Classify each by severity before you can respond.

--:--:-- RED CRA-01: Zero Day

Situation Feed

Incident Report

The Researcher's Email

Tuesday, 08:32 CET

You open the researcher's full report. Dr. Amara Osei, affiliated with TU Delft, has found a critical authentication bypass in the K400's BLE provisioning protocol. An attacker within Bluetooth range can bypass the pairing authentication and gain administrative access to the panel. She has captured network traffic showing active exploitation attempts targeting building management systems across Europe.

Her proof-of-concept works on v3.2 firmware — the current production version. She estimates 2,800+ panels are vulnerable. She is requesting a 30-day coordinated disclosure window.

CRITICAL — CRA Article 14 reporting clock initiated.

T-minus 23 hours 27 minutes to ENISA early warning deadline.

Actively exploited vulnerability confirmed.

Affected: K400 v3.2 firmware, ~2,800 deployed units.

You need to brief Jan and Sophie. This is real. You have a 24-hour window for the early warning, 72 hours for the detailed notification, and 14 days for the final report.

The first three markers are non-negotiable deadlines. Missing any of them triggers penalties under Article 64 — up to €15M or 2.5% of global annual turnover.

--:--:-- RED CRA-01: Zero Day

Situation Feed

Decision Required

First 60 Minutes

The CRA 24-hour clock is running. You need to brief leadership and begin the response. What is your first action?

--:--:-- RED CRA-01: Zero Day

Situation Feed

Situation Update

Outcome: Positive

Early Warning Filed

You file the ENISA early warning at 09:14 CET — 42 minutes after awareness. The notification includes: product name, firmware version, vulnerability type (authentication bypass), confirmation of active exploitation, and your contact details. You note that investigation is ongoing.

ENISA acknowledges receipt and forwards to the Dutch CSIRT (NCSC-NL). You now have until Thursday 08:32 for the detailed 72-hour notification.

At 09:30, you brief Jan and Sophie. Jan's first question: 'Do we need to pull the product from the market?' Sophie's answer: 'Not yet. But if we can't patch within the disclosure window, we need to discuss mitigation options with ENISA.'

Regulatory Reference

CRA Article 14 — The Reporting Timeline

The CRA requires three-stage reporting for actively exploited vulnerabilities: (1) Early warning to ENISA within 24 hours — this only requires awareness-level information, not a full analysis. (2) Detailed notification within 72 hours. (3) Final report within 14 days. Filing early does not create liability — failing to file does. The early warning is deliberately designed to be fast and incomplete.

--:--:-- RED CRA-01: Zero Day

Situation Feed

Situation Update

Outcome: Neutral

Verification First

You spend 3 hours verifying the researcher's claims. Your team confirms the vulnerability is real and reproduces the exploit on a lab K400 unit. At 11:45, you brief Jan and Sophie with confirmed technical details.

You file the ENISA early warning at 12:10 CET — 3 hours 38 minutes after awareness. Technically within the 24-hour window, but you've consumed time that could have been spent on patch development. ENISA acknowledges receipt.

SOPHIE LAURENT — Head of Legal

The early warning only requires what you know at the time. You didn't need to verify before filing. Next time, file first, verify in parallel.

Regulatory Reference

Speed vs. Accuracy

The CRA's early warning is designed for speed, not completeness. Waiting to verify before filing consumed 3 hours of your 24-hour window and delayed patch development. The early warning can and should be filed with partial information. The 72-hour detailed notification is where confirmed technical details belong.

--:--:-- RED CRA-01: Zero Day

Situation Feed

Situation Update

Outcome: Negative

Negotiating Instead of Reporting

You email Dr. Osei requesting a 90-day window. She replies at 10:15: 'I understand the patch timeline concern, but I have evidence of active exploitation. I cannot extend the window when people are at risk. I will publish in 30 days regardless.'

You have now spent 1 hour 43 minutes on disclosure negotiation instead of reporting. The ENISA notification has not been filed. The vulnerability is actively exploited.

SOPHIE LAURENT — Head of Legal

Leah, have you filed the ENISA notification yet?

When you explain you were negotiating with the researcher first, there is a long silence.

Regulatory Reference

Reporting Is Not Optional

The CRA's 24-hour reporting obligation is triggered by awareness of active exploitation — not by completion of internal processes, negotiations with researchers, or management approval. The researcher's timeline is between you and the researcher. The ENISA notification is between you and the law. Failure to notify within 24 hours: fine up to €15 million or 2.5% of global annual turnover.

--:--:-- RED CRA-01: Zero Day

Situation Feed

Incident Report

The SBOM Question

Tuesday, 14:00 CET

Your engineering team has begun patch development. The first question from the lead firmware engineer: 'Which components are affected?' You pull up the K400 SBOM.

The SBOM lists 47 top-level dependencies for firmware v3.2. But the triage queue flagged a zlib version mismatch this morning. Your lead engineer checks three more entries and finds two more discrepancies — one library is listed as v2.1 but the compiled binary contains v2.4, and another dependency was removed in the last release but still appears in the SBOM.

SBOM AUDIT — Firmware v3.2 dependency verification

MISMATCH zlib: documented 1.2.13, actual 1.3.1

MISMATCH libcrypto: documented v2.1, actual v2.4

GHOST DEP libfoo-legacy: listed but removed in v3.2 build

3 of 47 dependencies verified as incorrect. Full audit required.

JAN MULDER — VP Engineering

So our SBOM is wrong? How wrong? Can we even trust the dependency tree for the patch?

--:--:-- RED CRA-01: Zero Day

Situation Feed

Decision Required

SBOM Integrity

Your SBOM is inaccurate. The 72-hour detailed ENISA notification is due Thursday morning and must include affected components. What do you do?

--:--:-- RED CRA-01: Zero Day

Situation Feed

Situation Update

Outcome: Positive

SBOM Regenerated

The SBOM regeneration takes 5 hours. It reveals 7 discrepancies total — not just 3. Two additional libraries have known CVEs that were missed because the SBOM didn't reflect the actual versions bundled in the firmware.

The corrected SBOM feeds directly into the patch scope. Your 72-hour ENISA notification includes accurate dependency data. The patch addresses the authentication bypass and the two additional CVEs discovered through the SBOM audit. Total patch scope: 3 vulnerabilities, not 1.

JAN MULDER — VP Engineering

Better to find out now than from a market surveillance authority.

--:--:-- RED CRA-01: Zero Day

Situation Feed

Situation Update

Outcome: Neutral

Parallel Tracks

The patch for the authentication bypass is developed in 4 hours using the researcher's technical details. Meanwhile, the SBOM regeneration runs in parallel and completes 2 hours later. It reveals 7 total discrepancies — including 2 additional libraries with known CVEs.

The initial patch is correct but incomplete — it fixes the reported vulnerability but misses the two additional CVEs. You now need a second patch cycle. The 72-hour ENISA notification goes out on time with corrected SBOM data, but notes: 'Additional vulnerabilities identified during SBOM audit; supplementary patch in development.'

--:--:-- RED CRA-01: Zero Day

Situation Feed

Situation Update

Outcome: Negative

Filed with Inaccurate Data

You file the 72-hour notification with the current SBOM. The notification states that only the authentication bypass is affected. Three weeks later, during the post-incident review, the SBOM regeneration reveals the two additional CVEs.

SOPHIE LAURENT — Head of Legal

We submitted inaccurate component information to ENISA. Under CRA Article 64(4), providing incorrect or misleading information to authorities is a separate offence — fine up to €5 million or 1% of turnover. We need to file a correction and document why this happened.

--:--:-- RED CRA-01: Zero Day

Situation Feed

Activity

Product Category Assessment

Practice round — not scored. Your score comes from the three decisions.

Wednesday, 10:00 CET

SOPHIE LAURENT — Head of Legal

Are we sure the K400 is correctly classified as a default-category product? If it should be Important Class I or II, our self-assessment CE marking may be invalid. Sort these 8 product types into the correct CRA category.

--:--:-- AMBER CRA-01: Zero Day

Situation Feed

Decision Required

The CE Marking Question

Sophie's review concludes: the K400 should be classified as Important Class I, not default category. Your CE marking was based on self-assessment. Under the CRA, Important Class I products can self-assess only if conforming to harmonised standards — otherwise third-party assessment is required. Harmonised standards for access control products have not yet been published. What do you recommend to the board?

--:--:-- AMBER CRA-01: Zero Day

Situation Feed

Situation Update

Outcome: Positive

Notified Body Engaged

Kastos engages BSI Netherlands for third-party conformity assessment. New shipments are suspended for 6 weeks. The assessment costs €62,000. Existing deployed units are not affected — the obligation applies at the point of placing on the market.

The assessment confirms the K400 meets essential cybersecurity requirements (with the patched firmware). The updated CE marking and EU declaration of conformity are issued.

JAN MULDER — VP Engineering

Better 6 weeks now than a market withdrawal later.

--:--:-- AMBER CRA-01: Zero Day

Situation Feed

Situation Update

Outcome: Neutral

Continued Shipping

Kastos continues shipping while the notified body engagement is underway. Three weeks in, a Dutch market surveillance authority (RDI) contacts Kastos requesting the technical documentation and conformity assessment records for the K400.

The timing is not coincidental — your ENISA notification flagged the K400, and market surveillance authorities have access to the reporting platform. RDI notes the self-assessment for a product that appears to fall under Important Class I. They request a formal response within 30 days.

--:--:-- AMBER CRA-01: Zero Day

Situation Feed

Situation Update

Outcome: Negative

Classification Challenged

Kastos maintains the default category classification. Two months later, the European Commission publishes implementing guidance clarifying that 'products managing physical access to premises via network-connected systems' fall under Important Class I.

RDI opens a formal investigation. Under CRA Article 64(2), non-compliance with essential requirements and conformity assessment obligations can result in fines up to €15 million or 2.5% of global annual turnover.

SOPHIE LAURENT — Head of Legal

Three enterprise customers pause their K400 procurement pending the investigation outcome. Our competitor — who engaged a notified body 6 months earlier — picks up the contracts.

--:--:-- AMBER CRA-01: Zero Day

Situation Feed

Activity

The 14-Day Report

Practice round — not scored. Your score comes from the three decisions.

28 December 2027

Click through four phases of the CRA incident response timeline to see how your decisions shaped the outcome.

24 Hours

Early warning filed (or not). Internal response team activated. Researcher acknowledged. The 24-hour window tests your process, not your engineering — can you file a notification with incomplete information?

72 Hours

Detailed notification filed. SBOM accuracy determines patch scope. The 72-hour window tests your technical documentation — is your product inventory accurate enough to support a security response?

14 Days

Final report filed. Patch deployed to 2,800+ units via OTA update. Root cause analysis complete. The 14-day window tests your remediation capability — can you fix, deploy, and document within two weeks?

6 Months

Post-incident review. SBOM process integrated into CI/CD pipeline. Conformity assessment corrected (or challenged). Support period commitment reviewed. The question is not whether another vulnerability will be found — it's whether your process can handle it without a crisis.

--:--:-- GREEN CRA-01: Zero Day

Situation Feed

Incident Response Assessment

Response Rating

--

--%

Key Takeaways

1

File early, file fast. The CRA's 24-hour early warning is designed for speed, not completeness. File with what you know. The 72-hour and 14-day windows exist for detailed and final reporting.

2

Your SBOM is your incident response roadmap. If it's inaccurate, your vulnerability response will be incomplete. Integrate SBOM generation into your CI/CD pipeline so it always reflects the actual build.

3

Product classification determines your compliance path. Default, Important Class I/II, and Critical products have different conformity assessment requirements. Getting this wrong doesn't just mean regulatory exposure — it means your CE marking may be invalid.

4

The CRA treats inaccurate reporting as a separate offence. Submitting incorrect or misleading information to ENISA carries its own fine ceiling (€5M / 1% turnover). Accuracy matters — file corrections when you discover errors.

TAKE KNOWLEDGE CHECK →

Want to train your whole team? → blend.training