Everything worth asking about CUSS 2.

CUSS 2.0 is the IATA Common Use Self-Service standard (Recommended Practice 1706c) that defines how airline applications run on shared airport kiosks. It replaces the legacy CUSS 1.x stack with a web-native architecture built on OpenAPI, WebSockets, OAuth 2.0, and TLS — making self-service apps faster to build, more secure, and hardware-independent.

CUSS 1.x is built on CORBA/IDL middleware with proprietary platform vendor implementations. CUSS 2.0 replaces that with web standards:

• OpenAPI for the contract
• WebSockets for real-time peripheral I/O
• OAuth 2.0 + TLS 1.2+ for security

The result is cross-platform compatibility, standard web tooling, faster development cycles, and zero-trust security baked into the protocol itself. CUSS 2 is not backward compatible with CUSS 1.

Recommended Practice 1706c is the formal IATA specification document that defines CUSS 2.0. It is the source of truth for the API surface, peripheral profiles, security requirements, and certification criteria. Vendors and applications must conform to RP 1706c to be considered CUSS 2 compliant.

IATA formally retired CUSS 1.x on December 31, 2025. The industry is now in the CUSS 2 soft-transition phase: vendor-by-vendor CUSS 2 mandates have begun, and full cutover follows. Airlines and airports still running CUSS 1 applications need to migrate.

If your airline or airport relies on shared self-service kiosks at IATA member airports, yes. CUSS 1.x is formally retired, individual airports and platform vendors are setting their own CUSS 2 cutover dates, and continuing to operate CUSS 1 applications is no longer a viable long-term path.

It depends on the complexity of your CUSS 1 application, but most carrier check-in apps can be converted in weeks rather than months. The web-first architecture and open SDKs mean development teams ship the same day they write code.

Elevation AI's free conversion offer includes code-level translation — not a wrapper — so the resulting application is fully RP 1706c compliant and maintainable going forward.

No. CUSS 2 is a clean break from CUSS 1's CORBA-based architecture. A CUSS 1 application will not run on a CUSS 2 platform without code-level conversion or a bridge layer.

This is intentional — backward compatibility would have prevented the security and developer-experience improvements that motivated the new standard.

Generally no. CUSS 2 deliberately decouples hardware from software. Most existing kiosk hardware — printers, scanners, MSRs, cameras, payment devices — works with CUSS 2 through updated peripheral drivers. The platform software changes; the metal usually stays.

Elevation AI's Platform offer is built around exactly this premise: deploy CUSS 2 on the kiosks you already own.

Because CUSS 2 is web-native, you can build applications in any language that speaks OpenAPI and WebSockets — effectively all of them. Open SDKs are available for TypeScript, Angular, and React at cuss2.dev, with a live sandbox for testing.

Apps ship as web-first deliverables and can be deployed without recompiling for each kiosk vendor.

Both have a role:

• Airports (or their platform vendors) provide the CUSS 2 runtime environment on the kiosks.
• Airlines provide their check-in application built to RP 1706c.

At the spec level, an airline's CUSS 2 app will not run on a CUSS 1 platform, and a CUSS 2 platform cannot serve a CUSS 1 application — so generically, both sides need to be ready before any given airport can serve any given airline on CUSS 2.

This lockstep dependency is one of the major causes of migration delay industry-wide, and is exactly the problem Elevation AI's two-product approach is built to solve — see the next two questions.

Yes. Elevation's CUSS 2 platform is designed to serve both CUSS 2-native applications and existing CUSS 1 airline applications on the same kiosk during the transition. An airport can deploy a CUSS 2 platform without forcing every airline tenant to migrate on the same day.

This eliminates the lockstep dependency that has stalled many transitions: airports get to CUSS 2 readiness on their own timeline, and airlines migrate when each is ready — not when the last one is.

Yes. When an Elevation CUSS 2 application is deployed on a kiosk running a CUSS 1 platform, our bridge stands up a CUSS 2 facade in front of the CUSS 1 platform and translates calls back to CUSS 1 underneath.

The airline ships one modern, RP 1706c-compliant application that works on both CUSS 2 and CUSS 1 platforms during the transition. No fork. No double maintenance. The new app goes live immediately, regardless of which airports have completed their platform upgrades.

Qualifying carriers on the early waitlist receive a free conversion of their existing CUSS 1 application into a fully RP 1706c-compliant CUSS 2-native application — at no cost. The result is real CUSS 2 code that you own and can maintain, not a wrapper around the legacy app.

The new application also includes Elevation's bridge layer, which lets it run on legacy CUSS 1 platforms during the transition. Airlines can ship the modern app immediately — they don't have to wait for every airport in their network to be CUSS 2-ready before going live.

Capacity is limited and allocated first-come, first-served. Join the conversion waitlist →

Yes. For carriers that prefer to have an application built for them rather than build one with our SDKs, Elevation offers fully white-label CUSS 2 application development — hyper-branded to your carrier identity, built on a full-service architecture underneath.

Low and mid-service applications can ship in weeks. Full-service experiences with every feature turned on take longer, but still well under the 9–12 months typical of DIY builds or competing vendor projects.

Elevation stays invisible — the result is your application, your brand, your CUSS 2-native deliverable. Talk to us about white-label →

Yes. Elevation's bridge layer deploys on top of an existing CUSS 1 platform — regardless of which vendor it is from. CUSS 1 airline tenants keep running unchanged; CUSS 2 airlines gain a compliant target on the same kiosks.

The airport gains CUSS 2 readiness without a platform migration or vendor swap, and existing tenants are not disrupted. It is the fastest way to support CUSS 2 airlines while a longer-term platform decision is still in progress. Talk to us about the bridge →

We helped write the CUSS 2 standard and we run a CUSS 2 platform in production at 75+ airports today. Helping more of the industry migrate cleanly serves the standard, the supply chain we are embedded in, and our long-term business — all of which depend on CUSS 2 becoming the default rather than the exception.

The conversion and platform offers are loss-leaders by design.

Elevation AI is CUSS 2 native — built for the new standard from day one, not a legacy CUSS 1 platform retrofitted for CUSS 2. Co-founded by William Kapke — a key architect of CUSS 2.x — we are active members of the IATA CUSS Task Force shaping the standard going forward.

Most importantly, Elevation offers four paths to CUSS 2 — two for airlines, two for airports:

• Airlines can build their own CUSS 2 application with our open SDKs (with a bridge layer for CUSS 1 backward compatibility), or have us build a fully branded white-label application for them.
• Airports can keep their existing CUSS 1 platform and add our bridge layer on top to enable CUSS 2, or replace the platform entirely with our CUSS 2 platform that still serves CUSS 1 airlines side-by-side.

That decouples the lockstep migration dependency most of the industry is stuck on — airlines and airports each move on their own timeline.