How is penetration testing an online lottery different from testing a casino?

A casino is mostly continuous play: many small bets settled immediately. A lottery is built around three discrete events: ticket sales that close at a fixed time, a draw that produces a result once, and a prize payout that follows. The test should follow those events, with special attention to what can be changed after sales close and who can alter a result or a winner list.

Does a penetration test certify the draw or the random number generator?

No. Draw integrity and random number generation are assessed under separate laboratory or regulator-defined processes. A penetration test looks at whether an attacker, or an insider with a normal account, could reach the systems around the draw: the admin tools, the results pipeline, the ticket database and the payout workflow. State that exclusion in the scope.

What is the most sensitive moment to test around?

The window between ticket sales closing and the result being published. Anything that could add, alter or cancel a ticket, or change a result or a winner list, after the cutoff is the highest-impact finding class. Agree in advance which of those paths may be exercised with test data and which must be reviewed by walkthrough only.

Should the test run against production or a staging copy?

Use a staging environment for anything that touches a draw, a result or a payout, and populate it with test tickets and test accounts. Production testing, if any, should be limited to read-only checks of the public site and login, with written rules of engagement and no live draw or payout in flight.

Which ticket sales channels should be in scope?

Every channel that can create a ticket or touch an account: the website, the mobile app, any retailer or agent terminals, subscription or auto-play services and any partner API. Each is a separate entry point with its own authentication, so list them individually rather than testing only the main site.

Online Lottery Penetration Testing: Draw and Payout Scope

The short answer

An online lottery is tested around three events: ticket sales closing, the draw, and the prize payout. Scope the penetration test to what an attacker or insider could change at each event, especially after sales close, and test draw and payout paths in staging with test data. Exclude random number generation and draw certification, which are assessed separately.

Who this is for

This is for a CTO, head of security or compliance lead at an online lottery operator, a lottery retailer's digital arm or an iGaming company adding lottery products, who is buying or reviewing a penetration test. Casino cashiers, sportsbook bet placement and poker table state already have their own scoping articles; lotteries differ because the risk is concentrated in fixed, irreversible moments rather than continuous play.

Why a lottery is not a casino with fewer games

A casino session is a stream of small, independent events. A bet is placed, settled and forgotten, and a flaw usually costs a bounded amount per attempt. A lottery concentrates value into a few events that cannot be rerun.

Tickets are sold until a published cutoff. After that, the set of tickets is meant to be frozen. A draw then produces a result once, and the result decides a winner list and a prize pool. Winners are then paid or credited, often through the same wallet and withdrawal machinery as the rest of the platform.

That structure changes what a tester should look for. The most serious problems are not "can I place a bet faster" but "can the frozen set be changed", "can a result or winner list be altered" and "can a prize be paid to the wrong account". Those are integrity questions about workflow state, and they live in admin tools, batch jobs and databases that a purely external scan never reaches.

A row of sealed ticket terminals on a dark counter with one lit green indicator, and a locked safe in the background — The cutoff is the line the test is built around: before it the ticket set is open, after it the set must be frozen and every route that could still change it is in scope.

The scope matrix

Use this as a structure to fill in with your own architecture. It contains no thresholds and no external figures, because the right depth depends on your channels, your draw schedule and your licence conditions.

Event	What a tester examines	Typical entry points	Test environment	Out of scope
Account and ticket purchase	Authentication, session handling, purchase and basket logic, per-account limits	Website, mobile app, retailer terminals, partner API	Staging, plus read-only production checks	Real money purchases
Subscriptions and auto-play	Whether recurring purchases can be created, altered or replayed for another account	Account settings, subscription API	Staging	Production recurring charges
Sales close and ticket freeze	Whether any route can add, alter or cancel a ticket after the cutoff	Admin tools, batch jobs, database access, retailer sync	Staging with test tickets	Altering real tickets
Draw execution	Who can start, pause, repeat or annul a draw; access to the draw workflow and its logs	Back-office tools, orchestration scheduler	Staging, with walkthrough for sensitive steps	Random number generation, draw certification
Result publication	How the result reaches the site, apps and partners; whether it can be changed in transit or after release	Results pipeline, content delivery, partner feeds	Staging	Manipulating a live result
Winner calculation and payout	Matching logic, prize tiers, who can edit a winner list, how payouts are authorised	Prize engine, wallet and payment workflow	Staging with test wallets	Real prize payments
Support and back office	Privilege boundaries, impersonation, bulk export of customer data	Admin portal, support tooling	Staging	Real customer data

Sales close: the freeze is the control

The first thing to establish is how "frozen" is implemented. Sometimes it is a database state change, sometimes a time comparison in application code, sometimes a copy of the ticket set made at the cutoff. Each has a different weakness.

If freeze is a flag, ask who and what can write to the ticket table after it is set. If it is a time comparison, ask whether the clock the code trusts can be influenced, and whether retailer terminals that work offline can submit late. If it is a snapshot, ask where the snapshot lives and who can replace it.

A tester should try each route that could still touch tickets after the cutoff, using test tickets in staging, and record what actually stopped the change. A good result is not just "the request failed" but "the request failed for a reason that is enforced server-side and logged".

The draw is a workflow, not only a number

Random number generation and draw certification belong to specialists and to the licensing process, and a penetration test does not replace them. What a test can examine is everything around the draw.

Who has the permission to start a draw, to pause it, to repeat it or to declare it void? Are those permissions separated from the people who manage tickets and prizes? Are the draw's inputs and outputs logged in a way the person acting cannot edit? Is the process scheduled by a service account with broad rights that anyone with access to the scheduler could abuse?

Because a draw may be run once per cycle, the sensible method is to exercise the workflow against a staging draw with test data and review the sensitive steps by walkthrough with your own staff. Where the test would otherwise require touching a live draw, do not do it.

Results and winners travel through more systems than you expect

After a draw, the result is published to the website, apps, retailer systems and sometimes partners or aggregators. That path is a set of copies, caches and feeds. The test should ask where the authoritative result is stored, how each consumer receives it, and whether any hop accepts an unauthenticated or unsigned update.

The winner list is the more sensitive artefact. It is derived from the frozen tickets and the result, and it feeds the payout. Look at how it is computed, who can edit it, whether edits are logged and whether a second person must approve a change before payment. A test that can change a winner list in staging has found something worth fixing first.

Payouts reuse your wallet, so test the handover

Most lottery platforms credit winnings to a wallet and let the player withdraw. That means the payout path inherits the weaknesses of the cashier: limits, approval rules, account verification and withdrawal destination changes. The lottery-specific question is how a prize amount reaches the wallet: through an internal API, a batch file or a manual adjustment.

Manual adjustments are a classic weak point because they are rare, powerful and often lightly controlled. List who can post one, what evidence it requires and whether it is reviewed. Large prizes that need manual verification before release deserve their own review, because they carry both fraud and social-engineering risk.

Retailers, agents and partner channels

Many lotteries sell through third parties. Each retailer terminal, agent portal or partner API is an additional way to create tickets and reach accounts, usually with its own credentials and a lower level of control than your own site.

Ask how each channel authenticates, what it is allowed to do, how a compromised credential is revoked and whether its tickets reach you in real time or in a batch. A delayed batch can be a late-submission route if the cutoff is enforced only by the channel. In scope, list the channels you own and the partner interfaces you can test with the partner's written permission. Do not test a partner's systems without it.

Rules of engagement for the sensitive steps

The agreement should say, in writing, which environments are used for which events, which paths may be exercised and which are reviewed by walkthrough only. It should name a contact who can stop the test, set times that avoid sales peaks and draw windows, and require that test tickets and test wallets are clearly labelled so they cannot be paid out. Any cleanup of test data should be listed as a deliverable.

What a good report contains

For each event in the matrix, the report should say what was tested, what was not and why, with reproducible steps and the evidence that proves each finding. It should rank findings by whether they affect the integrity of a draw, a winner list or a payout before ranking by technical severity alone, because a modest technical flaw in the freeze or the winner list may matter more than a higher-rated one on a marketing page. It should also give a retest plan for fixes to the highest-impact paths.

Limitations

This article is not legal or regulatory advice and does not state what any licensing authority requires of a lottery operator; check your licence terms and local rules. It does not cover random number generation, draw certification or game fairness, which are assessed separately. It uses no external statistics or incident case studies. The matrix is a starting point and has to be adjusted to your channels, schedule and architecture, and a staging environment that differs from production will limit what the test can prove.

Decision and next step

If you can say, for each of the three events, which routes could change the ticket set, the result or the winner list, and which of those you will test in staging versus review by walkthrough, you are ready to request quotes. If not, the matrix above is the first deliverable. Submit your pentest scope with AnySec and we will turn your channels and draw calendar into a scoped, fixed-price test plan.

Sources and review

Testing method follows public references: the OWASP Web Security Testing Guide and NIST SP 800-115, Technical Guide to Information Security Testing and Assessment, read 2026-11-08; check the current versions. AnySec prepared the lottery-specific matrix from the public structure of lottery operations; no AnySec-original statistics are used. Author: AnySec Engineering. Published 2026-11-08; reviewed by the AnySec security team.

Frequently asked questions

How is penetration testing an online lottery different from testing a casino?: A casino is mostly continuous play: many small bets settled immediately. A lottery is built around three discrete events: ticket sales that close at a fixed time, a draw that produces a result once, and a prize payout that follows. The test should follow those events, with special attention to what can be changed after sales close and who can alter a result or a winner list.
Does a penetration test certify the draw or the random number generator?: No. Draw integrity and random number generation are assessed under separate laboratory or regulator-defined processes. A penetration test looks at whether an attacker, or an insider with a normal account, could reach the systems around the draw: the admin tools, the results pipeline, the ticket database and the payout workflow. State that exclusion in the scope.
What is the most sensitive moment to test around?: The window between ticket sales closing and the result being published. Anything that could add, alter or cancel a ticket, or change a result or a winner list, after the cutoff is the highest-impact finding class. Agree in advance which of those paths may be exercised with test data and which must be reviewed by walkthrough only.
Should the test run against production or a staging copy?: Use a staging environment for anything that touches a draw, a result or a payout, and populate it with test tickets and test accounts. Production testing, if any, should be limited to read-only checks of the public site and login, with written rules of engagement and no live draw or payout in flight.
Which ticket sales channels should be in scope?: Every channel that can create a ticket or touch an account: the website, the mobile app, any retailer or agent terminals, subscription or auto-play services and any partner API. Each is a separate entry point with its own authentication, so list them individually rather than testing only the main site.