Short answer for procurement teams: The EU Cyber Resilience Act (Regulation (EU) 2024/2847) makes a supplier’s software-security and update commitment a legal requirement for any connected tablet sold in the EU — not a nice-to-have. Reporting obligations for actively exploited vulnerabilities begin 11 September 2026 (even for devices already on the market), and the full manufacturer obligations — CE marking tied to security requirements, a minimum support period, secure-by-default design — apply from 11 December 2027. A general-purpose Android tablet falls in the “default” CRA category, so the obligations are real but not as heavy as “important” or “critical” devices. The practical effect: you must now ask OEMs for a written, contractually-backed update-and-vulnerability policy before you sign an RFQ.
Why the CRA changes how you buy a tablet
Before the CRA, “how long will you support the OS?” was a negotiation point. After December 2027 it becomes a compliance liability that sits on the importer’s and distributor’s shoulders too. If you bring a tablet into the EU and the manufacturer stops patching a known exploited vulnerability, you — the brand or distributor — carry part of the market-surveillance risk. That flips the sourcing conversation: instead of “what’s the cheapest quote,” the decision becomes “which OEM can document a defensible security posture for the full product lifetime.”
The deadlines that actually matter
- 10 December 2024 — CRA enters into force (Regulation (EU) 2024/2847 published in the Official Journal).
- 11 September 2026 — manufacturers and importers must report actively exploited vulnerabilities and severe security incidents to ENISA / national CSIRTs within the 24h/72h framework. This applies to products already on the market, including devices you may already be reselling.
- 11 December 2027 — the bulk of obligations apply: essential security requirements, CE marking (now covering cybersecurity, on top of the existing CE red mark / RED), a minimum support period, and security-update duty throughout it.
A general-purpose Android tablet is a “default” category device — not “important” (Category I) or “critical” (Category II). That classification keeps the paperwork manageable, but it does not exempt you from the CE marking or the support-period obligation.
What this means in an RFQ (the checklist)
| RFQ line item | Why it matters now | What to demand from the OEM |
|---|---|---|
| Guaranteed security-update window | CRA requires security updates throughout the support period; vague “will do our best” language won’t survive market surveillance. | Written minimum OS + security-patch period in the contract (e.g. 3–5 years), not just in a marketing datasheet. |
| Named support contact for vulnerability reports | 24h/72h reporting to ENISA only works if the OEM has a real PSIRT-style process. | A documented vulnerability-handling email/process + SLA in the supply agreement. |
| OS version & patch cadence | Secure-by-default design is now a CE precondition, and old Android versions are a top exploit vector. | Current Android version + published patch cadence; confirm the board/SoC vendor still issues CVEs for it. |
| CE technical file covering cybersecurity | CE marking now spans security requirements, not just RED/EMC. | Access to the declaration of conformity and the supporting risk-assessment documentation. |
| Post-sale update liability allocation | Importers/distributors share surveillance exposure if the upstream manufacturer stops patching. | Contract clause on who owns patching for devices already deployed if the OEM ends support early. |
The risk if you ignore it
Two real scenarios. Scenario 1: you buy a batch of inexpensive tablets, the SoC vendor drops support a year in, and a widely exploited CVE hits the device. From 11 September 2026 you may be obliged to report it, and from 2027 your CE-marked product is non-compliant. Scenario 2: your competitor brands the same hardware under a better contract with a supplier who documents a full support lifecycle — and you lose the tender on a compliance checkbox, not on price. In the EU market the cheapest quote now often carries the largest compliance tail.
How to de-risk before you sign
- Treat the support window as a spec, not a promise. Put it in the RFQ and the contract.
- Buy from OEMs who can point to real OS-lifecycle data — how long the board platform gets Android security patches, not just “we ship Android 16.”
- Ask for a reference to the CE conformity documentation that already covers the cybersecurity angle.
- Coordinate with the Digital Product Passport / Ecodesign (ESPR) timeline — EU Digital Product Passport 2027 work overlaps with the CRA support-period records, so one document set can serve both.
Your next step
If you are sourcing Android tablets for the EU market, start your RFQ with the support-window and CE-cybersecurity questions above. We’ll send a datasheet covering current Android version, security-patch cadence and the CE documentation set on any model you shortlist. Related reading: our Android 16 lifecycle guide and what Google’s extended update promise actually means.
