What does an external vulnerability assessment actually scan?

Everything internet-facing and nothing behind a login: the platform's external IP ranges and subdomains, open ports and the services listening on them, TLS/certificate configuration, the crawlable web application surface (including affiliate and back-office panels that get forgotten because they're not player-facing), software and framework versions matched against known vulnerabilities, and DNS hygiene. Every automated hit gets manually verified before it reaches the report.

What can't an external vulnerability assessment prove?

Anything that only exists behind authentication or inside the network it wasn't given access to. It can't prove whether a stolen session survives to a funded withdrawal, whether a bonus flow can be replayed, whether an employee with legitimate access can be abused, or whether an attacker who gets past the perimeter can move laterally — because by design it was never handed a valid account or a foothold inside the network to test any of that from.

Does an external VA satisfy the PCI DSS quarterly external-scan requirement?

PCI DSS Requirement 11.3.2 specifically requires that quarterly external scan to be run by a PCI SSC-listed Approved Scanning Vendor (ASV) using their certified methodology. AnySec is not an ASV, and a standard external vulnerability assessment is not a substitute for that specific attestation. It covers the same technical ground and is a reasonable baseline between ASV cycles, but if the deliverable has to be an official ASV scan report, that has to come from a vendor on PCI SSC's list.

Is an external-only scope enough, or do I need internal surfaces included too?

External-only is a reasonable starting point if you have no internal-facing scan coverage today and want fast, cheap visibility into what an anonymous internet attacker sees first. It is not sufficient on its own for an operator with any internal-facing infrastructure — back-office tools, internal BI/analytics dashboards, VPN concentrators — because those assets carry real risk and an external-only scope structurally never reaches them. Our own VA engagements default to external plus internal for exactly this reason.

What happens after the external scan finds something?

Every automated finding is manually re-verified before it's reported, so what you get is a prioritized, de-duplicated list ranked by real exposure rather than raw CVSS — not scanner noise. If a finding looks like it could chain into something deeper than the scan's method can confirm — an exposed admin panel, a login form worth testing for logic flaws — that's flagged as a candidate for a follow-up penetration test rather than guessed at.

Scoping an external vulnerability assessment for a casino

The short answer

An external vulnerability assessment for an online casino scans everything reachable from the public internet without a login: IP ranges and subdomains, open ports and services, TLS configuration, the crawlable web surface, and software versions checked against known vulnerabilities — all manually verified before anything reaches the report. What it structurally can't prove is anything that requires a valid account or a foothold inside the network: business-logic abuse, lateral movement, or whether an attacker who gets past the perimeter can reach anything that matters. It answers "what does the internet see," not "what can an attacker do with it."

Who this decision is for

This is written for the person scoping a Vulnerability Assessment for a casino, sportsbook, or exchange platform who has to define what "external" actually covers before the engagement starts. That's usually one of three moments: a PCI DSS obligation just landed on your desk and the quarterly external-scan requirement is due, a payment processor or licensing regulator asked for evidence of external exposure testing, or you're standing up recurring scan coverage for the first time and need to decide how wide to open the scope.

It's not for you if you've already decided between a vulnerability assessment and a penetration test — that decision, and the breadth-vs-depth reasoning behind it, is covered in vulnerability assessment vs penetration testing for iGaming. This post assumes VA is the chosen engagement and answers the next question: what does "external" mean inside it, and where does its evidence run out.

What "external" means as a scope boundary

"External" is a statement about vantage point, not thoroughness. An external-scoped assessment is run from outside your network, against only what's reachable from the public internet, with no VPN access, no internal network position, and — critically — no authenticated account unless one is explicitly issued for the engagement. Everything the assessment finds, it finds the same way an anonymous internet visitor would.

That vantage point matters because a casino's real attack surface usually spans more than the player-facing site:

The primary platform (web + API).
Affiliate portals and back-office / admin panels that were stood up without security's sign-off and are easy to forget because nobody logs into them daily.
Payment and wallet API endpoints.
Internal BI, analytics, and reporting tools that are sometimes exposed to the internet by accident — the same category of gap CVE-2026-72898 in Metabase illustrates.

An external scope by default covers everything internet-reachable in that list. Internal-only assets — the corporate LAN, VPN-gated admin tooling, anything requiring a network position you don't have from outside — are out of scope unless the engagement is explicitly widened to external-plus-internal.

What actually gets scanned

A properly run external VA is not "point a scanner at the domain and email the PDF." The technical checklist we run against a casino perimeter:

Check	What it establishes
ASN and subdomain enumeration	The full internet-facing footprint, including forgotten affiliate/staging subdomains
Port and service discovery	Every listening service on every discovered host, not just port 443
TLS / certificate configuration	Protocol versions, cipher suites, certificate validity and chain — relevant to both security and payment-processor requirements
Web application surface crawl	Every reachable endpoint, form, and panel, including back-office and affiliate portals that aren't linked from the main site
Software and framework version fingerprinting	Matching detected versions against known CVEs before they reach a KEV listing
DNS hygiene	SPF/DKIM/DMARC gaps, stale records, subdomain-takeover risk
Manual triage of every automated hit	Removing false positives and confirming each real finding by hand — the step that separates a usable report from scanner noise

Every row runs at the reconnaissance layer only — nothing in that list requires or attempts to use a valid session, account, or credential. That constraint is what defines the "external" scope, and it's also exactly where its evidence stops.

What it can't prove

By design, an external-only, unauthenticated scan never has a login. That single constraint sets the honest boundary of what it can establish:

It can't test anything behind authentication. No account was issued, so business-logic flaws in the cashier, bonus engine, or withdrawal flow — the kind that actually drive iGaming losses — are structurally invisible to it, not because the tooling missed them but because it was never given the access to look.
It can't prove lateral movement or blast radius. If a perimeter finding were exploited, what an attacker could reach next inside the network is outside an external scan's vantage point entirely.
It can't confirm exploitability end-to-end. Manual verification confirms a finding is real and not a false positive; it doesn't chain that finding into a proven path to a business impact the way a goal-driven penetration test does.
It doesn't cover internal-facing assets — back-office tooling, internal analytics, anything not reachable from the open internet — unless the scope is explicitly widened.

None of this makes an external VA less useful — it makes it a specific instrument with a specific, honest boundary. Treating a clean external scan as proof the platform can't be breached is the same "box now ticked" mistake we've written about before, just one layer earlier in the funnel.

PCI DSS and the ASV boundary

If the trigger for this engagement is compliance rather than general visibility, one distinction matters more than any other: PCI DSS Requirement 11.3.2 requires the quarterly external vulnerability scan to be performed specifically by a PCI SSC-listed Approved Scanning Vendor (ASV), using that vendor's certified scanning methodology.

AnySec is not a PCI SSC-listed ASV, and a standard external Vulnerability Assessment — ours or anyone's outside that list — is not a substitute for the official ASV attestation your acquirer or QSA requires for that specific requirement. Where a scoped external VA earns its keep is everything around that quarterly checkbox: a deeper, manually-verified pass between ASV cycles, coverage of assets an ASV scan's narrower scope may not touch, and a baseline you can run on your own cadence rather than waiting for the compliance calendar.

What you get back

A Vulnerability Assessment engagement runs 3–5 business days per cycle, with a quarterly or monthly recurring option, and produces:

A prioritized, de-duplicated list of real findings ranked by actual exposure — not raw CVSS, and with the false positives already removed.
Concrete remediation guidance per finding.
An audit-ready summary formatted for a regulator, payment partner, or internal audit trail.

If a finding during scoping or scanning looks like it needs deeper, authenticated, goal-driven testing to confirm real business impact — an exposed admin login, a payment endpoint worth walking end-to-end — that's the point where the recommendation shifts from "keep scanning" to "scope a pentest," per the breadth-vs-depth framing here.

How to decide your scope

Start external-only if you have no scan coverage today and need fast, low-cost visibility into what an anonymous attacker sees first, or if a specific external-facing compliance deadline is the immediate trigger.
Widen to external-plus-internal the moment you have any internal-facing infrastructure worth protecting — back-office tools, internal analytics, VPN-gated admin panels. External-only structurally can't reach any of it, and that's usually where the real exposure sits once the obvious perimeter gaps are closed.
Escalate to a penetration test for the specific high-value flows — cashier, wallet, auth — where the question isn't "is this exposed" but "can it actually be broken into," per the full scope breakdown for casino pentests.

If you're not sure where your obligation or your risk actually sits, that's the first thing we work through — tell us your platform and what's driving the request and we'll scope it plainly, including when external-only is genuinely enough.

Sources and review

External-scan methodology reflects AnySec's own VA engagement approach and NIST SP 800-115's assessment-technique guidance. The PCI DSS ASV requirement is described per the PCI Security Standards Council's own Approved Scanning Vendor program page. Author: AnySec Engineering. Published 2026-08-18.