GLI-26 Wireless Gaming Systems v2.0: Network Security, Session Control, and Mobile Certification Requirements

GLI Standard 26 (GLI-26), Wireless Gaming Systems, version 2.0, published February 24, 2015, is the primary technical benchmark for any gambling system that uses a wireless local area network (WLAN) to connect player-facing devices to the gaming back-end. Wireless Client Devices, explicitly defined in the standard’s glossary to include PDAs, mobile phones, and tablets, cannot lawfully operate in a certified gaming environment without a system that has been evaluated against GLI-26. Suppliers and operators deploying mobile or tablet gaming on a casino floor must understand the standard’s device architecture rules, its non-negotiable encryption mandates, the disconnection-handling regime, and how GLI-26 certification sits alongside GLI-19 certification for game content. This article addresses each of those areas directly.

What Does GLI-26 Actually Cover?

GLI-26 v2.0 defines its scope as the confidentiality, accountability, and integrity of Wireless Local Area Networks (WLANs) in gaming environments. Its stated goal is to ensure “that the security of the WLAN and/or Wi-Fi Systems in a gaming environment is as closely equivalent to the security of a wired system as possible” through controls governing design, implementation, and use of wireless networks and devices. The standard operates on a centralised WLAN model, in which security, authentication, and communications are managed through a centralised server or system, not distributed across individual client devices.

The standard covers four principal device categories. Wireless Devices are the generic category of any device using wireless connectivity. Wireless Access Point (WAP) Devices are the infrastructure components that bridge the wireless network to the wired backbone. Wireless Client Devices (WCDs) are the player-facing hardware, mobile phones, tablets, and personal digital assistants used for gaming activity. Wireless System Devices are system components that use wireless communication to interact with the gaming network but are located in secure, access-controlled areas of the facility.

A fourth category, Other Wireless Devices (section 2.6), covers peripherals such as keyboards, mice, and patron phones used for non-gaming activity. Under GLI-26 v2.0 section 2.6, these devices must not be used to communicate Sensitive Data unless they conform to all wireless communication security and encryption requirements specified elsewhere in the standard.

What Question Does GLI-26 Answer That GLI-19 Does Not?

GLI-19 v3.0, Standards for Interactive Gaming Systems, is the certification benchmark for the server-side platform: RNG validation, game outcome logic, account management, transaction processing, and responsible gambling controls embedded at the system level. GLI-26 is not a substitute for GLI-19, it governs the transmission layer. The standard makes this division of responsibility explicit: all critical functions, including the generation of any game outcome and the return to the player, must be generated by the Gaming System and be independent of the Wireless Player Client. The client device is prohibited from containing any logic used to generate game results.

This means an operator offering mobile casino gaming through a wireless network needs both certifications. GLI-19 covers what the game does, GLI-26 covers how the game communicates over the air. A supplier who has achieved GLI-19 certification for a slot platform has not thereby satisfied GLI-26 requirements for a wireless deployment of that same platform. Compliance teams building mobile casino products should scope both certifications in parallel rather than treating one as a prerequisite for the other. For a detailed breakdown of how GLI-19 sits alongside GLI-33 for sports wagering systems, see GLI-19 vs GLI-33: Choosing the Right Certification Path.

Two-Phase Certification: Lab and On-Site

GLI-26 v2.0 section 1.5 specifies that wireless system submissions to the Test Laboratory are performed in two distinct phases. The first phase occurs within the laboratory setting. The second is an on-site evaluation following initial installation of the system to verify proper configuration of the security applications in the live environment.

This two-phase structure reflects a practical reality: a wireless network’s security posture is substantially determined by how it has been configured in situ, not merely by whether its component hardware and software are capable of meeting the standard. Default credentials changed, SSID values set correctly, encryption protocols activated, and access control policies enforced in the actual deployment, these cannot be verified from a lab bench alone.

The GLI Composite Submission Requirements v2.0 notes that for network security certification, submission requirements will be handled on a case-by-case basis between the parties requesting certification and GLI. That flexibility does not reduce the substantive requirements, it reflects the fact that every wireless deployment has a unique physical and network topology that the test laboratory must assess in context. Submission materials typically include hardware and software components, application source code, build instructions, database scripts, installation policies and procedures, network diagrams, and identification of system components.

Network Security Requirements: Encryption and Authentication

GLI-26 v2.0 Chapter 4 contains the standard’s most operationally demanding provisions. The starting point is the prohibition on Wired Equivalent Privacy (WEP): section 4.1.2 states that WEP shall not be used. This is an absolute requirement, not a preference. Any system still relying on WEP fails GLI-26 on this point alone.

WPA2 Enterprise Mode is the mandated baseline. All Access Points must be configured with Enterprise Mode enabled or, alternatively, with a strong pre-shared key. All access points must be IEEE 802.11 compliant. The encryption standard is equally precise: Advanced Encryption Standard (AES) or equivalent, with a minimum key length of 256 bits, must be used to support integrity and confidentiality services.

Key management is subject to strict lifetime controls. The Pairwise Master Key (PMK) must have a lifetime of 24 hours or less, the standard notes that changing the PMK during pre-scheduled maintenance downtime is an acceptable alternative provided this is documented in internal controls. The Group Master Key (GMK) must have a lifetime of 8 hours or less. These rotation requirements prevent the extended exposure window that makes static key configurations attractive targets.

Encryption Requirement	GLI-26 v2.0 Specification
WEP	Prohibited (section 4.1.2)
Required standard	WPA2 Enterprise Mode (IEEE 802.11 compliant)
Encryption algorithm	AES or equivalent, minimum 256-bit
PMK lifetime	24 hours or less
GMK lifetime	8 hours or less
Fallback authentication	Must be at least as strong as primary method

For all gaming-related data traversing the wireless network, section 4.2.6 mandates use of one of six encrypted tunnelling protocols: Protected EAP (PEAP), EAP-TLS, EAP-TTLS, VPN with L2TP/IPsec, PPTP, or SSL. These methods are authenticated against LDAP, RADIUS, Kerberos, or Microsoft Active Directory servers. Unsecured transport protocols, such as Bluetooth, may not be used for any function that affects game play, player account management, or any other critical gaming function (section 4.2.3).

Section 2.1.2 imposes configuration-level obligations applicable to every Wireless Device on the network. All network management functions must authenticate all users and encrypt all management communications. Hard-coded authentication credentials must be encrypted. Communication on the secure network must only be possible between approved, registered, and authenticated components, no unauthorised communications to components or access points are permitted.

Access Point Configuration: SSID and Administrative Controls

GLI-26 v2.0 section 2.2.2 governs WAP device configuration in detail. The default administration login and password must be changed from the factory default to a value controlled according to the stakeholder’s Minimum Internal Control Specifications (MICS). The default network password must similarly be changed. The Service Set Identifier (SSID) must be changed from the factory default and must not contain any reference to the site name, the manufacturer, or any other reference that could be easily discerned by an outside party. Administrative access to the WAP’s functions must be restricted to connections from the wired side of the network, using a secure protocol with a privileged user account defined in the stakeholder’s MICS.

The MICS requirement runs throughout GLI-26 v2.0. Section 1.4 establishes the expectation that the network operator or stakeholder will establish Minimum Internal Control Specifications to define internal requirements for the creation, management, and handling of the wireless network, as well as requirements for internal control of any player or operator client software, hardware, and associated accounts. The MICS is not an internal document that sits alongside GLI-26 compliance, it is the instrument through which many of the standard’s requirements are operationalised.

Area Restriction and Geographic Containment

Section 3.2.3 imposes a geographic boundary on wireless gaming operations. Connection to, and use of, a wireless network for gaming or administration purposes must be limited to a specific location as defined in the stakeholder’s MICS. Once the device is removed from the defined area, it must immediately disable and cease all gaming or administration operations.

The consequence of a device leaving the allowed area is immediate and automatic: section 3.5.1 of the standard provides that when client devices are discovered to be out of the allowed area, the system must disable any current gaming or operator sessions associated with those devices. This is not a time-delayed or grace-period mechanism. The system must respond to out-of-area detection instantly by terminating active sessions.

“Connection to, and use of a Wireless Network for gaming or administration purposes shall be limited to a specific location as defined in the stakeholder’s MICS. Once the device is removed from the defined area, it shall immediately disable and cease all gaming or administration operations.”

For casino-floor deployments where tablets are used as gaming devices issued to patrons, this geographic control is typically implemented through the WLAN’s coverage mapping: devices lose network access and therefore gaming capability the moment they move beyond the access point coverage zone defined in the MICS. The standard does not mandate a specific geolocation technology, leaving that determination to the operator’s MICS and the test laboratory’s case-by-case evaluation.

Session Management: Player and Operator Sessions

GLI-26 v2.0 distinguishes between two session types, each with specific initialisation and security requirements.

A Wireless Player Session may be managed through either an established player account or guest play (section 3.4.3). Under the established account model, the player logs in using their player account credentials, those accounts must conform to the stakeholder’s MICS and applicable jurisdictional rules. In the absence of specific regulations, GLI-16, Cashless Systems in Casinos, should be applied. Under the guest play model, Gaming Venue personnel initialise the client software using a secure method and credits are added through methods defined in the MICS.

A Wireless Operator Session is defined as a period during which operator or Gaming Venue personnel use a Wireless Operator Client device to perform administrative functions on the gaming floor (section 3.3.3). The session is initiated by the operator logging into a controlled account with a secure username and password, on either their own device or a property-provided device. The operator must be provided with, or have created, an electronic identifier such as a digital certificate or an account description and password.

Operator session inactivity is addressed separately (section 3.3.4). The wireless operator client software must employ a mechanism that detects session inactivity and terminates the session when applicable. The inactivity timeout threshold is configurable according to the stakeholder’s requirements.

User authorisation requirements under section 4.2.9 apply to both session types: wireless systems must employ a secure and controlled mechanism capable of verifying that the wireless device is being operated by an authorised person. That mechanism must be initiable on demand and on a regular basis. Critically, any authorisation information communicated by the wireless device to the system for identification purposes must be obtained at the time of the request from the wireless system, it must not be stored on the wireless client device.

Disconnection Handling and Incomplete Game Resolution

The handling of communications loss is among the most operationally consequential requirements in GLI-26 v2.0, both for player fairness and audit integrity.

Section 3.4.2 establishes the foundational rule: Wireless Player Client devices cannot conduct gaming activity if disconnected from the associated gaming server. This applies absolutely, no offline gaming is permissible under the standard.

Disconnection during a game cycle creates an incomplete game, defined in section 3.5.4 as a game or gaming activity that has been interrupted before a final outcome has been reached or where the outcome cannot be properly seen by the player. Incomplete games may result from loss of communications, a system restart, a Wireless Player Client restart or malfunction, abnormal termination of the client software, or a game-disable command issued during play.

“An incomplete game shall be resolved before a player is permitted to participate in another instance of the same game.”

Section 3.5.5 specifies how the system must handle incomplete games upon reconnection. When the player reconnects or establishes a new session, the Wireless Gaming System must present the incomplete game for completion. Where no player input is required to complete the game, the system must display the final outcome as determined by the gaming system and update the player’s account accordingly. For single-player multi-stage games where player input is required, the game must return the player to the state immediately prior to the interruption and allow them to complete it.

Session reconnection itself is also prescribed. For sessions tied to player accounts, the player may establish a new session and resume play by re-establishing their login, at minimum, through manual entry of their secure password (section 3.4.5). For all other session types, the device must be returned to the origination point or to a property representative for reactivation. No further game play is permitted until a new wireless gaming session is reestablished.

Where a game cannot be continued due to a Wireless Gaming System action (for example, a system-initiated disable), all wagers must be returned to the players of that game (section 3.5.6). A timeout due to user inactivity during a game cycle is treated as an incomplete game and handled under the same sections 3.5.3, 3.5.4, and 3.5.5 regime.

Disconnection Scenario	Required System Response (GLI-26 v2.0)
Loss of communications during game cycle	Game treated as incomplete, must be presented upon reconnection before new game is permitted
System-initiated game disable during play	Player permitted to conclude current game, game then inaccessible once concluded
Game cannot continue due to system action	All wagers must be returned to players
Inactivity timeout during game cycle	Treated as incomplete game under sections 3.5.3, 3.5.5
Device leaves allowed area	Current gaming and operator sessions immediately disabled
Reconnection (account-based session)	Manual password re-entry required, new session established before resuming play

Audit Logging, Game Records, and Player History

GLI-26 v2.0 imposes detailed logging obligations across both device and network levels. At the game enable/disable level, section 3.5.2 requires that every instance of gambling being disabled or enabled on the Wireless Gaming System must generate an audit log entry that includes the reason for the action.

Firewall audit logging requirements are specified in section 5.4.7: the firewall must maintain a log of all changes to parameters controlling permitted connections, as well as a log of all successful and unsuccessful connection attempts. These logs must be kept for 90 days, with a sample reviewed monthly for unexpected traffic. The standard recommends recording source and destination IP addresses for each instance.

If the audit log becomes full, the firewall must disable all communication, it is not permissible to simply overwrite the earliest entries. Network appliances with limited onboard storage must disable all communication when the audit log is full or offload logs to a dedicated log server (section 5.4.3).

Player-facing history requirements are specified in section 3.4.6: a ‘replay last game’ facility must be provided, either as a re-enactment or by description. The replay must clearly indicate it is a replay of the entire previous game cycle and must include, at minimum, the date and time the game started and ended, the display associated with the final outcome, and the amounts wagered and won.

For each individual game played, the Wireless Gaming System must record and maintain back-end history per session (section 3.5.9), including the unique player ID, any contributions to progressive jackpot pools, game status, table number where applicable, the paytable used, and the game identifier and version. Retention periods are defined by the stakeholder’s MICS.

System Integrity: RNG, Software Validation, and Game Logic

The standard’s client-side prohibition extends beyond disconnection handling. Under section 3.4.2, Wireless Player Client devices must not store sensitive data or system information, and client software must not be able to transfer data to other Wireless Client software except for approved chat functions and approved files such as user profile pictures. Game outcome must not be affected by the effective bandwidth, link utilisation, bit error rate, or any other characteristic of the communications channel between the gaming system and the player client.

Software integrity verification is addressed in section 3.1. Software used in a wireless network must be capable of authenticating that all software in use is valid. Upon failure of authentication routines, the system must cease all gaming operations and display an error message until the fault is corrected. This authentication must occur upon installation, each time the software is loaded for use, upon initiation of an active session, and upon request by an authorised user account defined in the MICS.

The random number generator (RNG) used in conjunction with the wireless gaming system must be cryptographically strong at the time of submission and must meet the randomness requirements established by the relevant jurisdictional authority (section 3.7). In the absence of jurisdiction-specific requirements, the GLI-11 RNG requirements apply. Game software used with the system must similarly meet each jurisdiction’s applicable game requirements, in the absence of those, GLI-11 requirements govern.

For compliance teams managing ISO/IEC 27001 programmes alongside GLI certification, it is worth noting that GLI-26 v2.0’s information security chapters (Chapter 5) draw extensively on the same control domains, asset management, access control, cryptography, incident management, software development lifecycle, and business continuity, that form the backbone of ISO 27001 implementations. The two frameworks are not formally aligned, but teams with a mature ISO 27001 posture will find many GLI-26 Chapter 5 requirements map to existing controls. See ISO/IEC 27001 in iGaming: Why Most Compliance Teams Get It Wrong for the most common implementation gaps.

Shutdown, Recovery, and Business Continuity

GLI-26 v2.0 section 3.5.7 sets out shutdown and recovery requirements. The Wireless Gaming System must be capable of performing a graceful shutdown with no data loss. Automatic restart on power-up is only permitted after specific minimum conditions are met: program resumption routines including self-tests must complete successfully, all critical control program components must be authenticated using an approved method (such as CRC, MD5, or SHA-1); and communication with all components necessary for Wireless Gaming System operation must be established and similarly authenticated.

The standard’s business continuity provisions in section 5 require a disaster recovery plan that addresses recovery from a site physically separated from the production site, with documented technical steps for re-establishing gaming functionality. In the event of a catastrophic failure where the wireless network cannot be restarted by any other means, section 4.2.8 requires that it be possible to reload the system from the last viable backup point. Backups must include, at minimum, significant events, auditing information, and site-specific configuration settings and security accounts.

GLI-26 in the Regulatory Licensing Context

GLI-26 v2.0 does not specify which jurisdictions require it. Like other GLI technical standards, it is a testing benchmark that regulators adopt by reference in their licensing frameworks or technical standards. Jurisdictions that accept GLI-certified products, including those in North America such as Ontario’s AGCO and Alberta’s AGLC, as well as multiple European and offshore markets, will typically require that any wireless gaming system deployed within their territory has been certified against a recognised wireless standard, with GLI-26 being the most widely referenced GLI benchmark for WLAN-based systems.

For operators in Ontario and Alberta, where the AGCO Registrar’s Standards for Internet Gaming and the AGLC’s Standards and Requirements for Internet Gaming both incorporate technical certification requirements, compliance teams should confirm directly with the relevant regulator whether GLI-26 certification is required alongside GLI-19 for mobile deployments. The Ontario and Alberta frameworks differ in meaningful ways that affect technical certification scope, a comparison addressed in detail in AGCO vs AGLC: Key Differences in Ontario and Alberta Internet Gaming Regulation.

The UKGC’s Remote Technical Standards (RTS) and the MGA’s technical requirements under the Gaming Act (Cap. 583) similarly incorporate security and integrity standards for online gaming systems. Neither directly references GLI-26 by name, the UKGC and MGA each publish their own technical standards, but operators seeking GLI certification alongside UKGC or MGA licences should map their GLI-26 controls against the applicable RTS or MGA technical directive to identify any gaps requiring additional documentation.

Key Resources

GLI Standard #26, Wireless Gaming Systems, Version 2.0 (February 24, 2015), Gaming Laboratories International. Available at gaminglabs.com.

GLI-19, Standards for Interactive Gaming Systems, Version 3.0 (July 17, 2020), Gaming Laboratories International. Available at gaminglabs.com.

GLI Composite Submission Requirements, Version 2.0, Gaming Laboratories International. Governs submission documentation requirements for all GLI standard certifications, including network security submissions under GLI-26.

GLI-11, Gaming Devices in Casinos, Referenced within GLI-26 v2.0 as the fallback standard for game requirements, RNG requirements, and hardware requirements in the absence of specific jurisdictional standards.