Quick answer: The short answer: six RFQ clauses decide whether a kiosk fleet is still patched in year five — (1) named SoC and OS build line, (2) severity-tiered patch SLA, (3) a written LTS migration route, (4) a defined EOL start event plus spares tail, (5) a documentary evidence pack, and (6) a remedy that bites. A bid that cannot name the SoC and OS build line is not a weak bid on lifecycle risk; it is non-responsive, because there is nothing to score.
The short answer: six RFQ clauses decide whether a kiosk fleet is still patched in year five — (1) named SoC and OS build line, (2) severity-tiered patch SLA, (3) a written LTS migration route, (4) a defined EOL start event plus spares tail, (5) a documentary evidence pack, and (6) a remedy that bites. A bid that cannot name the SoC and OS build line is not a weak bid on lifecycle risk; it is non-responsive, because there is nothing to score.
The stakes are not hypothetical at portfolio scale. TIG – The Industry Group research compiled by KioskIndustry.org estimates the global installed base of self-service kiosks at between 8 million and 15 million units as of 2025 ( KioskIndustry.org, self-service technology statistics ). The compilation method and segment definitions are not published in the excerpt, so treat that range as order-of-magnitude context for procurement attention, not as a planning input.
Ranking pages on this topic tend to explain penetration testing and PCI scope without ever showing contract language, or reduce the whole lifecycle question to one checklist line about who owns the OS image. This page stays in the procurement seat: the exact RFQ fields, the wording that gets struck in legal review, and the numbers we refuse to invent.
| Clause | Risk it removes | Evidence you must receive | Pass / fail threshold |
|---|---|---|---|
| 1. SoC + OS build line | An unenforceable commitment to "Android" or "Windows" | SoC part number, OS product line and release, security patch level at shipment, image signing owner | Fail if any field is missing or generic |
| 2. Patch severity SLA | A patch promise with no clock attached | Per-tier acknowledgement, tested-image and rollout commitments | Fail if only one "response time" figure is offered |
| 3. LTS migration route | A migration that requires new hardware you did not budget | Named target release, hardware impact statement, cost owner | Fail if the target release is "a future LTS" |
| 4. EOL clock + spares tail | Three different end dates collapsed into one | Separate patch-EOL, firmware-EOL and spares-EOL dates with a stated start event | Fail if the start event is undefined |
| 5. Evidence pack | Claims that cannot be verified before award | Support matrix, patch release log, migration guide, CVE procedure | Missing document converts to a priced risk provision |
| 6. Remedy | Support that stops early at your cost | Capped extended-support fee, escrow trigger, early-termination credit | Fail if the remedy is "to be negotiated" |
Clause 1 — Name the SoC and OS build line, never "Android" or "Windows"
"Android-supported" is not a support commitment; it is a category. What is enforceable is a specific SoC part number plus a specific OS release plus a stated security patch level. Require these RFQ fields:
- SoC vendor and part number, and board revision.
- OS product line and release — for example a Windows IoT Enterprise LTSC release year, or an Android version with a stated security patch level.
- Kernel branch and build identifier of the shipped image.
- The legal entity that builds and signs the OS image.
Then ask the question most bids dodge: does the supplier build and sign the image themselves, or resell a board-vendor image? A resold image usually routes the patch path through a third party the buyer has no contract with — so the supplier is promising a cadence it does not control. Ask as well who supplies board support package (BSP) updates and for how many years from first shipment.
Peripheral drivers sit on the same treadmill. The cash acceptor, recycler, receipt printer and PIN pad each carry drivers that must be revalidated against every OS update. Name the driver-update owner inside this clause, not in a separate service annex that legal will deprioritise.
Clause 2 — Turn "we patch regularly" into a severity-based SLA
Define the severity tiers in the RFQ rather than accepting the supplier's definitions. A workable three-tier split: critical (remote code execution, authentication bypass, or any flaw touching the payment path), high, and routine. For each tier, demand three separate numbers — never one:
- Acknowledgement time — when the supplier confirms scope and impact.
- Tested-image availability — when a patched, regression-tested image exists.
- Fleet rollout window — how long after tested-image release your units are updated.
A single "response time" figure is the most common way this commitment gets blurred. Add: who regression-tests the image against your peripherals and payment application before fleet push, and is that test included or billed separately? And if a patch breaks a certified payment configuration, who owns the re-certification time and cost?
The compliance context is why this clause belongs in the contract. As described in AFINE's published kiosk security testing checklist, PCI DSS Requirement 6 covers secure development and maintenance of all system components including the kiosk application and its underlying operating system, and Requirement 11.4 covers penetration testing at least annually and after any significant change to the cardholder data environment (afine.com). A kiosk that receives late patches turns both requirements into a recurring finding. Confirm the current PCI DSS version and wording directly with the PCI Security Standards Council before you cite it in a contract schedule.
Clause 3 — Write the LTS migration path as a route, not a promise
Require a named migration target at bid stage: from OS release X to release Y, with Y identified. "A future LTS" is not a route. Then force out three hardware answers: does the migration require a new SoC or board revision; does it need more RAM or storage than the shipped bill of materials; and does the existing peripheral set remain driver-compatible?
Assign the cost and the mechanics. Who performs the migration — on-site, depot, or field engineer — at what price, and is the migration image supplied free if it falls inside the paid patch-support period? Specify the mechanism (USB re-imaging, remote OTA, or board swap) and the recovery path if a site loses power mid-migration.
The hidden cost that kills otherwise good bids is payment certification. Ask directly whether the migration preserves the existing certification or forces re-certification, and who pays for the re-testing window.
Clause 4 — Fix the EOL clock start point and the spares tail
End-of-life is meaningless without a start event. Counted from last production shipment, from contract signature, or from site acceptance, the same "five years" can differ by two or more calendar years across bids. This is the single most negotiated line in the schedule.
Demand three separate end dates in writing:
- OS security-patch end date.
- Firmware maintenance end date.
- Spare-parts availability end date.
Suppliers routinely quote only the first. On spares, state which modules are covered (mainboard, recycler, acceptor, display, power supply), the minimum last-time-buy quantity, and whether the last-time-buy price is fixed at bid or set at EOL pricing. Ask whether a unit past OS EOL can still receive firmware fixes for hardware-level issues — depot repair and firmware-only support are different commitments.
Finally, ask for track record on a platform the supplier has already retired: the platform name and the date support actually ended. A documented past end date is more persuasive than any forward-looking promise.
Clause 5 — Specify the evidence pack; missing documents become a risk provision
Require four documents at bid, not after award: a version support matrix, a patch release log covering the last twelve months, a migration guide for the named LTS path, and a vulnerability/CVE handling procedure. Two optional items differentiate serious suppliers: a software bill of materials for the shipped image, and the named party that signs security advisories.
Write the escalation rule into the RFQ: any document not delivered by the bid deadline converts into a stated risk provision — extended warranty, price holdback, or escrow — rather than being silently waived. Where a supplier cannot produce a patch release log, record that plainly. Absence of a log is not proof that no patches were issued, but it makes the claim unverifiable, and unverifiable support should be priced as risk.
Clause 6 — Attach a remedy, or the clause is decoration
Three mechanisms, all quoted at bid: a capped or indexed extended-support fee schedule so year-six support is not open-ended negotiation; an escrow trigger for source code or the signed image, with the releasing events named (supplier insolvency, product-line discontinuation, support breach) and the escrow agent identified; and an end-of-life buy-out or migration credit if the supplier ends support early. Add change-of-control and divestment language so the support obligation survives an acquisition of the supplier's kiosk business.
Red-flag decoder: what suppliers write versus what it commits them to
| Supplier wording | What it actually commits to |
|---|---|
| "Fully Android supported" | Nothing specific. No SoC, no OS build, no patch level, no end date. |
| "Lifetime support" | The lifetime of the product line as the supplier defines it, revocable by discontinuing the line. |
| "We always update" | A practice, not an obligation. No clock, no remedy. |
| "Industry-standard lifecycle" | Whichever standard the supplier chooses to invoke after award. |
| "Support available on request" | Availability priced and scoped at the supplier's discretion at the moment you need it. |
| "Security patch support for [SoC part number] on [OS build] through [date], evidenced by the attached support matrix" | The strong form: named hardware, named software, dated end, attached proof. This is the mirror you should hold up to every other row. |
Watch the timing trap throughout: a commitment expressed in years, attached to an undocumented start date, is not a commitment.
The RFQ block: twelve questions to paste into your schedule
- SoC vendor and part number, and board revision. (Scoring is impossible without this.)
- OS product line, release and security patch level at shipment. (Defines what "supported" means.)
- Who builds and signs the shipped OS image? (Determines whether the supplier controls its own patch path.)
- Who supplies BSP updates, and through what date from first shipment? (Third-party dependency, usually undisclosed.)
- Acknowledgement time for a critical-severity patch. (First of three needed numbers.)
- Tested-image availability for the same severity tier. (Second number; the one that usually slips.)
- Fleet rollout window per severity tier, and who regression-tests against our peripherals. (Third number, plus cost owner.)
- Named LTS migration target release and availability date. (Rejects "a future LTS".)
- Hardware impact of that migration: SoC change, RAM/storage delta, driver compatibility. (The budget question.)
- OS security-patch EOL date, with the start event stated. (Start event is the negotiable line.)
- Spares-availability EOL date, covered modules, minimum last-time-buy quantity and price basis. (Separate from patch EOL, always.)
- State any part of this support commitment that is outside your direct control. Intentionally disqualifying: suppliers who name their third-party dependencies here are the honest ones.
How to score the answers without over-weighting promises
Weight verifiability above length of commitment. A five-year commitment backed by an attached support matrix outranks a ten-year commitment with no document. Keep two separate blocks on a single page: scored rows (documented evidence, pass/fail) and priced rows (extended-support fees, migration cost, spares last-time-buy). Then cross-check the quoted patch-support end date against the depreciation period your finance team is using — if the support ends before the asset is depreciated, the total cost of ownership must include a mid-life hardware event. The aim is to make unsupported bids visibly unsupported, not to build a second procurement process.
Numbers this page will not invent
Patch cadence in months, supported-year counts, certification dates, pricing and spares lead times must come from the supplier in writing. Every such field in your schedule should be labelled "to be obtained from supplier" until a signed declaration returns it. A checklist that fills in plausible-sounding figures is worse than no checklist, because it transfers the supplier's risk onto your signature.
Frequently asked questions
How many years of Android security patches should a kiosk supplier commit to in an RFQ?
Do not anchor on a number in the RFQ — anchor on the evidence. Require the supplier to state the supported-through date for the exact SoC part number and OS build they are quoting, and to attach the version support matrix that substantiates it. A bid that offers a year count without a named SoC and build line cannot be compared to a bid that does.
Does migrating a kiosk fleet to a new LTS OS release require new hardware?
It can, and that is exactly what Clause 3 is for. Ask for a written hardware impact statement covering SoC or board revision changes, RAM and storage headroom against the shipped bill of materials, and peripheral driver compatibility. Where the supplier cannot confirm, treat hardware replacement as an unbudgeted event inside your depreciation period.
What happens to spare parts and firmware support after a kiosk OS reaches end of life?
Only what you wrote into the contract. OS security-patch end, firmware maintenance end and spares availability end are three separate dates, and suppliers often quote only the first. Require all three, with the start event defined and a last-time-buy price basis stated.
What documents can I demand as proof of a kiosk supplier's patch history?
A version support matrix, a twelve-month patch release log, a migration guide for the named LTS path, and a CVE handling procedure — requested at bid, not after award. If a document is missing by the deadline, convert that gap into a stated risk provision rather than accepting an assurance.
Get the clause template before you issue the RFQ
The fastest way to run this is to issue the schedule rather than the question. Request the OS lifecycle & patch support declaration template — pre-formatted for your RFQ schedule, with every field above as a fillable, supplier-signed row — and we will return it mapped to our published platform documentation, with any field we cannot document explicitly marked as such rather than left to inference. You can also request a quote and a lifecycle statement for a specific kiosk configuration, including the SoC and OS build line we would propose, so the comparison starts on the same footing across every bid on your shortlist.
