How is a poker vulnerability assessment different from a casino one?

A casino estate is dominated by the player web app, cashier and game-provider integrations. A poker room adds long-lived game servers with shared table state, client binaries players install, tournament administration and hand-history data paths. Those assets need to be on the inventory before any scanner runs, otherwise the assessment covers the marketing site and misses the game.

Can a vulnerability scan be run against live poker tables?

Only with an agreed window and rate limits. Aggressive scanning against game-connection endpoints can disconnect players or disturb a running tournament. Agree scan windows around the tournament schedule, start with low-intensity, non-authenticated checks, and name a game-operations contact who can stop the scan.

Does a vulnerability assessment check the poker RNG or detect collusion?

No. A vulnerability assessment looks for known weaknesses and misconfigurations in exposed assets. Shuffle and random-number-generator certification, and collusion or bot detection, are separate disciplines handled by accredited test labs and game-integrity teams.

How often should an online poker room be assessed?

Tie the cadence to change. Reassess when a new client version, tournament feature, payment route or partner connection ships, and on a regular schedule between releases. The right interval depends on how fast your release cycle moves; our cadence logic for casinos in the linked frequency article applies by analogy.

Vulnerability Assessment for an Online Poker Room: Scope

The short answer

A vulnerability assessment of an online poker room should start from an asset inventory, not a scanner: player clients and their download paths, lobby and game-connection endpoints, tournament and back-office admin panels, hand-history and export services, cashier callbacks, and partner or network links. Each asset gets an owner and a scan window that respects the tournament schedule. Findings are then ranked by what the asset can do to a table or a payout, not by score alone.

Who this is for

This is for a CTO, head of security or operations lead at a poker operator, or at a casino or sportsbook that runs a poker product, who is about to buy or commission a vulnerability assessment and needs to know what belongs in scope. If you run a general casino estate, the model in Scoping an external vulnerability assessment for a casino is the base; this piece covers only what a poker room adds. If you already have a scoping answer for the attacker's view, penetration testing an online poker room is the companion.

Why the casino scope misses the game

Most iGaming vulnerability scopes begin with a list of domains. For a casino that is nearly enough: the player site, the cashier, the admin portal and the integrations hang off a few hostnames. A poker room has the same hostnames, plus a layer that a domain list does not describe. There are long-lived server processes holding shared table state. There are client applications that players install and that talk to those servers over their own connection layer. There are administrative tools that run tournaments. There are exports that hand operators and sometimes players the record of what happened at a table.

A scan of the marketing site and the login page will return tidy results and say almost nothing about that layer. The risk is not that scanners cannot test it; it is that nobody put it on the list. Before choosing a tool or a window, write down what exists. That is the first deliverable of a good assessment and the one most often skipped.

A back-room wall of identical key hooks, most holding dark keys, with one lime-green key hanging on a single hook above a closed ledger — An inventory is a board where every hook has a key and a name. The hook nobody wrote down is the asset nobody assessed.

The asset-and-owner inventory

Use this as the working list when you prepare for scoping. Each row names the asset class, what makes it distinctive for poker, who should own it and the scan posture to agree in advance. Treat the posture column as a starting position to negotiate, not a rule.

Asset class	What is distinctive for poker	Owner to name	Scan posture to agree
Player web and download pages	Client installers and update endpoints are a supply path into players' machines	Web or release engineering	Normal external checks; verify signing and update delivery separately
Lobby and login APIs	Session creation, table listing, registration and password flows	Platform engineering	Rate-limited, outside peak tournament starts
Game-connection endpoints	Persistent connections to servers holding live table state	Game-server team	Low-intensity, non-authenticated first; named contact able to stop the scan
Tournament and back-office admin	Pause, void, re-seat and payout tools used by operators	Game operations	Authenticated checks on a staging copy where possible
Hand-history and export services	Data paths carrying hidden-information records and player behaviour	Data or platform owner	Check access control and exposure, not bulk retrieval
Cashier and payment callbacks	Buy-in, rebuy and payout hooks tied to tournament state	Payments or finance engineering	External checks only; coordinate with the payment provider
CDN, DNS and edge	Where traffic is filtered and where the origin can leak	Infrastructure	Standard external checks; confirm origin is not directly reachable
White-label and network links	Shared player pools, partner skins, third-party widgets	Partnerships or vendor owner	Scope by agreement with the partner, in writing

Two points deserve emphasis. First, the "owner to name" column is not decoration. A finding on an asset nobody owns sits in a spreadsheet; a finding on an asset with a named owner becomes a ticket. Second, the white-label row is the one most likely to be mis-scoped. If your poker product runs on a network operator's platform, many assets are theirs, and you cannot authorise a scan of them. Read how the same boundary works for sportsbooks in vulnerability assessment of a sportsbook's feeds, widgets and white-label.

Scan windows and the tournament calendar

Poker has a rhythm that a casino does not. Large tournaments start at published times, late registration windows are busy, and a disconnection during a hand is a customer-service event with real stakes. An assessment that ignores this calendar can cause the outage it was meant to prevent.

Get the schedule first. Ask game operations for the tournament calendar and the quietest hours by region before scheduling anything.
Split scan intensity by asset. Marketing pages and static download hosts tolerate normal external scanning. Game-connection endpoints need low intensity and a clear abort route.
Name a stopper. One person on the operator side who can halt a scan within minutes, with a reachable phone number during the window.
Test in two passes. A first, light pass to confirm what is reachable; a second, scoped pass on the assets where you have agreed the risk.
Never test payouts live. Cashier and payout flows are examined for exposure and misconfiguration, not exercised with real balances, unless a separate test plan and test accounts are agreed.

This sequencing is also what keeps the assessment honest about its limits: it describes what an outside observer could find at the agreed intensity, and nothing more.

Ranking findings by table impact

Scanners rank by a generic score. A poker operator needs a second lens: what does this weakness let someone do to a table, a tournament or a payout? Use three questions on every finding.

Does it touch game state? A weakness on an endpoint that holds table state, or on the admin tool that controls it, outranks the same class of weakness on a static page.
Does it touch money movement? Anything that reaches buy-in, rebuy or payout callbacks moves up.
Does it expose hidden information? Exposure on hand-history paths or on session identifiers that could reveal another player's cards or behaviour moves up.

A finding that fails none of these can be scheduled with normal patch cycles. A finding that fails any of them goes to the named owner with a short deadline and a retest. The method for turning a long scan result into a short, ordered fix queue is described in vulnerability scan results: from critical list to fix queue; apply the table-impact lens as an extra column.

What a vulnerability assessment does not prove

Be explicit with your own leadership about the boundaries. An assessment finds known weaknesses and misconfigurations in assets that were in scope and reachable. It does not certify the shuffle or the random number generator; that is accredited laboratory work. It does not detect collusion between players or bot play; those belong to game-integrity teams and specialist tooling. It does not exploit weaknesses to prove impact, which is the job of a penetration test. And it does not give you continuous visibility; for that you need monitoring such as a managed SOC fed with the right poker log sources.

Limitations

This article is not legal or regulatory advice and does not state what any licensing authority or testing laboratory requires of a poker operator regarding assessments, scanning or reporting; check your licence terms. It uses no external statistics or incident case studies. The scan postures are negotiating starting points and need adjusting to your architecture, vendor contracts and tournament calendar. Which assets you control depends on whether you self-host or run on a network or white-label platform, and you can only authorise testing of assets you own or have written permission to test.

Decision and next step

If you can list your poker assets with an owner against each one, and you know your quiet hours, you are ready to commission a useful assessment. If you cannot, the inventory and the window plan are the first deliverables and are worth completing before a scanner is pointed anywhere. Request an asset-scope quote and we will turn your inventory into a scoped, scheduled assessment with a ranked fix list.

Sources and review

Scanning and inventory practice follows the public NIST SP 800-115 Technical Guide to Information Security Testing and Assessment and the OWASP Web Security Testing Guide, read 2026-11-03; check the current versions. No AnySec-original statistics are used. Author: AnySec Engineering. Published 2026-11-03; last reviewed 2026-11-03.

Frequently asked questions

What should a vulnerability assessment of an online poker room cover?: Everything reachable from outside that a player, an operator or a partner can touch: the web and desktop or mobile client download paths, the lobby and game-connection endpoints, tournament and back-office admin panels, hand-history and export services, cashier and payment callbacks, the CDN and DNS layer, and any white-label or network partner connections. The unit of scope is the asset and its owner, not the website.
How is a poker vulnerability assessment different from a casino one?: A casino estate is dominated by the player web app, cashier and game-provider integrations. A poker room adds long-lived game servers with shared table state, client binaries players install, tournament administration and hand-history data paths. Those assets need to be on the inventory before any scanner runs, otherwise the assessment covers the marketing site and misses the game.
Can a vulnerability scan be run against live poker tables?: Only with an agreed window and rate limits. Aggressive scanning against game-connection endpoints can disconnect players or disturb a running tournament. Agree scan windows around the tournament schedule, start with low-intensity, non-authenticated checks, and name a game-operations contact who can stop the scan.
Does a vulnerability assessment check the poker RNG or detect collusion?: No. A vulnerability assessment looks for known weaknesses and misconfigurations in exposed assets. Shuffle and random-number-generator certification, and collusion or bot detection, are separate disciplines handled by accredited test labs and game-integrity teams.
How often should an online poker room be assessed?: Tie the cadence to change. Reassess when a new client version, tournament feature, payment route or partner connection ships, and on a regular schedule between releases. The right interval depends on how fast your release cycle moves; our cadence logic for casinos in the linked frequency article applies by analogy.