CRA-02 — EU Cyber Resilience Act

Secure by Default

Your product ships in 8 weeks. The technical file says nothing about cybersecurity. Prove it was secure by design.

THREAT LEVEL: GREEN

You are the Lead Firmware Engineer at Kastos IoT. Four weeks have passed since the Zero Day — the authentication bypass that triggered Kastos’s first CRA incident response. The patch shipped. The SBOM was rebuilt. The notified body engagement is underway. Now comes the harder question: can you prove the K400 was secure by design? Your task: produce the technical documentation file required under CRA Article 31 for the K400 v4.0 firmware release. The existing file was written for the Radio Equipment Directive. It covers EMC and RF safety. It says nothing about cybersecurity.

Kastos IoT — 340 employees, €62M revenue, HQ Rotterdam
K400 v4.0 firmware release scheduled in 8 weeks
Current technical file: RED-compliant (EMC + RF safety), no cybersecurity section
SBOM rebuilt after Module 1 — now verified against build artifacts
Notified body (BSI Netherlands) engagement underway for Important Class I assessment
40% of installer base are small firms that struggle with SSH configuration

Mission Briefing

How This Works

This is a decision-driven scenario. You’ll make real decisions that a Lead Firmware Engineer faces when building a CRA-compliant technical file — and your choices determine your final ops rating.

Document Redline Activity

Review the existing technical file and flag the sections that fail CRA requirements.

Three Decisions

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

Risk Assessment Spectrum

Use a slider to find the proportionate depth for the K400’s cybersecurity risk assessment.

Clause Builder

Construct the Annex VII technical file by selecting the correct clause for each mandatory section.

--:--:-- GREEN CRA-02: Secure by Default

Personnel Briefing

Your Team

You’ll work with these four throughout the scenario. Their priorities conflict. Your job is to find the decision that holds up legally, technically, and commercially.

Tomasz Kowalski

Lead Firmware Engineer

Builds the product. Knows every dependency. Allergic to paperwork.

Nina Berger

Product Manager

Owns the ship date. Will push back on anything that slips the launch.

Sophie Laurent

Head of Legal & Regulatory Affairs

Keeps Kastos on the right side of the law. Speaks in regulatory citations.

Jan Mulder

VP of Engineering

Tomasz’s boss. Counts every sprint. Hates surprises from legal.

--:--:-- AMBER CRA-02: Secure by Default

Situation Feed

Situation Update

The Technical File

Monday, 09:15 CET

You open the K400 technical file. It was last updated for the v3.0 RED certification — 18 months ago. The file covers electromagnetic compatibility testing, radio frequency safety assessments, and electrical safety standards. Under ‘Security,’ there is a single paragraph: ‘The K400 uses AES-256 encryption for cloud communication.’

The CRA’s Annex VII requires technical documentation to include: a general description of the product, the cybersecurity risk assessment, a description of how essential requirements are met, the list of harmonised standards applied, the EU declaration of conformity, and the SBOM. Your file has one of these items partially addressed.

Sophie has forwarded the BSI Netherlands assessment timeline: the notified body needs the technical file in 6 weeks to complete their review before the v4.0 ship date.

OF

OPS FEED — Situation Feed

[09:15] DOCUMENTATION — K400 technical file review initiated. CRA Annex VII compliance: 1 of 6 required sections present (partial).

TOMASZ KOWALSKI — Lead Firmware Engineer

One paragraph on encryption. That’s it. We’re building this from scratch.

--:--:-- AMBER CRA-02: Secure by Default

Situation Feed

Activity

Technical File Redline

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

Monday, 10:30 CET

Before you start writing, you need to understand how far the existing technical file falls short. Review the K400’s current technical documentation and flag the sections that fail to meet CRA requirements. Click each problematic section to reveal the compliance gap.

--:--:-- AMBER CRA-02: Secure by Default

Situation Feed

Situation Update

The Telnet Question

Monday, 14:00 CET

You present the audit. The secure defaults gap is the biggest problem — and Nina has a counter.

The K400 is deployed by building contractors. 40% of installs are small firms with no IT staff. They use Telnet because SSH key management breaks their workflow. Disable it and the support queue explodes.

NINA BERGER — Product Manager

340 support tickets in 6 months from installers who can’t complete SSH setup. Lost revenue, delayed handovers. Kill Telnet and we need to give them something that works.

SOPHIE LAURENT — Head of Legal & Regulatory Affairs

Regulation 2024/2847 requires secure default configuration. Telnet sends credentials in plain text. Shipping it enabled is non-compliance. The question is how we fix the workflow, not whether.

JAN MULDER — VP of Engineering

Lose 40% of the installer base and this isn’t a compliance problem — it’s a survival problem.

--:--:-- AMBER CRA-02: Secure by Default

Situation Feed

Decision Required

Secure Defaults vs. Installer Workflow

The K400 currently ships with Telnet enabled by default. The CRA requires secure default configuration. 40% of installers rely on Telnet because SSH key management is too complex for their workflow. How do you resolve this?

--:--:-- GREEN CRA-02: Secure by Default

Situation Feed

Situation Update

Outcome: Positive

SSH Wizard Built

Your team builds a guided SSH wizard that runs on the K400’s display during first-boot provisioning. It generates a key pair on-device and shows a QR code the installer scans with their phone. No Telnet, no manual key management.

Testing with 12 installer firms: setup time rises from 4 minutes (Telnet) to 6 minutes (wizard). Two firms needed a 15-minute support call on the first try, then ran faster than Telnet because the QR eliminated password entry entirely.

Sophie documents the solution as evidence for the technical file.

Regulatory Reference

CRA Annex I Section 1(3) — Secure Default Configuration

Products with digital elements must ship in a secure by default configuration, with the option to reset to that state. The user must take deliberate action to reduce security, never the other way around. Replacing an insecure protocol with a secure alternative that matches the usability need is the gold standard: it closes the compliance gap without creating a business gap.

Nina Berger — Product Manager

“If the support call volume stays under 50 in the first month, this works.”

--:--:-- AMBER CRA-02: Secure by Default

Situation Feed

Situation Update

Outcome: Neutral

Physical Opt-In

Telnet ships disabled. A recessed panel button activates it when held for 5 seconds in the first 24 hours after factory reset. The display warns: ‘TELNET ENABLED — UNENCRYPTED PROTOCOL — USE ONLY DURING INITIAL SETUP.’

Sophie’s read: ‘Defensible. Default is secure, opt-in requires physical access and informed consent. But the notified body will ask why we kept the insecure protocol at all — document why the escape hatch is proportionate to the installer use case.’

Nina accepts: ‘60% won’t need it. The other 40% can press a button. Good enough.’

Regulatory Reference

Proportionality in Secure Design

Regulation 2024/2847 doesn’t prohibit all insecure functionality — it requires secure defaults and informed user choice. An opt-in to a less secure protocol can be compliant if: the default is secure, the user takes a deliberate documented action to change it, the risk is clearly communicated, and reset to the secure state is possible. The residual risk is accepted by the user, not imposed by the manufacturer.

Sophie Laurent — Head of Legal & Regulatory Affairs

“This is defensible. The default is secure. The opt-in requires physical access and informed consent. But be prepared to document why the escape hatch is proportionate to the installer use case.”

--:--:-- AMBER CRA-02: Secure by Default

Situation Feed

Situation Update

Outcome: Negative

Auto-Disable Workaround

K400 v4.0 ships with Telnet enabled for 72 hours after boot. During the BSI Netherlands review the assessor asks: ‘So the product ships insecure by design?’ Tomasz explains the installer workflow. The assessor: ‘A 72-hour insecure window isn’t a secure default. It’s a scheduled vulnerability.’

The finding delays conformity assessment by 4 weeks. Jan is furious: ‘We tried to save 3 weeks of development and lost 4.’

Regulatory Reference

Default Means Default

A product that ships insecure — even temporarily — fails Regulation 2024/2847’s secure default requirement. The regulation assesses the product at the point of placing on the market, not after a timer expires. ‘It secures itself later’ is insecure by default with deferred remediation. Notified bodies assess what the product does out of the box.

Jan Mulder — VP of Engineering

“We tried to save 3 weeks of development and lost 4.”

--:--:-- AMBER CRA-02: Secure by Default

Situation Feed

Situation Update

The Risk Assessment Gap

Wednesday, 10:00 CET

Secure defaults settled, you turn to the risk assessment. The existing 3-page threat model predates the Module 1 vulnerability and missed the BLE authentication bypass entirely. Regulation 2024/2847 requires an assessment covering intended purpose, reasonably foreseeable use, and the full product lifecycle — including maintenance and end-of-life.

Three options on the table, each with different cost, time, and thoroughness trade-offs.

Threat category	K400 attack surface	Current file	Required
Spoofing	BLE pairing identity	✗ missing	Mutual auth + cert pinning
Tampering	Firmware update package	⚠ partial	Signed updates + secure boot
Repudiation	Door/access audit log	✓ covered	Tamper-evident log
Info Disclosure	Cloud API + BLE provisioning	✓ covered	TLS 1.3 + LE Secure Connections
Denial of Service	BLE scan flood + cloud overload	✗ missing	Rate limiting + offline cache
Elevation of Privilege	Telnet (default-on) + JTAG	✗ missing	SSH-only + JTAG fused at production
Supply Chain	BLE stack + 23 single-maintainer libs	✗ missing	Component provenance + SBOM

3 of 7 categories covered. The BLE bypass that triggered Module 1 lives in the Spoofing row that isn’t written yet.

SOPHIE LAURENT — Head of Legal & Regulatory Affairs

Annex I Section 1 requires the manufacturer to deliver the product ‘on the basis of an assessment of the cybersecurity risks.’ Document it in the technical file. Update it on significant changes — a new firmware version after a critical vulnerability qualifies.

OF

OPS FEED — Situation Feed

[10:05] COMPLIANCE — Risk assessment review: 3 of 7 required threat categories covered. BLE, physical access, firmware update, supply chain missing.

--:--:-- AMBER CRA-02: Secure by Default

Situation Feed

Decision Required

Risk Assessment Scope

The existing risk assessment is incomplete. The v4.0 technical file needs a cybersecurity risk assessment that covers all CRA-required categories. The notified body needs it in 6 weeks. How do you scope the assessment?

--:--:-- GREEN CRA-02: Secure by Default

Situation Feed

Situation Update

Outcome: Positive

Full Threat Model

Your team spends 3 weeks building a comprehensive threat model using STRIDE methodology across all K400 interfaces. The assessment identifies 23 threat scenarios across 7 attack surfaces. For each, you document: the threat, the existing mitigation, the residual risk, and the CRA essential requirement it maps to.

The assessment reveals two medium-severity issues that weren’t on anyone’s radar: the firmware update mechanism doesn’t validate package signatures on download (only on install), and the mobile app stores the API key in plaintext in shared preferences. Both are fixed before v4.0 ships.

The notified body reviewer comments: ‘This is one of the more thorough risk assessments we’ve seen. The STRIDE mapping to CRA essential requirements is particularly useful.’

--:--:-- AMBER CRA-02: Secure by Default

Situation Feed

Situation Update

Outcome: Neutral

Update Plus Pen Test

You update the existing threat model in 1 week, adding BLE, physical access, firmware update, and supply chain threat categories. The external pen test begins the following week and covers the new attack surfaces.

The pen test finds the same two medium issues (unsigned firmware download, plaintext API key) plus one low-severity finding. You remediate all three before v4.0 ships. The combined internal assessment + external pen test provides solid evidence for the technical file.

Sophie notes: ‘The notified body will appreciate the independent verification. External testing strengthens the conformity argument. The only risk is timeline — if the pen testers find something critical, we’re back to a patch cycle.’

Sophie Laurent — Head of Legal & Regulatory Affairs

“The notified body will appreciate the independent verification. External testing strengthens the conformity argument. The only risk is timeline — if the pen testers find something critical, we’re back to a patch cycle.”

--:--:-- AMBER CRA-02: Secure by Default

Situation Feed

Situation Update

Outcome: Negative

Minimal Patch

You patch in a single page on the BLE bypass. Everything else stays as it was for the v3.0 RED certification.

The BSI Netherlands assessor pushes back: ‘You cover network threats and the BLE bypass. What about physical panel access? Firmware update integrity? Supply chain risk on the 312 SBOM dependencies? Regulation 2024/2847 requires intended purpose and reasonably foreseeable use.’

The risk assessment is formally flagged insufficient. Conformity assessment paused. The v4.0 ship date is now uncertain.

Regulatory Reference

CRA Annex I Section 1(2) — Risk Assessment Requirements

Conduct the cybersecurity risk assessment before placing on market, update on significant change. Cover intended purpose, foreseeable use, and full lifecycle. A backward-looking patch of known past vulnerabilities isn’t enough — the regulation requires a forward-looking view of the threats the product will face in deployment, proportionate to its complexity and risk profile.

--:--:-- AMBER CRA-02: Secure by Default

Situation Feed

Activity

Risk Assessment Depth

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

Week 4

The risk assessment scope is a trade-off. Drag the slider to set the depth of the K400’s cybersecurity risk assessment. Each position shows the cost, timeline, coverage, and regulatory defensibility. Find the position that balances thoroughness with the 6-week notified body deadline.

Minimal — patch the known BLE bypass only Exhaustive — full threat model + external pen test + red team engagement

0% 25% 50% 75% 100%

RISK: LOW

Full STRIDE threat model across all 7 attack surfaces. 3 weeks, €0. Complete coverage using internal expertise. Strong documentation but no independent validation.

The CRA requires a proportionate risk assessment — thorough enough to cover all foreseeable threats, but not so excessive that it delays market placement unnecessarily. The 50–75% range provides comprehensive coverage with defensible evidence. Going below 50% creates compliance gaps. Going above 75% is disproportionate to the product’s risk profile and misses the deadline.

--:--:-- AMBER CRA-02: Secure by Default

Situation Feed

Decision Required

The Technical File Deadline

The v4.0 technical file is taking shape. BSI Netherlands needs it in 2 weeks. Risk assessment done, SBOM current, secure defaults implemented. The pen test results land 3 weeks out — 1 week past deadline. What do you submit?

--:--:-- GREEN CRA-02: Secure by Default

Situation Feed

Situation Update

Outcome: Positive

Transparent Submission

BSI Netherlands accepts the staged submission. They begin reviewing the risk assessment, SBOM, secure default documentation, and architecture sections immediately. The pen test results arrive 3 weeks later and confirm the remediations. The conformity assessment completes on schedule — the 3-week extension was absorbed because the assessors worked on other sections in parallel.

Jan is relieved: ‘The ship date holds. And we didn’t cut corners on the file.’ Sophie adds the assessor’s feedback to the internal compliance library: ‘They appreciated the transparency about the pending pen test. It’s better to be clear about what you don’t have yet than to pretend you do.’

Jan Mulder — VP of Engineering

“The ship date holds. And we didn’t cut corners on the file.”

--:--:-- AMBER CRA-02: Secure by Default

Situation Feed

Situation Update

Outcome: Neutral

Old Test, New Context

You submit with the 14-month-old pen test. The BSI assessor notes: ‘This test was conducted on v3.0 firmware. The scope excludes BLE provisioning — the exact attack surface that was exploited 4 weeks ago. A new vulnerability was found and patched in v3.2. I cannot use a pre-vulnerability pen test as evidence for post-vulnerability conformity.’

The assessor requests the new pen test results before proceeding. The conformity assessment is not rejected — it’s paused on the testing section. Other sections proceed. Net delay: 2 weeks beyond original timeline.

--:--:-- AMBER CRA-02: Secure by Default

Situation Feed

Situation Update

Outcome: Negative

Delayed Submission

You push everything back 3 weeks. The file is complete on submission — every section final, every test current. But v4.0 ship has now slipped 3 weeks.

Jan is frustrated: ‘We could have submitted what was ready and let them review in parallel. We lost 3 weeks of revenue waiting for perfection.’ Sophie agrees: ‘Staged submission is standard for notified body engagements. Unnecessary delay.’

The assessment itself takes only 2 weeks — the file was thorough — but the total timeline is 5 weeks longer than parallel review would have been.

Regulatory Reference

Working With Notified Bodies

Notified body engagements under Regulation 2024/2847 are collaborative assessments, not pass/fail exams. Assessors expect staged submissions and review sections in parallel. Transparency about pending deliverables (pen test results, supplier confirmations) is standard practice, not non-compliance. The goal is demonstrating conformity, not producing a perfect document in one shot.

Jan Mulder — VP of Engineering

“We could have submitted the sections that were ready and let them review in parallel. Now we’ve lost 3 weeks of revenue because we waited for perfection.”

--:--:-- GREEN CRA-02: Secure by Default

Situation Feed

Activity

Annex VII — Build the Technical File

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

Week 6

The technical file needs 6 mandatory sections per Annex VII. Construct the file by selecting the correct clause for each section from the available options. Wrong combinations fail validation — the notified body won’t accept a file with missing or mismatched sections.

Module complete. Continue when you're ready. CONTINUE TO MODULE 3 →

--:--:-- GREEN CRA-02: Secure by Default

Situation Feed

Knowledge Check

Before seeing your results — four questions on the CRA. Select one answer per question.