CRA reporting: what Android device makers need today

Since 11 September 2026, the first part of the EU Cyber Resilience Act (CRA) applies. If someone exploits a vulnerability in your device, you have 24 hours to report it. That includes the devices you've already sold.

Device makers now want to know how long security patches will keep coming, whether they get an SBOM, and who helps them when they have to report something. On an Android device, most of these answers sit on the level of the operating system.

Since September, exploited vulnerabilities must be reported within 24 hours

The CRA (Regulation (EU) 2024/2847) became law in December 2024, but most of it applies later. The reporting obligations came first.

You report to the national CSIRT, the computer security team your country named as coordinator, and ENISA, the EU's cybersecurity agency. One submission through ENISA's Single Reporting Platform reaches both.

The clock starts when you learn that a vulnerability in your product is being actively exploited, or that a severe incident has hit its security:

• Within 24 hours: an early warning. It can be short, but it has to be on time.
• Within 72 hours: a notification with more detail, plus the measures you've taken or recommend to users.
• The final report: 14 days after a fix or workaround is available for a vulnerability, or one month after the notification for an incident.

You also tell the affected users what happened and what to do.

The reporting duty covers every product in scope on the market, including devices sold long before December 2027 (Article 69), like a kiosk fleet installed in 2023.

To report within a day, you need to know what runs on your devices

The 24-hour clock assumes you know what runs on your devices. When a new attack makes the news, you have hours to find out whether the affected component is even on them. On an Android device, that's a long list: the Linux kernel, the Android framework and its system services, the chip vendor's BSP with its drivers and firmware, libraries like OpenSSL and SQLite, and every app you preinstalled.

All of these get security fixes all the time. Google publishes an Android Security Bulletin every month. The Linux kernel ships stable releases about once a week, and chip vendors publish their own advisories. If your OS was built once for the product launch and never touched again, you lose track fast. A few months later, nobody can say for sure which of these fixes your devices are still missing.

In our experience, you need five things on the OS side:

• An SBOM for every OS release. It's the parts list of your image: every component, every version. With it, you can check a new vulnerability against your devices in minutes instead of days.
• Someone watching for vulnerabilities. A person or a tool that follows the advisories for exactly these components and checks them against your SBOM.
• A fast way to build a fix. A build process that turns a patch into a tested, signed image, without depending on one engineer's laptop.
• A simple way to ship it. OTA updates that reach the whole fleet, with a few test devices that always get updates first.
• A plan for the report. Who decides, who writes it and what goes in. Settle that before the first case comes in.

From December 2027, the CRA's full requirements will apply to all new devices

On 11 December 2027, the rest of the CRA applies. From then on, a product with digital elements needs the CE marking to be sold in the EU, and it only gets it if it meets the CRA's essential cybersecurity requirements. For the OS, three of them matter most:

• A support period. You commit to handling vulnerabilities and shipping security updates for a defined time, as a rule at least five years.
• An SBOM that is part of your technical documentation.
• Protection of the software's integrity. Nobody should be able to swap your software unnoticed. On Android, that means verified boot and signed updates.

Devices you put on the market before that date only have to meet these requirements if you substantially modify them later. But if you're planning a new product generation now, they apply from the very first unit you sell. The Android version, the BSP and the update process you pick in 2026 decide whether that product is ready for 2028.

Five years of security updates depend on your Android version

Google patches an Android version for less than five years. Android 13 came out in August 2022, and Google shipped its last security patches for it in March 2026, about three and a half years after its release.

Picture a device that launched on Android 13 in 2024, a common choice back then. It got two years of patches from Google. To reach five years, it has two options: an upgrade to a newer Android version, or someone who backports every security fix to Android 13 by hand. The BSP decides how hard either one is, because chip vendors often stop updating the BSP for an Android version long before the device leaves the market.

That's why we plan support per Android version. You get at least five years of security updates for each major Android version, counted from its release and included in the contract. For Android 14, released in October 2023, that means updates at least until October 2028. Before that ends, we upgrade your devices to a newer Android version, so your product stays supported for its whole life. If you need to stay on one Android version for longer, that's possible per contract, depending on the BSP.

Emteria automates the OS side of the CRA

We build and patch custom Android OS for device makers, either on BSPs we maintain ourselves, or on the chip vendor's official BSP. We put a lot of work into automating that process, so the routine work runs on its own and your team checks and approves. Nobody should have to build images by hand on a Friday afternoon because a CVE just dropped.

On the OS side, we help you meet your CRA obligations with:

• Automated OS pipelines. Your Android image is built by a pipeline in the Emteria Hub. Every build runs the same way, and you can trace each image back to its sources.
• An SBOM for every release. Each build creates its SBOM automatically, so nobody has to put the parts list together by hand.
• Your own signing keys. Images and updates are signed with your own keys, so only software you approved runs on your devices.
• Vulnerability monitoring. Our team watches the components in your OS and tells you what affects your devices. Automated monitoring for all customers is in development.
• Security patch delivery. Fixed images reach your fleet as OTA updates. A separate testing workspace gets them first, so you can check each update on test devices before the production fleet.
• Documentation and reporting. We help with the OS part of your technical documentation and with your vulnerability reports.

The obligations stay with you as the manufacturer, and we'd be careful with anyone who says otherwise. What we take off your plate is the OS work behind them, as a steady process instead of a project that starts the day the first report is due.

If you sell Android devices in the EU, talk to us. Tell us the device or SoC, the Android version it runs and how many units are in the field. We'll show you what the OS side of the CRA looks like for your product.

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