Raspberry Pi Imager now supports Android 17 for RPi 5
Get Android 17
Login
Start for free Book live demo

Three dates every device maker should know

The CRA (Regulation (EU) 2024/2847) applies in three steps:

December 2024

The CRA becomes law

Security becomes a product requirement for connected hardware and software sold in the EU.

11 September 2026

Reporting duties start

You report actively exploited vulnerabilities and severe incidents within 24 hours, also for devices you sold years ago.

11 December 2027

Full requirements apply

New devices need a support period, an SBOM in the technical documentation and integrity protection to get the CE marking.

When a vulnerability is exploited, the clock starts

You report to your national CSIRT and to ENISA, through ENISA's Single Reporting Platform. To report within 24 hours, you need to know in advance which components run on your devices.

24 h

Early warning

A first report within 24 hours of becoming aware: the affected product and the EU countries where it is sold.

72 h

Notification

Details on the vulnerability and how it is exploited, plus the measures you've taken or recommend to users.

14 days

Final report

Within 14 days after a fix is available. For severe incidents: one month after the notification.

Make sure to inform the affected users about the vulnerability and what they should do. More information in our blog article about CRA reporting: what Android device makers need today.

What the CRA asks of your OS, and how we help

On an Android device, most of the CRA's technical requirements sit in the operating system: the kernel, the Android framework, the chip vendor's BSP and the libraries around them.

We build and maintain these layers for you through the whole support period. Your apps and your hardware stay with you.

Android device with its software layers: your apps on top, then the Android framework, the Linux kernel and the BSP and drivers, which form the OS side with updates, SBOM and monitoring

Support period

What the CRA requires

A defined support period with security updates, as a rule at least 5 years.

How we help

At least 5 years of security updates per major Android version, included in the contract, and an upgrade before it ends. More on long-term support.

SBOM

What the CRA requires

A software bill of materials as part of the technical documentation.

How we help

Your OS pipeline creates an SBOM in SPDX format and release notes for every OS release.

Vulnerability handling

What the CRA requires

Know the vulnerabilities in your product and handle them without delay.

How we help

Monitoring of the OS components of your image (AOSP, kernel, BSP) and detection of known vulnerabilities (CVEs) that affect your devices. If one is reported as actively exploited, for example in Google's Android Security Bulletin, you hear from us directly.

Security updates

What the CRA requires

Fix vulnerabilities in the field through security updates.

How we help

Your OS pipeline turns a patch into a signed, traceable image. OTA updates install it on your test devices first, then on your fleet. Devices without a network update from a USB flash drive.

Integrity

What the CRA requires

Protect the software against unauthorized changes.

How we help

We offer secure verified boot, OS signing with your own keys, a check of every update before it installs, and rollback protection against older, vulnerable versions.

Documentation and reporting

What the CRA requires

Technical documentation, and reports to the CSIRT and ENISA.

How we help

We help with the OS part of your technical documentation and vulnerability reports. Device management logs changes and commands per device and shows its security status, such as ADB access and test or release keys.

Clear roles for both sides

As the manufacturer, you keep the CRA obligations. We take over the OS work behind them, continuously.

Your part as the manufacturer

  • Risk assessment of your product
  • Conformity assessment, EU declaration of conformity and CE marking
  • Reports to the CSIRT and ENISA, and information for your users
  • Your apps, your hardware and your custom drivers

Our part on the OS side

  • Security updates for at least 5 years per Android version
  • An SBOM and release notes for every OS release
  • Monitoring of the OS components and direct notices on vulnerabilities reported as exploited
  • Signed, traceable builds and OTA delivery to your fleet
  • Help with your technical documentation and your reports

If a supplier promises to take over the obligations themselves, be careful.

Where do you stand today?

Planning a new product generation

From 11 December 2027, a new device gets the CE marking only if it meets the CRA. The Android version, the BSP and the update path you choose now decide whether it will. We will help you plan them.

Develop a new device

Devices already in the field

The reporting duties also cover devices you sold years ago. You need to know what runs on them and how to ship fixes. Devices without OTA updates could still get them with one additional installation.

Upgrade existing devices

We hold ourselves to the same rules

We are part of your supply chain, so we follow the same practices:

  • Coordinated vulnerability disclosureResearchers report vulnerabilities to security@emteria.com, as described in our security policy.
  • Direct noticesIf a vulnerability in an Android version you use is reported as actively exploited, we tell you directly.
  • SBOM and release notesFor every OS release, so you always know what runs on your devices.
  • Your keys, traceable buildsReleases are built in OS pipelines and signed with your own keys.
  • End of support announced earlyYou learn early when support for an Android version ends and can plan the upgrade in time.
  • Hosted in the European UnionThe Emteria Hub runs in our European cloud, as a dedicated instance or on your own servers.
Security update flow: vulnerability found, patch in the base OS, your OS pipeline signs the image and creates the SBOM, test devices first, then OTA to your fleet

Frequently asked questions

Does the CRA apply to my Android device?

It applies to products with digital elements sold in the EU that connect to a device or a network, which covers most Android devices. It also applies to makers outside the EU who sell into the EU. Some products have their own rules, for example medical devices and vehicles. Ask your legal advisor about your specific product.

Do the reporting duties apply to devices we sold before 2027?

Yes. Since 11 September 2026, you report actively exploited vulnerabilities and severe incidents for every product in scope on the market, including devices sold long before December 2027. The full requirements apply to devices placed on the market from 11 December 2027.

Does working with Emteria make our device CRA compliant?

No supplier can do that for you: the obligations stay with you as the manufacturer. We take care of the OS side: the support period, security updates, an SBOM for every release, monitoring of the OS components and help with your documentation and reports.

Do we get an SBOM for every release?

Yes. Your OS pipeline creates an SBOM in SPDX format for every OS release, together with release notes.

How long do we get security updates?

At least 5 years for each major Android version, counted from its release and included in the contract. Before that ends, we upgrade your devices to a newer Android version. Longer support for one version is possible per contract, depending on the BSP.

Do you monitor vulnerabilities in our own apps?

We monitor the OS components: AOSP, the kernel and the BSP. Apps you preinstall and your custom drivers stay with you, unless we agree otherwise.

Our devices are offline. How do they get security updates?

Our OTA client installs updates from a USB flash drive, without a PC or tools. For closed networks, the Emteria Hub can also run on your own servers.

What happens when a critical vulnerability appears?

We patch our base OS, build and test it, and tell you. You build your image in your OS pipeline, test it on your devices and release it to your fleet. A response-time agreement is available on request.

How do I report a vulnerability in an Emteria product?

Send it to security@emteria.com. Our security policy explains what to include and what you can expect.

Start with a CRA check

We look at your device from the OS side and show you what the CRA means for your product.

  1. Tell us the device or SoC, its Android version and how many units are in the field.
  2. We check what's missing on the OS side: updates, SBOM, monitoring, update path.
  3. You get a plan: OS pipeline, support period and the update path to your fleet.
Book a CRA check

This page is an overview of the CRA from the OS perspective, not legal advice.