IATA RP 1706c · reference The CUSS Handbook
Abstract illustration of a platform generation transition

Abstract illustration of a platform generation transition

The CUSS Handbook  /  CUSS 2: the move to web technologies

CUSS 2: the move to web technologies

The second generation of the CUSS standard is not a version bump. It replaces the technology the interfaces are built on, and it comes with published dates by which the previous generation stops being supported.

Why it happened

The 1.x line was designed around the interface technology of its era and defined fixed interfaces using CORBA. That choice held up for a remarkably long time — it delivered exactly what it promised, namely system independence and interoperability across implementation languages — but the ecosystem around it thinned out steadily. IATA's own framing is unambiguous: most of the technologies incorporated by CUSS 1.x have already reached their end of life.

There is a second driver, and it is arguably the stronger one. A shared public terminal that reaches into airline host systems is a security problem, and it is a security problem that got considerably more serious in the two decades after the original specification was written. A standard whose transport, authentication and session handling predate modern practice is hard to secure by bolting things on. CUSS 2 follows “security by design” principles and is built to support secure technologies from the interface up.

The third driver is supply of people. Writing a CUSS 1.x application meant hiring for an increasingly rare skill set. Writing a CUSS 2 application means hiring web developers, of whom there are a great many. That is not a small consideration for an airline weighing whether to maintain its own kiosk application at all.

What CUSS 2 is built on

IATA describes CUSS 2 as making use of current web technologies, specifically OpenAPI, OAuth2, HTML5, JSON, TLS above version 1.2 and WebSocket, enabling web developers to implement CUSS applications.

Each of those maps onto something the old design had to solve by hand:

  • OpenAPI gives the platform interface a machine-readable contract, so client code can be generated rather than written against prose.
  • OAuth2 gives applications a standard way to be authorised against the platform, replacing bespoke trust arrangements.
  • HTML5 makes the application itself a web application, which is what removes the specialist toolchain.
  • JSON replaces the older serialisation with something every stack already speaks.
  • TLS above 1.2 sets a floor on transport security rather than leaving it to deployment.
  • WebSocket supplies the persistent, low-latency, bidirectional channel that device interaction genuinely needs — a printer or a scanner produces events, and polling a scanner over request/response is not a serious design.

What the toolkit contains

Implementers work from the CUSS toolkit rather than from the Recommended Practice alone. It comprises four things: the CUSS 2 specification, which describes the concepts, requirements, interaction, workflows and behaviour expected of both platforms and applications; the CUSS 2 API and data model definitions in YAML; a certification document template; and a development guide.

The YAML definitions are the practical heart of it. An API described in a machine-readable format is one that can be validated against automatically, which changes what certification can realistically test — a point worth carrying into certification planning.

The transition timeline

IATA has published a transition path, and it has hard dates. The technical specification was released on 31 March 2023. The CUSS 2 transition phase began on 1 January 2024. CUSS 1.x platforms were discontinued as of 1 January 2026.

Those dates are the ones that should be driving asset planning. A platform still on the 1.x line is running on a generation the standards body has retired, which has consequences beyond aesthetics: certification, vendor support, security patching and airline willingness to deploy new applications all follow the standard rather than the installed base.

Check the current position before acting. Standards timelines move, and extensions and transitional arrangements are not unusual in this industry. The dates above are as published by IATA; confirm the current status on the common use standards page before writing them into a business case or a contract.

What it means in practice

For an airport or platform provider, the transition is a platform replacement, and platform replacement in a live terminal is a phased, hall-by-hall exercise with a period of running two generations side by side. That period is the expensive part and is the thing worth planning properly.

For an airline, it is an application rewrite, with the compensation that the rewrite lands in a technology stack the carrier's own web teams already work in. Several airlines have used the transition as the moment to consolidate a kiosk application, a bag-drop flow and a mobile web check-in onto shared components, which is a considerably better outcome than porting an old application unchanged.

For both, it is the natural moment to fix the things everybody knows are wrong: accessibility gaps, inconsistent device behaviour across a mixed estate, and monitoring that cannot tell an operator which of four hundred machines is actually broken.