Skip to content

Deepfakes in iGaming. Why a selfie alone cannot protect an account

Checking a document and a face is only the beginning. We examine how deepfakes are changing iGaming account protection, why the whole process matters and…

Deepfakes in iGaming. Why a selfie alone cannot protect an account
AT A GLANCE

Key information

  • Deepfakes and stolen data undermine trust in the appearance of a document or recording alone.
  • Identity proofing must be distinguished from protecting subsequent sign-in and account recovery.
  • Transparent verification rules and limiting data collection are part of service quality.

A photo of an identity document, a short video of your face, a few seconds of waiting and a message: “Identity confirmed”. From the user’s perspective, this is a small part of registration. From the operator’s perspective, it determines who will be associated with an account, its activity history and access to money. As generative AI develops, a convincing image becomes harder to treat as sufficient evidence on its own.

This does not mean that every biometric check is ineffective or that every additional question from an operator indicates a problem. It means that protection must be assessed more broadly: from checking the document and the origin of the recording to securing sign-in and account recovery. In iGaming, this chain connects technical security, money, the protection of minors and privacy.

Why the problem goes beyond a fake face

In its ENISA Threat Landscape 2026 report, published in September, the European cybersecurity agency describes threats observed in 2025. It highlights, among other things, the use of generative AI and deepfake videos to impersonate trusted people in social engineering. This is a broader picture of cybercrime, not a measurement of fraud at online casinos. The report cannot legitimately be used to calculate what proportion of iGaming accounts are opened using fake recordings. [1]

That distinction matters. Public discussions of security can easily become a race to quote alarming percentages. For an individual platform, the more important question is which event it is trying to detect: impersonation during registration, takeover of a real account or manipulation of a support employee. Each situation requires a different set of controls.

Europol’s IOCTA 2025 report describes data as a commodity in the cybercriminal marketplace: both a target of attacks and a resource used to commit further crimes. Access to data in one place can therefore increase risk elsewhere. [2] The practical lesson for iGaming is that an operator should not assume that a complete set of correct personal details automatically proves that their real owner is present.

What verification actually confirms

NIST’s digital identity guidelines distinguish identity proofing from subsequent authentication, which confirms the right to access an account. A document can be genuine while the person presenting it is not its owner. Likewise, successful registration does not guarantee that the next session will belong to the same person. [3]

Users can translate this into three questions. Were the details and document checked? Did the platform link them to the person completing verification? Does the account remain protected after the process ends? When a service answers only the first question, the label “verified” says less than it appears to.

Consider a hypothetical customer who completes registration correctly but later gives away access to their email on a website impersonating support. The initial document check may have worked properly. The failure occurred elsewhere: in account protection and changes to account details. Asking for an identical photograph again may not resolve the situation.

Facial similarity alone does not settle the matter

In SP 800-63A-4, NIST discusses manipulated media and attacks that inject images into remote identity proofing. It notes that biometric comparison alone does not prevent these attempts. Checks for the presence of the document and the person make abuse harder, but do not cover every possible case. The origin of images, transmission security and detection of manipulation also remain important. This is a technical reference, not a separate legal requirement applying to every gambling operator in Europe. [3]

The difference is invisible to customers. Two applications may display similar screens and request the same head movement while protecting the overall process differently. A polished interface, fast facial recognition or a green check mark at the end does not demonstrate the quality of the system.

When choosing a verification provider, a useful question is therefore not only “How quickly does it accept customers?” but also “How does it recognise uncertainty, and what does it do with a case it cannot resolve?” In our view, this is one of the most important differences between a sales tool and an identity protection system.

Secure registration is only the beginning

Once an account has been created, protection shifts towards sign-in and actions that change control of the profile. NIST SP 800-63B-4 distinguishes ordinary one-time codes from phishing-resistant methods. Manually entering a code does not bind it to the genuine website in the same way as appropriately implemented cryptographic solutions. The guidelines identify WebAuthn as an example of a mechanism that binds authentication to the verifier’s name. [4]

This is not a promise that a particular sign-in method will solve every problem. A hijacked session, a poorly designed email-change process or a weak recovery procedure can still undermine protection. For users, what matters is not only whether an additional safeguard exists, but whether it covers the most important operations.

OWASP recommends particular care when replacing authentication factors: reauthentication, risk checks and notifications of changes. It also stresses that account recovery should not create an easy way to bypass protection. [5] For an account linked to money, it is hard to justify strong protection at sign-in alongside a substantially weaker route for changing the account’s contact details.

Dwoje analityków omawia niejednoznaczny wynik weryfikacji na ekranie komputera
Human review remains an important part of the process when a result is ambiguous. Editorial illustration.

Verification at withdrawal: an obligation or a poorly planned process?

In Great Britain, the Gambling Commission requires age and identity checks before a customer is allowed to gamble. The regulator also explains that an operator should not make a withdrawal conditional on information it could reasonably have requested earlier. At the same time, legal obligations can justify additional questions later. A repeat check is therefore not automatically improper. [6]

This is an example from a specific market, not a universal instruction for the whole world. The design principle it illustrates is nevertheless important: a company should explain early enough which documents may be needed, in what circumstances and how they should be submitted. [6]

In our view, a transparent process reduces both customer frustration and opportunities for fraud. A user who knows the official verification channel is more likely to notice an unusual request in a messaging app. Support teams receive fewer questions about conflicting instructions. Operators can assess risk earlier instead of trying to clarify everything only when a customer wants to end the relationship and withdraw funds.

More documents do not always mean better protection

Verification creates risks of its own: a company receives data that may be especially valuable if a security breach occurs. The European Data Protection Board lists data minimisation, purpose and storage limitation, and integrity and confidentiality among the core principles. Data should correspond to the actual need for processing it. [7]

In practice, an operator must be able to explain why it collects particular material, who will have access and how long it will be retained. This does not mean every copy can be deleted immediately: separate obligations may arise from market regulation or anti-money-laundering rules. What matters is that the scope of collection follows a justified purpose rather than a reflex to gather everything “just in case”.

From a risk management perspective, a document is both a control tool and an asset that needs protection. Adding another form may improve one stage of the process while increasing the cost and impact of a potential leak. A mature system should be able to explain that trade-off instead of presenting the number of required attachments as a measure of security.

Questions an operator should ask

In our view, discussions with a technology provider should start with scenarios that matter to the platform. How does the system behave when a genuine customer uses an older phone? What happens after an unsuccessful attempt? Can a rejection be explained and referred for further review? How are changes to contact details and account recovery confirmed?

A second area is responsibility. Who makes the decision when a result is ambiguous? Who sees the documents? Will the operator be notified of an outage or a problem at the provider? Can it reconstruct the basis of an important decision without relying solely on a final “accepted” message?

A third area is quality measurement. Registration speed alone says little about resistance to abuse. We propose assessing both sides of the process: effectiveness against attempted fraud and the burden on genuine users. A system that rejects almost everyone may look good in a narrow statistic but cannot serve customers. A system that accepts users very quickly, meanwhile, needs credible evidence that it is not skipping important checks.

What users can do

The most valuable steps reduce risk without requiring users to assess an operator’s algorithms. CISA recommends enabling multifactor authentication, including for email, using strong passwords and keeping software updated. Email deserves particular attention because it is often used to restore access to other services. [8]

Documents should be submitted through the channel identified on the service’s official website. When an unexpected message arrives, it is wiser to open the known website yourself and check the notification in your account than to start by clicking the supplied link. You can verify an additional request with support, particularly when it differs from the procedure described earlier.

Identity verification alone does not establish whether an operator may legally offer a service where a user lives. Likewise, a licence and properly functioning sign-in do not change the financial risks of gambling. These are separate questions and should be assessed separately.

Trust depends on the entire process

Identity verification is a part of iGaming that users would prefer to complete quickly, but operators cannot think about it solely in terms of fast registration. It protects access while also affecting privacy, and it can determine how a customer judges a company’s credibility in a difficult moment.

The development of deepfakes makes this responsibility more important. A good process should recognise the limits of automated decisions, protect subsequent sign-in and provide a clear route for resolving problems. For the industry, this means fewer impressive promises of “complete security thanks to AI” and more questions about specific decisions, data protection and service quality.

This is our editorial conclusion from the sources cited: the value of a system is not demonstrated by a single selfie or a final green check mark. It is demonstrated by how the platform protects the connection between a real person and their account throughout their use of the service.

Sources and verification

An analytical article based on institutional sources and technical documentation. Sources were checked on 11 October 2026. The customer example is hypothetical; assessments of process design are identified as editorial conclusions. Editorial illustrations depict example situations.

  1. ENISA - Threat Landscape 2026
  2. Europol - IOCTA 2025: Steal, deal and repeat
  3. NIST SP 800-63A-4 - Identity Proofing and Enrollment
  4. NIST SP 800-63B-4 - Authentication and Authenticator Management
  5. OWASP - Multifactor Authentication Cheat Sheet
  6. Gambling Commission - Age, ID and financial verification
  7. European Data Protection Board - Basic principles
  8. CISA - Turn On MFA