This news keeps you updated on the latest information from the Common Use Group (CUG) activities or on any information that supports the activities of this group.

The information is pertinent to airline Chief Information Officers and to anyone already involved or interested in the Common Use activities.

EOL Adobe Flash Plug-in

US company Adobe has announced the end of the Flash Player for end of 2020. - So, from 2021 no more updates or security patches for this software will be published. The company also states that Flash-based content will be blocked from running in Adobe Flash Player after the EOL date. Meanwhile open standards such as HTML5, WebGL and WebAssembly fulfill the role of Adobe Flash.

As a consequence to the above announcement, application suppliers and providers cannot expect a newer Flash or Shockwave version than the latest one released by Adobe in 2020 and distributed on a CUSS platform. 

Application providers still using Adobe Flash as a technology in their applications must double check with CUSS platform providers on the latest Flash version available on the targeted CUSS platform and if this version still plays Flash based content.

From 2021 the CUSS TSG will no longer list Adobe Flash and Shockwave plug-in’s as a required presentation technology in its CUSS specification(s).

IATA Technical Peripheral Specifications (TPS)

The Association of European Airlines (AEA) was the voice of the European airline industry for over 60 years and was responsible for the specifications on Automated Ticket and Boarding Pass equipment (ATB), Parametric Tables (PECTAB), and Self-Service and Baggage Tag Printers (BTP). Related firmware are industry standards, applied by manufacturers worldwide.

AEA, as an organization, has ceased existence in 2016. In 2018, IATA has taken over the former AEA Technical Specification Standards and created a Technical Solution Group called IATA Technical Peripheral Specifications (TPS). The ITPS sub-group, under the governance of the Common Use Group, will maintain this standard going forward. Read the IATA Technical Peripheral Specifications (ITPS) brief here (pdf).

The IATA Technical Peripheral Specifications Manual is now available on the IATA online store.

Windows 7 - End of Life

The IATA Common Use Group met in Athens in October 2018 and agreed that IATA recognized common use standards used for passenger processing will not be supported on systems using the Windows 7 operating system as of January 14, 2020.
It is urgent that all parties migrate systems from Windows 7 to a current supported operating system, such as Windows 10 to maintain flight operations at airports, and to reduce risks and costs of security breaches.

Windows XP - End of Life

During its December 2017 meeting, the CUG agreed that common use standards used for passenger processing will not be supported on systems using the Windows XP operating system. Read the Common Use Windows XP- End of Life document.

It is urgent that all parties migrate systems from Windows XP to a current supported operating system, such as Windows 7 to maintain flight operations at airports, and to reduce risks and costs of security breaches.

CUSS version 1.2 end of life

During its June 2017 meeting, the CUG decided to terminate the CUSS version 1.2 for use in airport and airline environments. This decision was made for a diverse number of reasons. Read the CUSS version 1.2 End of Life by December 2017 Document (pdf) for more information.

Airlines and airports are now urged to start the migration to the latest CUSS v1.4.

Card payment at common use positions

There is an increasing demand for guidance on what are the desirable components of a solution that would support the "multi-merchants/multi-acquirers" business model of common use positions at airports which are shared by several airlines.

A Business Requirements Document (pdf) was put together providing recommendations that airports and airlines should consider when drawing up their own business requirements. These business requirements do not recommend any technology or provider and only seek to establish the key components of an effective industry card payment for this specific environment.

Bar Coded Boarding pass (BCBP) Implementation Guide

The BCBP group of experts updated Resolution 792 version 8, which has become effective on June 1, 2020.  The list of changes to Resolution 792 - Version 8 is as follows:

  • Gender Code - Field 15: Gender Code the gender code “X” which is defined as “Unspecified” and gender code “U” defined as “Undisclosed”.  


The BCBP group of experts updated the BCBP Implementation Guide 7th Edition reflecting the latest changes to Resolution 792 - Version 7 that has become effective on June 1, 2018. Section 2.2.4 provides additional information and examples related to certain data elements contained in the standard for implementation purposes. The list of changes to Resolution 792 - Version 7 is summarized below:

  • Bar Code on Printed Boarding Pass: the default Bar Code presented on printed boarding pass is a 2-dimensional Bar Code in PDF417 standard containing a structure data message (SDM). On the request from the Airlines version 7 extend the standards to allow Aztec, Datamatrix or QR code formats on printed boarding pass those formats are currently used on Electronic (Mobile) Boarding Pass only.
  • Field 23 (Baggage Tag License Plate Number (s)): last 3 digits have been changed to follow RESO 740/RP1745 where 001= 1 bag, 002= 2 bags, 007= 7 on version 6th of RESO 792, 000=1 bag.
  • Field 6 (Field Size of variable size field): there was a change in the Implementation Guide where the previous version stated: Items 8 to 118, Plus Item 4, and now Size of data used within the subsequent conditional and airline individual fields (items 8 to 254, plus item 4) in ASCII-printed hexadecimal. If not used, enter "00."
  • Field 10 (Field Size of following structured message - unique): there was a change in the Implementation Guide where the previous version stated: Items 15 to 23 the updated version: Size of data used within the subsequent fields (items 15 to 32), in ASCII-printed hexadecimal. If not used, enter "00." Should only count for the length of the conditional data identified as unique. In other words, it is the sum of the length of items 15, 12, 14, 22, 16, 21, 23, 31 and 32.

Latest CUPPS features

Although CUPPS already allows the use of mobile devices such as tablets on Windows 8.1, Wi-Fi networks and even remote access for airlines to airport peripherals, the following new features are now included in the new CUPPS 1.04 specification that was finalized in December 2014:

  • It is now possible to use CUPPS with a baggage drop device that operates in a common use environment. The baggage drop device has the status of "Defined, Required" in the latest CUPPS 1.04 specification and can be implemented based on AEA 2012.
  • A snapshot reader device is also defined and allows taking snapshot photos on a conveyor belt in the case of a baggage drop device or any other area as required. It can also return a picture from any full page scanner used for passports or biometric devices.
  • Self boarding gates are now "Defined, Required" in CUPPS instead of being just optional.
  • An electronic payment device simply allows full bi-directional data exchange of any nature to facilitate future integration with a generic payment module.
  • Simulated hardware can now be used to facilitate platform compliance for complex devices such as baggage drop and electronic payment.

While new features were added, part of the work concentrated on streamlining the existing specification. For example, a simpler way has been put in place for airlines to do host printing. Other devices such as beep and display devices were marked as obsolete as they are no longer used as separate devices. Certain hardware requirements were also modified to ease various cloud and virtualized deployments.

CUPPS Request for Proposal (RFP)

Airports, airlines and consultants preparing a Request for Proposal (RFP) for the supply of CUPPS are advised to take into account the considerations contained in the CUPPS RFP Guidance Document (pdf).

Common Use Evolution

With the current strong air travel growth and with the expectation that global passenger traffic will double within the next two decades, airport infrastructure in many regions are already or will soon be capacity-challenged.

The whole passenger process has changed and continues to evolve. There is now an expectation on airports and airlines to provide passengers with multi-channel self-service and accessible capabilities (i.e. web, kiosk, mobile phone, auto check-in, self-tagging, self-bag drop, self-boarding, etc.). At the same time, there is a need to maintain infrastructure to continue to provide full service options for some passengers.

The CUG developed the following vision in order to have a more flexible infrastructure and improve the customer experience.

By 2020, common use will provide flexibility of choice to deploy services based on interfaces adhering to industry standards.

These interfaces will range from Web Services, Cloud computing and mobile devices through to standard desktop offerings.

Whether platforms are physical or virtual, there will be standard interfaces presented to the application so that the concept, first introduced by CUPPS and CUSS, of "certify on one platform, run on many" will remain as a core principle.

Perspective on Common Use standards

In common use/shared systems environments IATA recommends the adoption of Recommended Practice RP1706c on CUSS, RP1797 on CUPPS and RP1741 on standardized data exchange supporting common use self-service bag drop through the use of web services technology. These three common use industry standards effectively support the air transport industry's business strategies and needs.

Consequently, it is recommended that as new contracts are negotiated, platform operators (such as airports or Common Local User Boards - CLUBS) request CUSS and CUPPS platforms for their common use environment.

U.S. DOT rule on kiosk accessibility

Airlines, airports and vendors need to be aware of the U.S. DOT final rule on kiosk accessibility that became effective on December 12, 2013.

The rule requires that:

  • All airlines must ensure that all proprietary and common use kiosks installed on or after December 12, 2016 that they own, lease or control at U.S. and Canadian airports with 10,000 or more annual enplanements meet detailed accessibility design standards until a total of at least 25% of each type of the kiosk provided at each location in the airport meet these standards. At least 25% of kiosks in each location at a U.S. airport must be accessible by December 12, 2022 and by December 31, 2022 for Canadian airports.
  • All airlines in addition to U.S./Canadian airports must ensure that accessible kiosks are visually and tactile identifiable and maintained in working condition
  • All airlines must give priority access to accessible kiosks to passengers with disabilities
  • All airlines must provide equivalent service to passengers who cannot use accessible kiosks that airlines own, lease or control due to disability

The U.S. DOT will be conducting onsite inspections to see that the rule has been enforced appropriately.

Beginning with IATA CUSS version 1.4, the standard and technical specifications provide the necessary framework to enable current accessibility standards. Airlines, airports and vendors should maintain an ongoing compliance plan to meet accessibility requirements and are strongly recommended to document all efforts.

For information, the rule also covers two other elements of airline website accessibility and wheelchair stowage that are not related to common use activities.

View the official information on the U.S. DOT rule.

View the Canadian Transport Association official information on Removing Communication Barriers for Travellers with Disabilities.

View the official Directive of the European Parliament and of the Council.