GLI-21 Client-Server Systems v2.2: Certification Requirements for Server-Based Gaming Infrastructure

GLI Standard #21, Standards for Client-Server Systems, version 2.2 (published September 6, 2011) is the primary technical benchmark governing networked gaming infrastructure on land-based gaming floors. Where GLI-11 addresses the individual gaming device and GLI-19 addresses interactive online systems, GLI-21 governs the server architecture, communication fabric, and software management processes that connect those devices into a unified, regulatorily accountable system. Manufacturers deploying server-based game floors and operators accepting such systems onto their licensed premises both carry compliance obligations under this standard. Misunderstanding the scope, or assuming that GLI-11 device certification covers the client-server layer, is one of the most common errors in pre-certification planning.

What Is a Client-Server System Under GLI-21?

GLI-21 v2.2 defines a Client-Server System (CSS) as a networked architecture in which a server component interacts with one or more Client Terminals on a gaming floor. The standard immediately bifurcates into two materially distinct system types, and the compliance obligations for each differ in ways that affect architectural design, certification scope, and internal control development.

A Server Based Game System (SBGS) is defined as the combination of a server and Client Terminals in which the Client Terminal requires continuous communication from the server, or the system portion of the Client Terminal, in order to function. The Client Terminal in an SBGS cannot operate independently when disconnected from the server, it is inherently network-dependent. Game outcome is determined server-side, and the client is effectively a rendering endpoint.

A Server Supported Game System (SSGS) operates differently. The server transfers the entire control program and game content to the Client Terminal on an intermittent basis, after which the Client Terminal is capable of operating independently. In an SSGS, game outcome is determined by the Client Terminal itself, not by the system. The server manages software distribution and may also take control of peripheral devices such as bill validators or printers, but the game logic is local to the terminal once the download is complete.

What Does GLI-21 Require for Network Communications?

Chapter Two of GLI-21 v2.2 addresses communication requirements and is the chapter most directly relevant to network architecture design. The standard imposes a hierarchy of requirements across data integrity, system security, and remote access that together define the minimum acceptable network posture for a CSS deployment.

GLI-21 Section 2.1 requires that the CSS implement mechanisms designed to prevent tampering with communications between server and client. The standard strongly recommends encryption with secure seeds or algorithms for this purpose. Alternative measures are permitted but will be reviewed on a case-by-case basis and require explicit regulator approval, a standard cannot be substituted with a security control that has not been reviewed by the testing laboratory in this specific context.

“For a Server Based Game System (SBGS), a client must be rendered unplayable if communications from the server or system portion of the Client Terminal is lost. If a game is in progress, a mechanism must be provided to recover to the point of the game when communications was lost.”

This is GLI-21 Section 2.1.3. The loss-of-communications obligation has two components. The Client Terminal must lock out play immediately on server disconnection, there is no grace period and no permissible mode of continued operation while disconnected. Concurrently, if a game was in progress at the moment of disconnection, the system must be able to restore game state to that exact point. In a multi-player environment, an alternative is available: the game may be aborted and player wagers refunded. For cashless credits held on a Server Based Client Terminal at the time of disconnection, the CSS must provide an alternative redemption mechanism, such as a hand pay, to allow the patron to cash out those credits.

Network Security and Firewall Requirements

GLI-21 Section 2.2.1 establishes the baseline network security requirement for CSS deployments integrated with any external network. All communications, including remote access communications, must pass through at least one approved application-level firewall. The standard prohibits any facility that would allow an alternate network path to bypass this firewall. This is an architectural constraint, not merely a configuration requirement: the system topology itself must be designed so that no routing decision can circumvent the approved firewall.

Section 2.2 also requires that the CSS implement controls against predefined thresholds being exceeded on network traffic or connection parameters, with automatic notification to the system administrator when any such threshold is breached. The specific thresholds are established in conjunction with the testing laboratory and approved regulator, not unilaterally by the manufacturer.

Remote Access: Approval, Auditing, and Prohibition

Remote access under GLI-21 is defined as any access to the CSS that originates outside the “Trusted” Network. GLI-21 Section 2.3.1 permits remote access where it is authorised, but subjects it to a specific set of hard prohibitions that cannot be waived by operator policy alone.

Authorised remote access must authenticate all computer systems based on the CSS or firewall application settings that govern the connection. The security posture of any remote access arrangement is reviewed on a case-by-case basis by the local regulatory agency, blanket approval for a class of remote access methods is not available under this standard.

Three prohibitions apply regardless of whether remote access is otherwise authorised. No unauthorised remote user administration is permitted, covering actions such as adding users, changing permissions, or any other user management function. No unauthorised access to any database other than information retrieval through existing system functions is permitted. No unauthorised access to the operating system is permitted.

The standard expressly acknowledges that system manufacturers may remotely access the CSS and its associated components for product support or user support purposes, provided this is permitted by the relevant regulatory authority. This manufacturer carve-out must be specifically authorised rather than assumed.

GLI-21 Section 2.3.2 requires that the CSS Server maintain an activity log for all remote access sessions, capturing at minimum the authorising party, the purpose, the logon name, time and date, duration, and all activity conducted during the session. This log must be maintained both by the property and by the manufacturer.

CSS Server Requirements: Architecture, Security, and Access Controls

Chapter Three of GLI-21 v2.2 addresses the “back of house” requirements for the CSS Server itself. It opens with an important scoping clarification: the Game Server may be located locally within a single facility or may be remotely located outside the facility over a Wide Area Network (WAN). Where a CSS Server also performs functions required by other systems, such as an On-Line Monitoring and Control System or a Ticket Validation System, those functions are evaluated against the standards applicable to those systems, not GLI-21.

Section 3.2 addresses multiple-server deployments, which are common in production environments. A CSS may comprise a collection of servers deployed for load balancing, redundancy, or functional separation. The standard permits this architecture explicitly: there might be separate game servers, a finance server, a monitoring server, and a download server, each handling distinct functions. The compliance obligation is that the system as a whole must meet all GLI-21 requirements. Individual servers within the collection are not each required to satisfy every requirement independently, the system-level view applies.

Server Security and Access Restrictions

For an SBGS, the Game Server must generate and transmit to the Client Terminals all control, configuration, and information data that the terminal requires to function. Section 3.3.3 requires that all servers maintain sufficient physical and logical intrusion protection against unauthorised access. The standard frames the ideal posture as one requiring joint access by both the manufacturer and the Regulatory Authority, with neither able to gain access separately.

Section 3.3.4 requires that the CSS interface element setup and configuration menus be unavailable unless accessed through an authorised, secure method. Section 3.3.5 imposes a hard prohibition on operator-level programming of the server: there must be no means available for an operator to conduct programming on the server in any configuration, including execution of SQL statements to modify the database. Network Administrators may perform authorised network infrastructure maintenance using SQL statements that are already resident on the system, provided they have sufficient access rights.

Backup, Recovery, and Self-Monitoring Obligations

GLI-21 Section 3.5 governs data backup. The minimum backup frequency is once every 24 hours, though the testing laboratory reviews the specific backup scheme implementation on a case-by-case basis. The backup requirement is not optional and applies to all CSS deployments regardless of server topology.

Section 3.5.2 addresses catastrophic failure recovery. Where the CSS cannot be restarted by any other means, it must be possible to reload the database from the last viable backup point and fully recover its contents. The standard specifies a minimum set of recoverable information: significant events, auditing information, and site-specific information such as game configuration and security accounts.

Section 3.6 establishes self-monitoring requirements. The CSS must implement automated self-monitoring of all critical Interface Elements, including central hosts, network devices, firewalls, and links to third parties. The system must be capable of notifying the system administrator of any detected condition, provided the condition is not itself catastrophic. Self-monitoring must execute at a frequency of at least once in every 24-hour period.

Software Verification and Controlled Component Authentication

GLI-21 Section 3.7 addresses the verification of software residing on the CSS. The system must prevent the execution of any control program component that is determined to be invalid. On detection of an error, the system must provide visual notification of the invalid program. A critical design requirement applies to the verification mechanism itself: a program component of the verification mechanism must reside on and securely load from non-alterable media. The integrity of the verification process cannot depend on software stored on alterable media that could itself be tampered with.

Section 3.7 requires that a report be available detailing the outcome of each automated execution of the validation mechanism, identifying any invalid program components. For controlled components, the CSS must employ a third-party industry-standard secure hashing algorithm for authentication. MD-5 or SHA-1 are cited as examples. If an algorithm is embedded in the system, the manufacturer must be prepared to demonstrate the algorithm to both the testing laboratory and the Commission.

“In the event of failed authentication the CSS shall deactivate the controlled component in a manner in which the following functions, including, but not limited to, download, install, and configuration of the controlled component to a connected Client Terminal, is not possible. The CSS shall also provide a mechanism to provide notification of the authentication failure to the Commission.”

This deactivation requirement on authentication failure is absolute. A system that logs a failure but continues to allow download or installation of the suspect component does not satisfy GLI-21 Section 3.7.

Server Recall and Game History Requirements

GLI-21 Section 3.8 governs server recall for Server Based Games. The server must be able to display a complete play history covering the most recent game played and at least nine prior games for each client station connected to it. This minimum depth of ten games per station is a floor, not a target, jurisdictions may impose deeper recall requirements. The recall capability must include cashless transaction logs for each client station that incremented any cashless in- or out-meters, and the capability to initiate a transaction history inquiry must be available at the Client Terminal itself for transactions associated with that specific terminal.

Recall Element	GLI-21 Minimum Requirement
Play history depth	Most recent game + at least 9 prior games per client station
Error logs	Must be retained and accessible
Drop meters	All drop meters retained
Bill recall	Required
Cashless transaction logs	Per client station, covering all cashless in/out meter increments
Audit logs	Client Terminal Game Program transaction audit logs

The Download Data Library: A Regulator-Controlled Asset

GLI-21 Section 3.9 establishes the Download Data Library (DDL) as the formal storage location for all approved data files that may be downloaded to Client Terminals, covering control and game software, peripheral firmware, and configuration data. The DDL is defined in the standard’s glossary as a regulator-controlled library residing at the CSS server.

Section 3.9.2 specifies two permissible write-access models for the DDL. Under the first, access is controlled by the regulator, and the manufacturer and operator may access the DDL provided this access does not permit adding new Download Data Files, they can read and use approved files, but cannot introduce new ones without regulator authorisation. Under the second, the DDL may only be written to using a method that is acceptable to both the testing laboratory and the regulator.

Section 3.9.3 mandates an audit log for all changes to the DDL. Every addition, modification, or deletion of a file must be logged with sufficient granularity to support regulatory review. The DDL audit log is a primary source for regulators investigating whether unapproved software was introduced to a gaming floor.

Downloading Control Programs to Client Terminals

GLI-21 Section 3.10 governs the mechanics of downloading software from the server to Client Terminals. This section applies to both SBGS and SSGS deployments where the server provides download functionality. Two specific requirements in Section 3.10.2 merit particular attention during operational planning.

The Client Terminal and/or the SSGS Server must have a method to monitor and report to the Slot Monitoring System all external door access occurring during a foreground program download or activation process. Where the system lacks this monitoring capability, the testing laboratory’s report must note this limitation, and internal controls must be developed to address the resulting physical security gap.

Prior to execution of updated software, the Client Terminal must be in an Idle State for a defined period. The Idle State is defined in the GLI-21 glossary as the condition in which the Client Terminal is disabled, has no activity, holds no credits, and is not in an error condition. Software updates may not execute while a game is in progress or while credits remain on the meter.

Paytable and Denomination Configuration via the CSS

GLI-21 Section 3.11.2 provides a conditional waiver of the Regulatory Control requirement for paytable and denomination changes made through the CSS Server. Without this provision, every paytable change on a networked floor would require the same regulatory approval process as a physical hardware modification under GLI-11. The waiver applies where five conditions are simultaneously satisfied.

All available paytables must meet local theoretical payback percentage and odds requirements. The Client Terminal and/or CSS Server must maintain Amounts Bet and Amounts Won meters within Critical Memory for each available paytable. The Client Terminal must maintain Master Accounting meters in the local currency at the lowest available denomination. The game must be in an Idle State when the update occurs. The change must not cause inaccurate crediting or payment, which excludes games using coin hoppers or coin acceptors with a fixed denomination from this waiver.

Section 3.11.3 addresses Critical Memory clears via the CSS. Clearing Client Terminal critical memory through the server must use a secure method that requires Regulatory Control. Systems that do not satisfy this requirement must obtain specific regulator approval for the alternative method used.

Testing Phases and Submission Structure

GLI-21 v2.2 Section 1.6 specifies that CSS submissions to the testing laboratory will be performed in phases. The standard does not prescribe a rigid number of phases universally, recognising that the appropriate phase structure depends on the complexity of the system under review. What the standard does establish is that the system as a whole, including all server components and all Client Terminal types connected to it, must be represented in the submission scope.

The standard’s acknowledgements in Section 1.2 identify the regulatory bodies and technical references that informed its development. These include the Nevada Gaming Control Board, Australian state and territory gaming authorities, the New Zealand Casino Control Authority, NIST Special Publication 800-57 on key management, and the GSA G2S and S2S protocol standards. The jurisdictional breadth of these acknowledgements signals that GLI-21 was designed for multi-jurisdictional acceptance rather than a single regulatory framework. Operators deploying CSS infrastructure across multiple licensed jurisdictions should verify whether each regulator requires its own jurisdiction-specific addendum to the GLI-21 certification or accepts a base certification with a supplemental jurisdiction review.

Interaction with Adjacent GLI Standards

GLI-21 v2.2 explicitly limits its own scope. Where a CSS Server also performs functions required by other GLI standards, such as an On-Line Monitoring and Control System or a Ticket Validation System, those elements must be evaluated against the applicable standard rather than GLI-21. The standard cross-references GLI-11 Standards for Gaming Devices directly, particularly regarding alterable configurations and Regulatory Control requirements in Section 1.5 of that standard. For operators deploying a fully integrated gaming floor, the practical consequence is that GLI-21 certification of the server-side infrastructure does not substitute for GLI-11 certification of the individual device, and vice versa. Both certifications must be in place and must be consistent in their treatment of shared parameters such as meter definitions and critical memory.

Compliance teams managing multi-standard certification programmes should also note that the standard’s Section 1.4 directs readers to Gaming Laboratories International’s website for the complete list of GLI standards that may apply concurrently. For server-based gaming floors that include downloadable content, cashless wagering systems, or wide area progressive jackpot networks, additional standards will almost certainly apply. The GLI Certification hub provides a structured reference for navigating the full family of GLI standards and their jurisdictional adoption patterns.

Teams preparing for a first GLI-21 submission who are also managing interactive or online product lines should review the distinctions between GLI-21 and GLI-19, which governs interactive gaming systems. The architectural assumptions differ materially: GLI-19 presupposes a system in which online players access game content remotely, while GLI-21 addresses physical Client Terminals on a licensed gaming floor connected to a local or WAN-hosted server. A detailed comparison of GLI standard selection for different certification paths is available as a companion reference.

“One should be cautioned that this document should not be read in such a way that limits the use of future technology. The document should not be interpreted that if the technology is not mentioned, then it is not allowed.”

This passage from GLI-21 Section 1.3.2 carries practical significance for operators deploying modern CSS architectures that use virtualised server environments, cloud-hosted WAN components, or software-defined networking. The standard’s technology-neutral posture means these architectures are not automatically excluded, but they also are not automatically approved. Each novel implementation requires case-by-case review by the testing laboratory and the relevant regulator, which should be planned into the certification timeline from the outset.

Practical Compliance Checklist for Certification Submissions

Compliance Area	GLI-21 Section	Key Requirement
System classification	1.5	Determine SBGS or SSGS, document basis for classification
Communications integrity	2.1	Encryption or approved alternative, regulator sign-off required for alternatives
Loss-of-comms handling (SBGS)	2.1.3	Immediate lockout, game-state recovery mechanism, hand pay for cashless credits
Firewall architecture	2.2.1	Approved application-level firewall, no alternate network path
Remote access	2.3	Regulatory approval, full activity log, three hard prohibitions enforced
Server intrusion protection	3.3.3	Physical and logical controls, joint manufacturer-regulator access preferred
Operator programming prohibition	3.3.5	No operator SQL or programming access, Network Admin access scope-limited
Backup frequency	3.5	Minimum daily, scheme reviewed by testing laboratory
Self-monitoring	3.6	All critical Interface Elements, minimum 24-hour cycle, admin notification
Software verification	3.7	Industry-standard hash algorithm, deactivation on failure, Commission notification
Game recall depth	3.8	Most recent + 9 prior games per client station, cashless transaction logs
Download Data Library	3.9	Regulator-controlled write access, full audit log for all changes
Software downloads	3.10	Idle State required before execution, door-access monitoring during download
Paytable configuration	3.11.2	Five conditions for regulatory control waiver, all must be satisfied concurrently
Critical memory clear	3.11.3	Secure method requiring Regulatory Control, regulator approval required for alternatives

Operators and manufacturers preparing GLI-21 submissions should engage qualified legal counsel and a licensed independent testing laboratory before commencing pre-certification work. The standard’s case-by-case review provisions for encryption alternatives, remote access, backup schemes, and novel technology deployments mean that jurisdictional context affects the precise compliance posture in ways that a single reading of the standard cannot fully resolve. Counsel familiar with the regulatory authority in the deployment jurisdiction is essential for navigating these discretionary review points.

For compliance teams also managing information security frameworks alongside GLI certification, the interaction between GLI-21’s server security requirements and ISO/IEC 27001 controls is worth mapping early. Common gaps in ISO 27001 implementation in iGaming frequently arise precisely in the areas GLI-21 also addresses: access control architecture, audit logging completeness, and the scope definition for network security controls.

Key Resources

GLI Standard #21, Standards for Client-Server Systems, Version 2.2 (September 6, 2011), Gaming Laboratories International. The primary technical standard governing all Client-Server System certifications referenced throughout this article.

GLI Standard #11, Standards for Gaming Devices, Version 3.0, Gaming Laboratories International. Cross-referenced by GLI-21 for Regulatory Control requirements and alterable configuration standards applicable to Client Terminals.

NIST Special Publication 800-57, Recommendations for Key Management, Part 2, National Institute of Standards and Technology. Referenced in GLI-21 as a key management best-practices document informing the standard’s encryption and algorithm requirements.

GSA G2S and S2S Protocol Standards, Gaming Standards Association. Referenced in GLI-21 as foundational protocol standards for the communication layer within Client-Server Systems. To deepen your understanding of GLI-21 requirements and begin your compliance assessment, consult the GLI Certification hub or contact a qualified testing laboratory in your jurisdiction.