The attackers aren’t interested in your hotel. They want your Okta tenant, and the front desk is just the softest door into it. That’s the uncomfortable reframe buried in Okta Security’s August 2025 report on a Russia-linked campaign hitting hoteliers and vacation-rental providers: this isn’t spray-and-pray phishing that happened to land on a hospitality inbox. Someone picked the vertical on purpose, bought malvertising to seed credential-harvesting pages, and went after the one credential that unlocks booking systems, guest PII, and the payment rails behind them.
That report is dated, but the technique isn’t. Okta documented this specific campaign as active through August 2025; I can’t tell you the same operators are still at it today, and it doesn’t matter. Adversary-in-the-middle phishing aimed at a chosen vertical is now a permanent fixture of the threat model, not a one-off incident you can wait out. If you run identity for a hotel group, a property-management platform, or a booking aggregator, you have two defensive bets to place. They sound complementary in a slide deck. In the field they compete for the same scarce thing — your attention and your change window — so let’s judge them head to head: phishing-resistant authentication (FIDO2/WebAuthn and Okta FastPass with device trust) versus detection and risk-based policy (Okta ThreatInsight, Behavior Detection, System Log hunting, and if you pay for it, Identity Threat Protection).
Round 1: Does it actually stop the credential theft?
This is the whole game, so start here. The campaign works because a human types a password and an OTP into a page that looks like their Okta sign-in and isn’t. Push notifications, TOTP, SMS — every shared-secret or approve-this-prompt factor is harvestable by an adversary-in-the-middle proxy. The attacker relays your code in real time and you never know.
FIDO2/WebAuthn breaks that chain at the protocol level. The authenticator signs a challenge bound to the real origin (https://yourtenant.okta.com), so a credential presented to yourtenant-okta[.]login-verify[.]com simply doesn’t produce anything the attacker can replay. There’s no secret to phish. Okta FastPass extends the same guarantee to the Okta Verify app when device binding is enforced: the origin check is part of the ceremony, so it refuses to authenticate against a spoofed sign-in page. When that happens, the attempt surfaces in the System Log as a failed FastPass authentication rather than a success — in effect, a passkey telling you that someone just tried this exact attack and the origin binding stopped it. That failure signal is worth alerting on.
Detection doesn’t prevent anything. It tells you after the password is already gone. ThreatInsight can block a sign-in from an IP it already knows is malicious, and Behavior Detection can flag a new country or a new device — but the credential was still harvested on the fake page, and a patient operator rotates infrastructure and logs in from a residential proxy in your own city.
Phishing-resistant auth wins, decisively. Prevention 1–0.
Round 2: How fast can you deploy it against a live threat?
Here the scoreboard flips, and this is the round architects underweight. The attack pattern isn’t going anywhere, and you don’t get to pick when the next operator points it at your vertical. ThreatInsight is a toggle. You can turn it to enforce before your next coffee:
Behavior Detection is similarly fast — define the behaviors, then reference them in an authentication policy to step up or deny. And you can start hunting the System Log for this campaign’s shape immediately, no project plan required:
Rolling out FIDO2 to a hospitality workforce is not a toggle. It’s authenticator enrollment, hardware keys or platform passkeys for people who’ve never heard the word, a help desk that will absolutely get the “I left my YubiKey at home” call during check-in rush, and franchise owners who don’t report to you. Realistically that’s weeks to months, not an afternoon.
Detection wins this round on pure time-to-mitigate. 1–1.
Round 3: The hospitality long tail
Every vertical has an awkward shape, and hospitality’s is brutal for passkeys. Shared front-desk terminals logged in by whoever’s on shift. Seasonal staff who onboard in April and vanish in October. Franchisees running their own IT with a service-desk admin account that hasn’t been touched since setup. Contractors on the property-management platform. These are exactly the accounts the campaign wants, and they’re the hardest to put a security key in front of.
FIDO2 is the right answer for the accounts you can reach — and you should ruthlessly prioritize the ones that matter: super admins, app admins, anyone with API tokens, anyone who can touch the booking or payment integration. Scope a dedicated authentication policy and require the phishing-resistant factor only there first:
That deny-if-can’t-satisfy line matters. A phishing-resistant policy with a password-plus-OTP fallback is not phishing-resistant; it’s a speed bump the attacker drives around by claiming their key is unavailable. If you leave the fallback, you’ve done the work and kept the hole.
For the long tail you genuinely cannot enrol this quarter, detection and risk-based policy is the net. Behavior Detection plus a step-up on new-device/new-country is a real control for the shared terminal and the dormant franchise admin. It’s not as good. It’s what you have.
Split round. FIDO2 for the crown jewels, detection for the accounts it can’t reach yet. 2–2.
Round 4: What happens when the attacker adapts?
Assume they get a session. Adversary-in-the-middle kits don’t just steal passwords; they steal the session token after a successful MFA, then replay it. A static sign-in-time check — even a strong one — doesn’t see the stolen cookie being used from somewhere else an hour later.
This is where the two bets start to need each other. Device trust (via Okta FastPass and a managed-device signal from Intune, Jamf, or the equivalent) binds the session to hardware, so a replayed token from an unmanaged machine fails a device-posture check it can’t forge. And Okta Identity Threat Protection — be honest about this — is a separate paid add-on, not something in your base Workforce Identity tenant, and it’s the piece that does continuous evaluation: it can kill a live session mid-flight when risk changes, instead of only judging at the front door. If you have the license, this is the round it earns its line item. If you don’t, device-bound FastPass plus aggressive System Log alerting on user.session.start from new ASNs is the poor-architect’s version.
Prevention edges it, because a bound session beats a watched one — but only with device trust layered on. 3–2 to phishing-resistant auth.
The verdict
Phishing-resistant authentication wins the war; detection wins the week. Those aren’t in tension once you sequence them correctly.
Today — before you close this tab — turn ThreatInsight to block, switch on Behavior Detection, and stand up System Log alerts for the queries above. That’s your tourniquet against a threat that doesn’t need a specific campaign to be live, and it costs you a change window, not a project. This week, scope a deny-no-fallback phishing-resistant policy for admins and the apps touching bookings, PII, and payments, and start the FIDO2 enrolment there. That’s the cure, and it’s the only control on this list the attacker can’t phish around.
The one case where I’d pick the loser outright: accounts you genuinely cannot get onto FIDO2 this quarter — the shared front-desk terminal, the seasonal cohort, the franchise admin you don’t control. For those, detection and risk-based step-up is not a compromise you apologise for. It’s the correct answer for an account you can’t fix yet, and the alternative is nothing.
Okta didn’t publish a tidy IOC list you can paste into a block rule, so don’t wait for one. The infrastructure rotated out of relevance within weeks of that August 2025 report; the next operator’s will too. What doesn’t rotate is the shape of the attack: a human, a convincing fake page, and a credential that should never have been phishable in the first place. Fix the credential. The malvertising becomes someone else’s problem.