Passwordless in Practice: How Phishing-Resistant Authentication Works for Regulated Gaming

5 min read
May 28, 2026
Neon Shield underneath Passwordless in Practice text

 

In the summer of 2022, one cyberattacker ran the same SMS phishing campaign against both Twilio and Cloudflare. The text messages were nearly identical: fake IT department alerts, urgent language, links to convincing login pages. Employees at both companies clicked on the bad links and entered their credentials, but only one of the companies was breached.

Twilio, whose platform powers communications for tens of thousands of businesses, disclosed the breach on Aug. 7. Customer data from 125 client accounts had been accessed; the downstream damage hit Signal, Okta, and other tech companies. Cloudflare had faced the same campaign in July, six weeks earlier, and confirmed no systems were compromised, because its employees authenticate with FIDO2 hardware keys cryptographically bound to the legitimate domain. The phishing proxy couldn't complete the handshake, so the stolen credentials were useless. Three employees got fooled, but it didn't matter.

That gap—same human error, two entirely different outcomes—is the clearest possible argument for phishing-resistant authentication. In regulated gaming, where accounts hold real funds and operators sit at the intersection of gaming and banking compliance, the case for building that same architecture is overdue.

Gaming Accounts Are Financial Accounts

Bad actors don't send phishing campaigns into the gaming space the way they carpet-bomb traditional banking because they don't have to. The gaming space’s attack surface is smaller and more defined: They need to know someone has an account, which property or platform they use, and how they get in. That specificity makes the threat more deliberate, not less dangerous.

In digital gaming, exposure is concentrated at login. Sports betting accounts, iGaming sessions, and loyalty portals are all gated by credentials that can be compromised if someone is tricked into providing them or if those credentials live somewhere they can be lifted. On the physical casino floor, the risk shifts to the moment a player enters a PIN or authenticates at a machine, often in a crowded environment. The social engineering playbook that worked on a Twilio help desk employee works just as well on a player who gets a convincing text telling them their account is about to be locked.

A gaming account should be protected and valued by the consumer in the same manner as a bank account. It holds funds, moves money, and deserves the same skepticism a consumer would apply to a message from their bank asking them to confirm their PIN. Security training can teach someone to recognize a phishing attempt, but it can’t guarantee they’ll catch it at 11 p.m. after a long day, when the message looks exactly right. The architecture has to close the gap that human judgment leaves open.

What Hardware-Bound Authentication Does

The difference between Twilio and Cloudflare wasn’t the attack but what happened after credentials were entered. Twilio's second factor relied on time-based one-time passwords—codes that an employee reads and types—which means the codes can be intercepted in real time and reused by an attacker before they expire.

Cloudflare's second factor was a FIDO2 hardware key, which performs a cryptographic challenge–response authentication bound to the specific domain of the legitimate site. A phishing proxy sitting in a different domain—no matter how convincing it looks—fails at the cryptographic level.

Passkeys work the same way. A player authenticates, their device generates a unique response that the server verifies. Nothing is transmitted that could be intercepted or stolen, so there is nothing for a phishing attack to capture. In gaming, several states have mandated additional verification measures, including New Jersey and Pennsylvania.

At Sightline, that logic extends into our platform architecture. Every transaction requires the use of valid credentials and a single-use authorization token. Requiring an authorization token adds a layer of security to system-to-system processing, similar to the use of multifactor authentication for consumer requests. Every requests that reaches our system carry four layers of credentials to identify the originating touchpoint and request the authorization token; for example, a slot machine at a specific property looks distinct from a mobile app request. If a touchpoint isn't configured and recognized for a specific request type, Sightline doesn’t issue a token. The transaction stops before it starts, not because a person reviewed it but because the system has no record that this combination should exist.

Two Regulatory Frameworks, One Compliance Strategy

Regulated gaming operates under considerable compliance obligations. When payments enters the picture, banking regulation, KYC standards, enhanced AML monitoring, and transaction reporting come with them.

At Sightline, we monitor and perform transaction oversight on behalf of our operator partners for all Sightline solutions, and much of that work runs on automation: fraud rules, behavioral triggers, and anomaly detection that flags unusual patterns before they require human escalation. The goal is to meet or exceed every regulatory requirement without creating more work for the operator.

The relationship with operators is bidirectional. They see one side of a transaction, and we see the other. Neither view is complete on its own. That ongoing exchange is how controls improve over time, how automated triggers get calibrated, and how both parties stay ahead of emerging behaviors rather than reacting to them.

The friction in this transition, when it exists, tends to live in one place: internal training. Getting every part of an organization—not just the IT team—to understand how the program works and what it requires of them is the real implementation work. Once that's done, the day-to-day is largely automated.

The Responsible-Gaming Angle Few People Talk About

When Sightline launched its first cashless gaming programs, the same question came up in nearly every conversation: "Aren't you making it easier for people to spend more than they should?" It seemed like a reasonable concern. Faster access to funds, less friction at the point of play—the assumption was that the program would accelerate problematic behavior.

However, the data showed that because cashless gaming requires authentication at every touchpoint, players are never anonymous. Every deposit and withdrawal is visible to operators and Sightline, and the consumer through their own account history. Funding limits are built in at the sponsor bank level. We can lower them further at a consumer's request. And when spending patterns shift—a player who typically spends $500 a week tapping significantly more—the change shows up in account data, where it can be reviewed and proactively addressed.

Cash doesn't create that record. A player who walks onto a casino floor with cash and heads directly to a machine may go unnoticed. If that person is on a self-exclusion list, there's no automatic check. With gaming accounts, authentication happens before any transaction can take place. A restricted player can't authenticate, and without authentication there's no transaction. The control runs at the point of entry, not after the fact.

Responsible-gaming advocates have taken notice. Account-based, authenticated interactions are among the most effective tools for protecting consumers who need it.

Why This Is a Product Decision

Operators reading this and thinking they should probably look at passwordless authentication are right, but the framing matters. Instead of looking at it like an IT upgrade, consider it a decision about what kind of experience a player has across every touchpoint—the casino floor, the mobile app, the kiosk—and whether that experience holds together or creates friction that erodes trust.

Security and player experience are often treated as competing priorities. In this case, they aren't. A player who authenticates once on their device and moves through the property without reentering passwords or worrying about someone watching over their shoulder has a better experience. The operator has a more defensible security posture, and the regulator has a cleaner audit trail. Those outcomes stem from the same architecture.

The Twilio breach happened because attackers found the human in the loop and worked it. Cloudflare had the same humans, got the same text messages, and walked away clean—because they'd already built authentication to prevent that vector. In regulated gaming, where the accounts in play are treated as financial accounts, that's the standard worth building toward.