Before you sign a tablet purchase order for the EU market, ask the shortlisted supplier for four things: a machine-readable SBOM for the exact firmware build you are buying, a written security update support period with an end-of-support date tied to that BSP and Android version, a named vulnerability disclosure channel with a response commitment, and the CE conformity route with the economic operator named on the documentation. If any of the four cannot be produced in writing, the model is not procurement-ready — regardless of its spec sheet.
The short answer: a tablet PO is now a document set, not a spec sheet
Two dates govern the decision. Vulnerability and incident reporting obligations apply from 11 September 2026, and the full regulation applies from 11 December 2027 — both milestones are set out on the European Commission’s Cyber Resilience Act policy page and are repeated in dated practitioner guidance, for example Bytesnap’s EN 18031 guide of 26 February 2026. The regulation entered into force on 10 December 2024, which matters commercially: a supplier who answers “we will handle it before 2027” has already spent the runway and is describing a project, not a capability.
The practical consequence for a distributor or tender bidder is that the compliance evidence now travels with the purchase order. You will be asked for it at tender review, by your own customers, and potentially at audit. What you hold in your document management system on the day you sign determines whether you can answer.
This article is procurement due diligence, not legal advice. Whether your specific product falls within scope, and which obligations attach to your role in the chain, must be confirmed with your own counsel.
Why this checklist is written for the buyer, not the engineering team
Most published material on CRA and SBOMs is addressed to software vendors and release engineers — how to generate SBOMs in a CI pipeline, how to automate component monitoring, how the standards map to each other. Useful, but it does not answer the question a procurement manager actually has: which artefact do I demand from this tablet supplier, in what form, and what answer disqualifies them?
Tablet sourcing adds three problems that software-focused guides do not cover: the BSP and the Android version have different end-of-support dates and both diverge from the chipset vendor’s support window; patch cadence claims are unverifiable without release history; and component end-of-life arrives mid-deployment, on a Wi-Fi module or SoC you cannot swap. Those three sit at the centre of the checklist below.
The 10-document supplier checklist
Work through these in order. Each item names the artefact to request and the test that separates a real document from a marketing answer.
1. A machine-readable SBOM for the exact firmware build you are purchasing
Request SPDX or CycloneDX — an interchange format your security tooling can parse — not a PDF component list. The CRA requires manufacturers of products with software components to create and maintain a software bill of materials; the requirement itself is well documented in practitioner overviews such as Anchore’s SBOM compliance summary. No verified source we hold prescribes one mandatory interchange format, so specify the format your scanning tooling ingests and have counsel or your notified body confirm what they expect. Critically: the SBOM must correspond to the build you are buying, not to a reference platform.
2. An SBOM that carries versions, supplier fields and dependency relationships
A component list without version strings is decorative — it cannot be matched against a vulnerability feed, so it will fail the first downstream scan your customer runs. Check that each entry carries component name, version, supplier and the dependency relationship. Then ask the process question: how and when is the SBOM regenerated? An SBOM issued once at new-product introduction and never refreshed does not survive a three-to-five-year deployment, particularly when an OEM-added application or the BSP changes.
3. The security update support period in writing, on letterhead
Demand a number of months or a fixed calendar end date, stated on company letterhead and referenced by name in the supply agreement. “We support it for years” is unusable in a tender response and unenforceable in a dispute. Also pin down what the period applies to: the shipped firmware build, the hardware platform, or the model name — these are not the same commitment.
4. The end-of-support date for the specific BSP and Android version — not the chipset family
On a typical ODM programme, the SBOM is authored by the firmware or BSP engineering team from the build manifest at release, while the support tracking happens separately, per SKU, against the platform roadmap. That separation is where buyers get caught: the chipset may be supported for years after the Android version shipped on your model stops receiving security patches, and the BSP layer may stop before either. Ask for all three dates in one table and check which one binds your deployment period.
5. A patch cadence commitment, and a definition of what a patch is on this model
Ask whether cadence is monthly, quarterly or critical-only, and who classifies a vulnerability as critical. Then ask how a patch physically reaches the device: full OTA image, incremental update, or re-flash at a depot. A re-flash-only model changes your field-service cost and must be priced before award, not discovered after. Vague cadence language is one of the most common gaps in supplier answers.
6. A named vulnerability disclosure channel with a response commitment
Get the security contact, PGP key or portal — and the published commitment on acknowledgement. An unmonitored info@ inbox is not a disclosure channel; it is a place where reports go to expire. Ask who triages reports, in which timezone, and whether the channel is published externally so researchers can find it without asking you.
7. An incident reporting workflow that covers products already in the field
Ask the supplier to walk through their reporting workflow against the regulation’s reporting obligations. Practitioner descriptions commonly outline a staged sequence beginning with a 24-hour early warning followed by a fuller notification; verify the exact hour counts and content against the regulation text with counsel rather than relying on any secondary summary. The scope question is the one that catches distributors: the 11 September 2026 obligations extend to products already placed on the EU market, not only to new shipments. Confirm the workflow covers stock in your warehouse and units already deployed.
8. The CE conformity assessment route, and who holds the technical documentation
Ask which conformity assessment route was used, which entity holds the technical documentation, and which EU-established economic operator is named on the documentation you will receive. If no EU entity appears anywhere in the chain, your own position as importer or distributor needs legal review before award. Certification dossiers for other markets follow a similar logic of named holder and traceable evidence — the ANATEL, BIS and SASO certification overview shows how those packages are typically structured, and the same questions transfer to the EU file.
9. EN 18031 evidence for radio-connected tablets, not just a CE sticker
Wi-Fi, Bluetooth and cellular tablets sit in the overlap between the Radio Equipment Directive’s cybersecurity requirements and the CRA. The EN 18031 series is widely expected to inform the CRA’s horizontal security requirements. Ask whether the model has been assessed under the relevant EN 18031 parts and request the test evidence or notified-body involvement. Then probe the known failure modes directly: published guidance flags products that let users skip or bypass password requirements as falling foul of clauses 6.2.5.1 and 6.2.5.2 in EN 18031-1 (Bytesnap, 26 February 2026). Ask how default credentials and first-boot setup are handled on the shipped build.
10. Last 12 months of actual patch releases, plus component end-of-life handling
A cadence claim with no release history is a hypothesis. Request the release log for the past year with the CVEs addressed in each build. Then ask the question almost no supplier anticipates: what happens when the Wi-Fi module, SoC or a third-party SDK you depend on reaches end of life? You want advance notice with a defined lead time, a last-time-buy window, and a written commitment on how long security fixes for the shipped build continue after component EOL.
Red flags that should stop the purchase order
| Signal | Why it disqualifies |
|---|---|
| No one can name the person or team who authors the SBOM | The artefact does not exist as a process; it will not be regenerated. |
| Support period appears only in marketing copy | Nothing to attach to a contract or a tender response. |
| No EU economic operator named in the documentation chain | Enforcement and recall risk lands on you. |
| Patch history is absent, or is a single NPI build | No evidence the supplier has ever shipped a security fix. |
| SBOM offered as a PDF component list with no versions | Cannot be scanned; useless to your customer’s security team. |
| Supplier treats December 2027 as the only deadline | Shows they have not read the September 2026 reporting obligation. |
What to attach to the supply contract
- Attach the SBOM and the support-period statement as schedules, so their content becomes a contractual obligation rather than a courtesy.
- Define patch cadence, the notification window for actively exploited vulnerabilities, and your remedy if a release commitment is missed.
- Add a documentation-request or audit right covering the technical documentation you need for your own conformity work and tender submissions.
- Add component EOL notice with a defined lead time and a last-time-buy option.
These clauses are a procurement position, not a legal template. Have your counsel adapt them to the applicable national law and to your role in the supply chain. For public-sector work, the same evidence also feeds the bid file — the education tablet tender bid-readiness checklist covers the documentation set tender reviewers ask for.
If the supplier cannot produce the documents yet
Do not accept an open-ended promise. Instead, place an evaluation or pilot order against a written remediation plan with dated milestones, and record the interim artefacts you can obtain now — the BSP and Android security patch level per build, the current disclosure contact, and the chipset vendor bulletin subscription — as your baseline. Then escalate the shortlist toward manufacturers who hold the artefacts themselves, rather than integrators who would have to obtain them from a third party after you sign.
Model-level diligence is where the checklist becomes concrete. On a programme built around the Snapdragon 685 11.97-inch business tablet or the T616 11.97-inch business tablet, the questions above should be answered against the shipped BSP build and the specific configuration you are ordering — not against the chipset platform in general.
FAQ
What exactly must an Android tablet supplier give me for CRA compliance?
At minimum: an SBOM for the shipped build, a written security update support period with an end-of-support date for the exact BSP and Android version, a named vulnerability disclosure channel with a response commitment, and the CE conformity documentation with an identified EU economic operator. Ask for all four in writing before the PO.
Does the CRA require a specific SBOM format like SPDX or CycloneDX?
The regulation requires an SBOM to be created and maintained; we hold no verified source prescribing a single interchange format. Specify the format your scanning tooling ingests, and confirm any format expectation with your counsel or notified body.
Is EN 18031 the same as CRA compliance for a Wi-Fi tablet?
No. EN 18031 supports the Radio Equipment Directive’s cybersecurity requirements and is widely expected to inform the CRA’s horizontal requirements. Assessment under it is evidence, not a substitute for the CRA conformity route — confirm the mapping for your product with counsel.
What happens on 11 September 2026 if the tablet is already in stock in the EU?
Reporting obligations from that date extend to products already placed on the EU market, so stock in your warehouse and units already deployed are in scope. Establish now who reports, through which channel, and how quickly you would be informed.
How long must a tablet supplier provide security updates?
The support period is a commercial commitment the supplier must state in writing, and it must be long enough to cover your deployment and resale horizon. We do not quote a universal number here because the correct figure depends on your contract term and the platform’s own end-of-support dates. Ask for a fixed end date and check it against your field-life plan.
Screen your shortlist before the PO, not after
Run this checklist against every model you are considering, and treat a missing artefact as a cost you will absorb later. Request our security update commitment letter and an SBOM sample for your shortlisted tablet model — review both against the ten items above before you raise the purchase order. Start from the enterprise and rugged Android tablet range on our business tablet pages, where model specifications and OEM/ODM options can be matched to the documentation package you need.
