How often does RNG certification need to be renewed or re-tested

An RNG certificate confirms the compliance of a specific version of the generator and its implementation, not all future updates to the gaming system. Even if the document has no expiry date, changes to the algorithm, entropy source or related game logic may require re-testing. Additional checks may also be conducted during periodic audits or at the regulator’s request. Relying on an outdated certificate creates a risk that the production version no longer matches the tested configuration. In this article, we explain how often RNG certification must be renewed, which changes require re-testing and how to manage certified versions.

What RNG certification actually covers

RNG certification confirms that a defined version of a random number generator meets the applicable technical standard. It does not automatically certify the entire gaming platform or every game connected to that generator.

Depending on the product and regulatory regime, an independent testing laboratory may assess:

• The RNG algorithm, entropy source and seeding process;
• Resistance to predictability, bias and manipulation;
• Statistical distribution of generated values
• Conversion of RNG output into game outcomes;
• Source code, configuration and relevant interfaces.

For example, GLI-19 establishes technical requirements for random number generation within interactive gaming systems. However, the regulator determines which standard and testing scope apply in a particular jurisdiction.

RNG certification should be distinguished from other forms of technical assessment. Game testing may cover mathematics, paytables, rules, return to player and the mapping of random values to outcomes. A platform audit may examine security, access controls, transaction records, deployment procedures and change management.

The operator should therefore verify the exact scope of each certificate. Relevant details include the tested software version, build number, RNG type, applicable standard, laboratory, issue date and report reference. A certificate issued for another version or implementation may not cover the production system.

Using the same RNG across several games also does not necessarily mean that all games are certified. Each integration may require separate assessment of outcome mapping and game mathematics. Where a third-party platform or game supplier provides the certificate, the operator must confirm that it applies to the software and configuration actually deployed.

Does an RNG certificate have an expiry date?

There is no universal validity period for an RNG certificate. Testing frequency depends on the relevant jurisdiction, regulatory requirements and certification scope. The rule that a certificate must be renewed annually therefore does not apply to all operators and suppliers.

In many cases, a certificate remains applicable while the RNG continues to operate as tested. GLI expressly states that product certification reports remain valid as long as the product is used in the field as tested. The validity of the GLI Certified Mark and the technical report are separate matters: the right to use the mark must be renewed annually, but this does not automatically require RNG re-testing.

A certificate may cease to apply if:

• The code, algorithm or entropy source changes;
• The RNG is moved to a different technical environment;
• The method of converting random values into game outcomes changes;
• The released product version does not match the tested build;
• The regulator updates its technical standard or requires new testing;
• The laboratory suspends or withdraws the certification.

The issue date is not the only criterion. The version number, configuration, testing standard, covered components and jurisdiction for which the report was prepared must also be checked.

An older certificate is therefore not necessarily invalid, while a newer one may not cover the current production version. The operator must maintain continuous alignment between the tested RNG and the system actually used to determine game outcomes.

When RNG re-testing becomes mandatory

Re-testing is triggered not by a fixed schedule but by changes that may affect the generation or use of random values. Before releasing an update, the operator or supplier must determine whether it affects a certified component.

Under GLI gaming device submission requirements, an RNG must be resubmitted for certification if its code or implementation changes. Testing is also required when a previously certified generator is moved to a new hardware platform or produces values outside the previously tested range.

Reassessment may be triggered by:

• Changes to the algorithm, seeding mechanism or entropy source;
• Updates to RNG-related libraries or modules;
• Migration to a new server, processor or operating environment;
• Changes to the range or format of output values;
• New logic for converting random numbers into game outcomes;
• Correction of an error affecting outcome probabilities;
• A vulnerability or incident affecting RNG integrity.

Not every technical update requires full repetition of the original tests. The laboratory may first conduct a change assessment to determine the required scope. This may be limited to specific modules or include renewed statistical and integration testing.

The operator should not classify a change as immaterial without proper assessment. Before deployment, the new version must be compared with the certified build, the changes documented, and an opinion obtained from the laboratory or regulator where required. Otherwise, the existing certificate may not cover the updated product.

Periodic testing requirements across jurisdictions

Regulators use different technical control models. Some require pre-release testing of new games and annual audits of specific processes. Others focus on certification before launch and reassessment of material changes. There is no universal rule requiring annual re-certification of every RNG.

1. Great Britain. Operators subject to the relevant UK Gambling Commission requirements must submit game and RNG test results before releasing a new game or major update. Companies holding both a gambling software licence and certain remote operating licences must undergo an annual game testing audit. However, this audit does not amount to mandatory annual re-certification of every unchanged RNG. 
2. Malta. When adding new games using an RNG that has not been approved, the MGA requires a valid certificate from an independent laboratory and technical documentation. Changes to critical game elements follow a similar procedure. Changes to essential components also require prior approval. New testing is therefore linked primarily to the product and its changes, not merely to the passage of time.
3. Nevis. NOGA requirements provide for independent RNG certificates for proprietary games. When using third-party games, the operator must confirm its legal right to the content and hold the applicable technical documents.

In practice, testing frequency cannot be determined solely by the company’s jurisdiction of incorporation. The licence type, game, content delivery model and change history must also be considered. An existing report may remain sufficient for one product, while another requires an annual audit or new testing before an update is released.

Renewal, re-testing and ongoing monitoring are not the same

Certificate renewal, re-testing and ongoing technical monitoring serve different purposes. Confusing them may cause unnecessary costs or reliance on a document that no longer covers the production system.

Renewal usually concerns the formal validity of a document, status or right to use a certification mark. The laboratory may request confirmation that the product remains in its tested configuration. Full repetition of the original tests is not always required.

Re-testing is a new technical assessment. Its scope depends on the changes made. The laboratory may examine one updated module or re-evaluate the RNG, game mathematics and conversion of random values into game outcomes.

Ongoing monitoring takes place while the product is in operation. It may include:

• Monitoring actual RTP and outcome distribution;
• Analysing errors and unusual deviations;
• Comparing production builds with certified versions;
• Reviewing change logs and access rights;
• Investigating player complaints and technical incidents.

Monitoring does not replace certification because it assesses a product already in operation. At the same time, a valid certificate does not relieve the operator from reviewing actual results. Integration errors, incorrect configurations or unauthorised changes may arise after laboratory testing.

Each procedure should have its own basis, deadline and responsible person. Certificates are managed by the compliance or certification function, technical changes by development and change management teams, and production metrics by the operator together with the supplier. This makes it possible to determine when an internal review is sufficient and when the laboratory or regulator must be involved.

How to manage RNG changes without disrupting operations

RNG changes must be incorporated into the overall release process. If testing begins after a new version has been deployed, the operator may have to suspend games, roll back the update or repeat the regulatory approval process.

Before development starts, the operator should determine whether the update affects certified code, the entropy source, value range or game outcome mapping. The operator and supplier must compare the planned release with the scope of the current certificate.

The practical process includes:

• Change description. The development team records the affected modules, versions and reasons for the update.
• Regulatory impact assessment. The compliance function reviews the licence conditions and determines whether notification, prior approval or re-testing is required.
• Laboratory submission. Technical documents and the change list are sent to the test house to define the testing scope.
• Pre-release testing. The update is deployed in a controlled environment matching the intended production configuration.
• Document updates. New reports, certificates, release notes and approvals are linked to the relevant build.
• Controlled deployment. Only a version that has completed the required checks is released into production.

Agreements with game or platform providers should set deadlines for notifying the operator of changes. The operator also needs access to certificates, test reports and lists of covered versions. A general supplier certificate that does not identify the deployed build is insufficient for effective control.

A central certification register can reduce these risks. It should record the product, RNG, version, laboratory, applicable standard, report date, licensed markets and related approvals. These details should be checked against the change log before each release. This prevents deployment of an update outside the existing certification scope.

Risks of relying on an outdated RNG certificate

The main risk is not the age of the document but a mismatch between the certificate and the product actually in use. Even a recent report is ineffective if it covers a different RNG version, configuration or limited set of games.

During a review, the regulator or laboratory may determine that the certificate does not cover the production build. Possible consequences depend on the jurisdiction and nature of the breach:

• Delay in launching a new game or entering a market;
• Temporary suspension of the affected product;
• Additional testing at the operator’s or supplier’s expense;
• Correction of the games register and regulatory file;
• Refunding bets or compensating players for incorrect outcomes;
• Fines, licence restrictions or other regulatory measures.

A separate issue is the absence of evidence that the software remained unchanged. Without release notes, checksums, deployment records and approvals, proving conformity with the certified version may be difficult even if the RNG contains no errors.

Supplier documents may create further risks. A certificate may cover only the supplier’s core gaming engine, not the operator’s integration or an individual game. The report may also follow a different technical standard or be unrecognised by the target-market regulator.

If a mismatch is identified, the affected release should be restricted, logs and technical data preserved, and the laboratory and regulator notified as required. Replacing files or redeploying the product without documentation may complicate the investigation.

Regular comparison of certificates with the production environment helps identify problems before a regulatory audit or player complaint. This review is particularly important after platform migrations, supplier changes and major updates.

How Key2Law supports RNG certification and compliance

Key2Law team helps gaming operators and software providers determine when initial RNG certification, re-testing or approval of technical changes is required. We consider the product type, licensing jurisdiction, supplier structure and actual system configuration.

The Key2Law team provides comprehensive support:

• Identifying applicable RNG and game testing requirements;
• Reviewing the scope of existing certificates;
• Comparing certified versions with the production environment;
• Assessing the regulatory impact of technical changes;
• Preparing change assessments and test house documentation;
• Reviewing agreements with game, platform and RNG providers;
• Allocating responsibility for testing and update notifications;
• Developing an internal certification register and release procedure;
• Supporting regulatory notifications and approvals;
• Preparing for technical or compliance audits.

A proper approach does not require re-testing an unchanged RNG without an established basis. It should provide documented evidence that the certificate covers the current product and is recognised in the target market.

If you plan to launch a new game, update an RNG or migrate a platform, contact the Key2Law team before deploying the changes. We will help determine the required testing scope, prepare the documents and integrate certification into the release process without unnecessary delays.

___________________________________

This article is provided for general informational purposes and does not constitute legal, tax or financial advice. Applicable requirements depend on the jurisdiction and specific circumstances; professional advice should be obtained before making legal or business decisions.