Reporting on July 28 set out where the airline industry stands on Common Use Self Service, the standard that lets several airlines serve passengers through shared kiosks instead of one machine per carrier. IATA's current specification is CUSS 2.3.2, and its migration plan asks the industry to leave CUSS 1.x platforms and applications by the end of 2026.
The question for anyone who owns kiosks is whether a new standard means new machines. The reported answer is that age alone does not decide it: applications have been deployed on kiosks around 12 or 13 years old, and Frontier Airlines applications run on NCR kiosks approaching 20 years. What decides it is which parts can be replaced separately from the rest.
The change is in the software stack, not the sheet metal
CUSS 1.x was built for fixed, Windows-based kiosks running locally installed applications, and some of the technologies underneath it are now unsupported or expensive to maintain. CUSS 2 moves to current web technologies — OpenAPI, OAuth 2.0, HTML5, JSON, WebSocket, and TLS protocols newer than version 1.2 — dropping dependencies on CORBA, Java and browser plug-ins that were normal when the earlier versions were written. It adopts security-by-design principles and supports current payment security, privacy and data-protection requirements across kiosks, bag drops, tablets, phones and other touchpoints. Applications can be responsive instead of permanently installed on one kiosk type, running across different devices, screen sizes and locations, and the standard supports multiple screen orientations and aspect ratios — with developers still responsible for making interfaces and accessibility features render correctly.
None of that is a mechanical requirement. An enclosure, a display, a mounting arrangement — none cares whether the application arrived over WebSocket or a Java plug-in.
Where the audit actually fails
The reported upgrade path is component-level. Some airports may keep the enclosure, display, printer, scanner and other components while replacing the internal computer or updating the operating system and drivers; modular kiosks are the better candidates because individual components can be upgraded without replacing the whole terminal.
But the same reporting is clear that ageing printers, passport readers, barcode readers and computers may still need replacing, and that machines depending on unsupported processors, operating systems, payment readers or proprietary drivers may be too costly or risky to retrofit. None of those are the parts that wear out mechanically. They are the parts whose behaviour depends on a driver someone else has to keep maintaining. A steel enclosure has a service life measured in decades and no software surface; a passport reader has one measured by whoever still ships a driver for it.
The operating system is a per-unit question
IATA has warned that common-use systems should not run on end-of-life Windows platforms, because unsupported software creates security, compatibility and compliance risks. The detail underneath the warning matters more than the warning: Windows 10 Home and Pro support ended in October 2025, while certain Windows 10 Enterprise and IoT Long-Term Servicing Channel editions remain supported for several more years, so airports are advised to check the specific edition on each kiosk rather than treating every Windows 10 machine alike. Two physically identical terminals can therefore land on opposite sides of a compliance line because of an SKU decision made years earlier at procurement — an argument for recording the OS edition as a durable specification of the deployed unit, not an install-time detail.
The timetable and the escape hatch
IATA's roadmap has four milestones: plan, test and update applications; by the end of the second quarter of 2026 vendors were expected to have CUSS 2 platforms available for testing and certification; from the end of the third quarter airports may begin requiring them; and CUSS 1 operations and support end in 2026, with new kiosks supporting CUSS 2 natively and airports free to remove applications from carriers that have not converted. The schedule is industry guidance, not a single authority's mandate — enforcement depends on airports, contracts, platform providers and airline readiness, and at least one technology provider expects the transition to run well into 2027.
Because CUSS 1 applications do not run natively on CUSS 2 platforms and the reverse is also true, suppliers expect the two to coexist temporarily, with dual-platform and bridge technologies letting legacy airline applications run alongside CUSS 2 software on existing kiosks under temporary arrangements between participating airports, airlines and vendors. A purchasing rule is embedded there: airports are advised not to buy new equipment that supports CUSS 2 only through an intermediary compatibility layer, because the roadmap calls for new deployments to support the standard natively. A bridge protects an installed base; it is not a specification to accept on a new order.
How we read it
The costs described in the reporting sit mostly outside the enclosure: application development, integration, security reviews, testing and certification for airlines; platform licences, operating-system upgrades, computing components and professional services for airports; plus deployment labour, project management and contingency planning to keep passengers moving during the changeover. Certification slot availability is expected to be one of the tighter constraints.
Yinestar builds POS touch systems, industrial panel PCs, box PCs and Android all-in-ones, and this migration describes the condition all four are eventually judged by. A standard change arriving eight or twelve years into a deployment does not ask whether the machine was good when it shipped. It asks which parts can change without changing the rest.