Certified Random Number Generator: Labs, Testing, and Renewal

To get a certified random number generator for a gaming product, you submit your RNG — source code, mathematical documentation, and sample output — to an accredited independent testing laboratory, pass its statistical and security evaluation against the standards your target regulator uses, and file the resulting compliance report with the gaming authority before you go live. The evaluation usually runs two to eight weeks for a clean submission and longer when the lab finds issues that need fixing. No regulated jurisdiction will license your product without that report in hand.

What the Lab Is Actually Testing

Certification exists because the RNG replaces the physical shuffle, dice roll, or wheel spin. If it is flawed or manipulable, the whole game is compromised, so regulators want independent proof that the odds you advertise match what the software delivers and that no one can predict or influence outcomes.¹ Every framework in common use — GLI-19 for interactive gaming, GLI-11 for casino devices, the UK Gambling Commission’s RTS 7, and 25 CFR Part 547 for tribal gaming in the United States — checks the same three properties, in slightly different language.

Statistical Randomness

Your output has to look random both in isolation and in the combinations the game actually uses. Federal tribal gaming standards require the RNG to pass recognized statistical tests at a 99% confidence level, and list ten acceptable ones by name, including the chi-square, runs, serial correlation, frequency, gap, poker, coupon collector’s, permutation, and spectral tests along with tests on subsequences.² Labs also commonly run the NIST SP 800-22 suite of 15 tests.³

The scaling algorithm — the code that maps raw RNG output to a card, a reel position, a number — gets tested alongside the generator itself. Federal standards require scaling to be independent, uniform over the range, capable of producing every possible outcome, and unbiased to within 1 in 50 million.²

Unpredictability

Passing statistical tests is not enough. Your output must also be computationally infeasible to predict, even for someone who knows the algorithm and has watched a long run of past numbers.⁴ This is where algorithm choice matters. The Mersenne Twister and similar general-purpose generators clear basic statistical tests but are not cryptographically secure; from a modest output sample an attacker can recover the internal state and predict every future number. Gaming regulators will reject that.

GLI-19 requires RNGs used for outcome determination to be cryptographically strong, resistant to direct cryptanalytic attack, known input attack, and state compromise extension attack, even against an adversary who has the source code.⁵ In practice that means AES in counter mode, SHA-based generators, or hardware entropy sources rather than a general-purpose PRNG. The generator must also be continuously reseeded or cycled, and reseeding inputs must be at least as statistically random as the RNG’s own output.²

Non-Repeatability

The RNG cannot be initialized to reproduce a previous output stream, and two instances running at the same time cannot produce the same sequence. Initial seeding has to come from a true random source, such as a hardware noise generator, or from a combination of timestamps, system-specific parameters, and previous RNG outputs that together defeat reproducibility.² A seed drawn from a time value alone will fail certification, because the seed can be reconstructed.⁵

One rule catches developers off guard: the game must consume RNG output immediately and in order. No discarding unfavorable numbers, no cherry-picking from a batch, no adjusting outcomes against a history of previous prizes, and no “reflexive software” that sits between the generator and the player and modifies results.²

Alongside the algorithm, the lab evaluates the security infrastructure around it: authenticated access with credentials stored to standards such as FIPS 140-2, tiered permissions, full access logging, application-level firewalling, and intrusion detection. Remote access is permitted only with regulator authorization and multi-factor authentication, and only to application functions, not to the underlying operating system or database.⁵ Hardware entropy sources must be monitored in real time by ongoing statistical tests that automatically disable gameplay if the source degrades.

What to Send the Lab

Labs will not start the clock until the submission is complete, and incomplete packages are one of the most common causes of delay. Expect to provide:

Complete, well-commented source code, organized so an outside engineer can follow the algorithm line by line.
Mathematical documentation describing the algorithm, whether it is software or hardware based, how seeding and reseeding work, which cryptographic primitives are used, and how the scaling algorithm maps raw output to game outcomes.
Hardware specifications and manufacturer data sheets if the RNG uses a physical entropy source such as thermal noise or radioactive decay.
Raw output samples, typically millions of generated numbers, for preliminary statistical analysis before the source-code review begins.

Under the UK regime, the operator and the chosen test house agree on the scope of testing in advance, covering documentation review, algorithm research, source-code verification, and statistical testing of both raw output and scaled game data.¹ Getting that scope right at the start prevents re-scoping halfway through.

How the Testing Runs

Once the submission is accepted as complete, the evaluation moves through documentation review, algorithm research (checking for publicly known weaknesses in the chosen approach), source-code verification against the documentation, and statistical testing of both raw output and scaled game data.¹ For a full game rather than a standalone RNG, the lab also checks the game math, artwork, displayed rules, and theoretical return-to-player, running the software in an environment that mirrors the live deployment and confirming actual RTP matches the theoretical figure.

A passing evaluation ends in a formal written report certifying compliance with the applicable standards.⁶ That report is what you file with the gaming commission when applying for or renewing your operating permit. Timeline from submission to final report generally runs two to eight weeks when things go smoothly; straightforward software RNGs with clean documentation come in on the short end, complex or hardware-based systems on the long end.

Choosing a Lab Regulators Will Accept

Only accredited independent laboratories can issue reports regulators will accept. The major labs serving the industry include Gaming Laboratories International, BMM Testlabs, eCOGRA, and iTech Labs. Their authority rests on accreditation to ISO/IEC 17025, the international standard for testing laboratory competence: GLI operates ISO/IEC 17025:2017 accredited labs on six continents,⁷ BMM holds expanded ISO 17025 accreditation covering additional certification protocols,⁸ and eCOGRA is ISO/IEC 17025:2017 accredited for Great Britain, Greece, Denmark, Sweden, and Switzerland, among others.⁹

Reach matters as much as quality. A report from a lab recognized across multiple jurisdictions saves you from repeating full evaluations when you expand into a new market; some labs offer targeted gap-analysis testing to bring a previously approved game into compliance for an additional regulator rather than starting over. Federal tribal gaming regulations go a step further and require the tribal gaming regulatory authority to independently verify that any lab it accepts reports from demonstrates integrity, independence, financial stability, and technical capability.¹⁰ Confirm with your target regulator that they recognize the lab before you engage it.

If Your RNG Fails

A failed evaluation is not the end of the process, but it costs weeks. The report will describe the specific deficiencies: a statistical test that missed the confidence threshold, a predictable seeding mechanism, code that does not match the documentation, gaps in the security infrastructure. You remediate and resubmit. This is where most timeline overruns happen. A clean submission can clear in two or three weeks; a cycle of fix and resubmit that touches the algorithm or the architecture can stretch into months. Keeping open communication with the assigned engineers helps, because they can flag issues informally before the formal report is finalized.

Design your codebase with recertification in mind. Under federal tribal gaming standards, modifications to previously certified software may be handled with a lab report confirming the changes maintain or advance compliance, while software written from scratch has to be fully tested from the ground up.¹¹ Incremental updates to a certified base are far cheaper to re-clear than a rewrite.

Keeping Certification Current

Certification is not a one-time event. The UK Gambling Commission requires external retesting for every new game and for updates to existing games where the change affects fairness; when the RNG or the remote gaming system that hosts it is updated in a way that could affect the games it serves, a representative sample of those games has to be retested.¹ Cosmetic changes, localization, and bug fixes unrelated to the RNG generally do not require external retesting, though your own QA should confirm nothing has moved.

Some jurisdictions require periodic recertification on a fixed schedule regardless of whether you have changed anything, with annual cycles common in European markets. Build that cadence into your budget and release calendar. A lapsed certification can force your product offline until the lab finishes retesting.

1
Gambling Commission. Testing Strategy for Compliance With Remote Gambling and Software Technical Standards
2
eCFR. 25 CFR 547.14 – Minimum Technical Standards for Electronic Random Number Generation
3
National Institute of Standards and Technology. A Statistical Test Suite for Random and Pseudorandom Number Generators for Cryptographic Applications
4
Gambling Commission. Remote Gambling and Software Technical Standards – RTS 7 Generation of Random Outcomes
5
Gaming Laboratories International. GLI-19 Interactive Gaming Systems v3.0
6
eCFR. 25 CFR Part 547 – Minimum Technical Standards for Class II Gaming Systems and Equipment
7
Gaming Laboratories International. GLI Receives A2LA ISO/IEC 17025:2017 Accreditation for Noida and Moncton Laboratories
8
BMM Testlabs. BMM Testlabs Announces Expanded ISO Accreditation to Cover Full GSA Certification Requirements
9
eCOGRA. Game Testing and Certification Services
10
eCFR. 25 CFR 547.5 – How Does a Tribal Government, TGRA, or Tribal Gaming Operation Comply With This Part
11
National Indian Gaming Commission. Bulletin No. 2008-3 – Compliance Guidance for New Technical Standards 25 CFR Part 547