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 choose-your-own-adventure 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 evidence audit to the team. The secure defaults gap is the biggest problem. Nina immediately raises the installer issue.

The K400 is deployed by building contractors, not IT teams. In 40% of installations, the installer is a small firm with 2–5 employees and no dedicated IT staff. They use Telnet because SSH requires key management that their workflow doesn’t support. Disabling Telnet will generate hundreds of support calls and potentially delay deployments.

NINA BERGER — Product Manager

I have 340 support tickets in 6 months from installers who can’t complete SSH setup. That’s not theoretical — that’s lost revenue and delayed building handovers. If we disable Telnet, we need to give them something that actually works.

SOPHIE LAURENT — Head of Legal & Regulatory Affairs

The CRA requires secure default configuration. Telnet is an unencrypted protocol that transmits credentials in plain text. Shipping it enabled by default is a clear non-compliance. The question is how we address the installer workflow, not whether we address it.

JAN MULDER — VP of Engineering

We can’t lose 40% of our installer base. That’s not a compliance problem — that’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 setup wizard that runs on the K400’s built-in display during first-boot provisioning. It generates a key pair on-device, displays a QR code that the installer scans with their phone to complete pairing, and stores the key securely. No Telnet, no manual key management.

Testing with 12 installer firms shows: average setup time increases from 4 minutes (Telnet) to 6 minutes (wizard). Two firms needed a 15-minute phone call with support on the first try. After that, they were faster than Telnet because the QR code eliminated password entry entirely.

Nina is cautiously positive: ‘If the support call volume stays under 50 in the first month, this works.’ 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 be made available with a secure by default configuration, including the possibility to reset to the original secure state. ‘Secure by default’ means the product ships in its most secure usable state — the user must take deliberate action to reduce security, not the other way around. Replacing an insecure protocol with a secure alternative that matches the usability need is the gold standard: it eliminates 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 is disabled by default. A recessed button on the K400 panel activates Telnet when held for 5 seconds during the first 24 hours after factory reset. The display shows a warning: ‘TELNET ENABLED — UNENCRYPTED PROTOCOL — USE ONLY DURING INITIAL SETUP.’

Sophie reviews the approach: ‘This is defensible. The default is secure. The opt-in requires physical access and informed consent. But the notified body may ask why we didn’t eliminate the insecure protocol entirely — be prepared to document why the escape hatch is proportionate to the installer use case.’

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

Regulatory Reference

Proportionality in Secure Design

The CRA does not prohibit all insecure functionality — it requires secure defaults and informed user choice. Providing an opt-in mechanism for a less secure protocol can be compliant if: (1) the default is secure, (2) the user takes a deliberate, documented action to change it, (3) the risk is clearly communicated, and (4) the product can be reset to the secure state. The key is demonstrating proportionality — 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

The K400 v4.0 ships with Telnet enabled for the first 72 hours after boot. During the BSI Netherlands review, the assessor asks: ‘So the product ships in an insecure state by design?’ Tomasz explains the installer workflow. The assessor notes: ‘The CRA requires secure default configuration at the point of making available on the market. A 72-hour insecure window is not a secure default — it’s a scheduled vulnerability.’

The finding delays the conformity assessment by 4 weeks while Kastos implements a proper secure-by-default mechanism. The v4.0 ship date slips. Jan is furious: ‘We tried to save 3 weeks of development and lost 4.’

Regulatory Reference

Default Means Default

A product that ships with an insecure configuration — even temporarily — does not meet the CRA’s secure default requirement. The regulation assesses the state of the product at the point of placing on the market, not after a timer expires. ‘It secures itself later’ is not secure by default. It is insecure by default with deferred remediation. Market surveillance authorities and 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

With the secure defaults question addressed, you turn to the risk assessment. The existing 3-page threat model was written before the Module 1 vulnerability. It covers network-level threats but missed the BLE authentication bypass entirely. The CRA requires a risk assessment that covers the product’s intended purpose, reasonably foreseeable use, and the product’s lifecycle — including maintenance and end-of-life.

You have three options for the risk assessment scope, 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 CRA threat 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.’ This risk assessment must be documented in the technical file and updated when significant changes occur. A new firmware version after a critical vulnerability qualifies as a significant change.

OF

OPS FEED — Situation Feed

[10:05] COMPLIANCE — Risk assessment review: current document covers 3 of 7 CRA-required threat categories. BLE, physical access, firmware update, and supply chain categories 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 update the risk assessment with a single page on the BLE authentication bypass. The rest of the document remains unchanged from the v3.0 RED certification.

During the BSI Netherlands review, the assessor asks: ‘Your risk assessment covers network threats and the BLE bypass. What about physical access to the panel? Firmware update integrity? Supply chain risks for the 312 dependencies in your SBOM? The CRA requires the assessment to cover the intended purpose and reasonably foreseeable conditions of use.’

The assessor formally flags the risk assessment as insufficient. The conformity assessment is paused until a compliant risk assessment is produced. The v4.0 ship date is now uncertain.

Regulatory Reference

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

The CRA requires manufacturers to conduct a cybersecurity risk assessment before placing a product on the market and to update it when significant changes occur. The assessment must cover the product’s intended purpose, foreseeable conditions of use, and the entire product lifecycle. A risk assessment that covers only known past vulnerabilities is backward-looking — the CRA requires forward-looking assessment of the threats the product will face in deployment. A notified body will assess whether the risk assessment is proportionate to the product’s 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. The notified body needs it in 2 weeks. Your risk assessment is complete, the SBOM is current, and the secure defaults are implemented. But the penetration test results won’t be finalised for another 3 weeks — 1 week after the BSI Netherlands 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 technical file is complete when submitted — every section is final, every test is current. But the v4.0 ship date has now slipped by 3 weeks.

Jan is frustrated: ‘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.’ Sophie agrees: ‘A staged submission with transparent gaps is standard practice for notified body engagements. They’re used to reviewing sections in parallel. This was an unnecessary delay.’

The conformity assessment itself takes only 2 weeks — the file was thorough. But the total timeline is now 5 weeks longer than the parallel approach would have been.

Regulatory Reference

Working With Notified Bodies

Notified body engagements are not pass/fail exams — they are collaborative assessments. Assessors expect staged submissions and work in parallel across sections. Transparency about pending deliverables (like pen test results) is standard practice and does not signal non-compliance. Waiting for perfection before engaging wastes time that both parties could use productively. The goal is demonstrating conformity, not demonstrating that you can produce a perfect document in one submission.

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.

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

Situation Feed

Knowledge Check

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