The EU Cyber Resilience Act: What It Means for Raspberry Pi (and You)

EU Cyber Resilience Act (CRA) — implications for Raspberry Pi-based products

What the CRA is and when it matters

The video frames the EU Cyber Resilience Act (CRA) as new cyber-security obligations for products with digital elements (hardware or software).

Key timelines mentioned:

• 11 September: reporting requirements begin (for exploited vulnerabilities and severe incidents).
• December 2027: additional CRA requirements come fully into force.

Who is responsible (and why “manufacturer” includes many Raspberry Pi integrators)

The legislation is described as a shift from security being solely the user’s responsibility toward explicit obligations on the manufacturer.

In CRA terms, the “manufacturer” is the entity integrating and placing a product on the market, not necessarily Raspberry Pi itself. So, if someone repurposes Raspberry Pi into a specific device and sells it, they become the manufacturer with compliance and diligence duties.

CRA scope and product tiers

The CRA scope is characterized as very broad, covering many kinds of connected devices.

The video explains that products are categorized by risk/security profile:

• Lower risk
• Middle tier: includes detection features
• High-risk: on-device security is a primary function

Regardless of tier, it emphasizes security principles such as:

• Encryption and secure communications
• Device integrity measures (e.g., trusted boot)

Core technical requirements highlighted

The presenters emphasize two foundational capabilities:

• Trusted boot: devices boot only authenticated software.
• Encryption of data at rest: protect stored data.

They argue these should be incorporated early in product development.

How Raspberry Pi can help manufacturers comply (tools and engineering support)

Raspberry Pi is presented as providing capabilities that reduce compliance burden, including:

• Tools to create secure images that enforce authenticated software only
• Generation of a Software Bill of Materials (SBOM) for the built image to enable auditing and vulnerability scanning
• Provisioning/build tooling to support large-scale deployment, enabling secure properties from day one (e.g., secure boot and encrypted filesystems)

A major point: Raspberry Pi build tooling outputs an SBOM that matches exactly what gets deployed, reducing “SBOM drift,” especially when using immutable/read-only filesystem approaches.

Ongoing compliance after deployment: reporting exploited vulnerabilities

A central compliance mechanism described is the obligation to report:

• Exploited vulnerabilities
• Severe incidents

Reporting is described as multi-stage, with time windows:

• Report within 24 hours
• Provide mitigation planning within 72 hours
• Deploy mitigation (patch) typically within 14 days

The video stresses that firms may need the ability to patch entire fleets (thousands or tens of thousands of devices). It also notes the EU expects automatic over-the-air patching, with users able to opt out.

Updating and fleet management (Raspberry Pi Connect + A/B boot)

Raspberry Pi Connect is described not as a “patch tool” but as a secure communications channel (outbound initiated, avoiding inbound port/firewall requirements).

For field-safe updates, the video discusses an A/B update model:

• Two OS slots: one active and one inactive
• Update is staged to the inactive slot
• The device boots the new version, runs health checks, then commits it if successful
• If problems occur, the device can rollback, reducing “bricking” or outage risk

The presenters caution that manufacturers still must do their own QA/testing and verification.

How manufacturers know what to patch

The presenters distinguish between general CVEs and CRA-relevant issues:

• CRA reporting/obligations focus on vulnerabilities that are known to be exploited and capable of causing harm.

They also outline manufacturer duties to perform cyber security risk assessments, including:

• Evaluate the data handled (e.g., personal/banking info)
• Evaluate connectivity (e.g., cameras, network exposure)
• Consider potential harms (e.g., privacy breaches, botnets, DoS attacks)

Raspberry Pi’s role is described as:

• Running daily scans of packages included in Raspberry Pi OS (via a security page)
• Publishing vulnerability information so downstream manufacturers can correlate vulnerabilities to their SBOM/package versions

Fix ownership: upstream packages vs Raspberry Pi

The video emphasizes that responsibility for vulnerabilities is not always held by the manufacturer or by Raspberry Pi:

• For Raspberry Pi OS components based on Debian packages, upstream Debian maintainers are responsible for fixes.

Raspberry Pi positions itself as supporting manufacturers by pointing them to the appropriate upstream/community path when issues originate outside Raspberry Pi’s own maintained packages.

Practical “to-do” checklist presented to manufacturers

• Perform a risk assessment
• Build a minimal/hardened image to reduce attack surface (remove unnecessary components)
• Use encryption and trusted boot
• Use Raspberry Pi Connect for secure remote updates
• Continuously audit for new CVE occurrences, determine whether they impact the shipped build using the SBOM, and patch when relevant to exploited-harm scenarios

Video’s overall conclusion

The CRA creates new obligations—especially around reporting timelines and having the ability to update fleets.

The presenters argue that Raspberry Pi provides tooling and infrastructure that makes CRA compliance more achievable, while still requiring manufacturers to do diligence, testing, and ongoing vulnerability assessment.

---

Presenters / contributors

• James Hughes (Software Engineer, Raspberry Pi; technical support)
• Matthew Leair (Principal Software Engineer, Applications team; build system tooling/provisioning; customer support)