Cybersecurity for Hospitality Guide: Threats, Regulation and Priority Controls

Hotels and hospitality groups hold payment cards, passport numbers and loyalty balances for millions of guests, yet run them on franchised networks, shared front-desk PCs and outsourced IT that attackers reach with a phone call or a fake booking message. The sector's largest incidents were not exotic: a help desk reset, an unsegmented franchise network, a guest database nobody was watching for four years. This guide covers the hospitality threat picture, the regulation and enforcement that actually bites (PCI DSS, FTC orders, GDPR), and the controls that matter more here than in a typical enterprise. It is written for security leads at hotel groups, management companies, franchisors and independent properties, and for the MSPs that support them. Casinos and integrated resorts have their own regulators and are covered in the sibling Cybersecurity for Casinos and Gaming Guide.

Key takeaways

• Identity is the main entry point. Help desk impersonation, phished front-desk staff and booking platform account takeover feature in more hospitality incidents than technical exploits.
• The franchise model shapes the attack surface. Brand, management company and owner each run part of the estate, so property networks must be treated as untrusted by the brand's central systems.
• Card data scope can be shrunk, and should be. Validated point-to-point encryption and tokenisation remove most of the property from PCI DSS scope; card numbers on reservation notes put it straight back.
• Guest data retention is a liability. Regulators have punished hotel groups for keeping passport numbers and old guest records far longer than any business need.
• Operations stop when identity or hypervisors fall. Reservations, check-in and digital room keys depend on the same identity provider and virtual infrastructure, so recovery planning must cover a manual front desk.

Why hospitality is a distinct risk

CISA places lodging, alongside gaming, inside the Commercial Facilities critical infrastructure sector, with the Department of Homeland Security as its Sector Risk Management Agency. That label understates the cyber exposure. A hotel is a retailer, a landlord, a restaurant, a small data centre and a public Wi-Fi provider at once, open 24 hours a day with high staff turnover and a front desk that must say yes to callers.

• Fragmented ownership: a single branded property can involve the brand (central reservations, loyalty, brand standards), a management company (staff and day-to-day IT) and an owner (capital spend). Each assumes another is responsible for patching the property management system (PMS) or the guest Wi-Fi.
• High-value data in bulk: payment cards, passport or identity document numbers captured at check-in, dates of birth, travel patterns of executives and public figures, and loyalty points that are effectively a currency.
• Shared and kiosk devices: front-desk workstations are shared across shifts, often with generic logons, and connect to the PMS, card terminals and key encoders.
• Dense third parties: PMS and point-of-sale (POS) vendors, channel managers, online travel agencies (OTAs), revenue management SaaS, door lock and building management suppliers, all with remote access.
• Seasonal pressure: attackers time campaigns to peak travel, when staff are busiest and least likely to question an urgent guest message.

Threat picture

The table maps the threats most often seen against hospitality to ATT&CK techniques and the primary control. Technique IDs are from ATT&CK v20.

Microsoft Threat Intelligence described the booking platform pattern in March 2025: a cluster it tracks as Storm-1865 sent emails impersonating Booking.com (negative reviews, guest requests, account verification) to hospitality staff across North America, Europe, Oceania and Asia from December 2024, timed to busy travel periods. The link led to a fake CAPTCHA that told the user to open the Windows Run dialog and paste a command, which used mshta.exe to load credential-stealing malware such as Lumma Stealer, XWorm and NetSupport RAT. The goal was payment fraud and credential theft. The same campaign shape recurs because it works against a role whose job is to respond quickly to guests.

The FBI and CISA joint advisory on Scattered Spider (AA23-320A) lists commercial facilities among the targeted sectors and describes the help desk route in detail: impersonating staff by phone or SMS to have passwords and MFA reset, SIM swapping, MFA fatigue, persuading employees to install remote access tools, and encrypting VMware ESXi servers with ALPHV BlackCat ransomware. See the Scattered Spider Threat Actor Profile.

Regulation and enforcement

There is no hospitality-specific cyber law in the US, UK or EU. The obligations come from card brand rules, consumer protection enforcement and data protection law, and the enforcement record is unusually rich.

The Marriott case is the reference point for the sector. The FTC said three breaches affected more than 344 million customers worldwide; one began in July 2014 inside Starwood's network and was not detected until September 2018, by which time it had reached 339 million guest records including 5.25 million unencrypted passport numbers. The order's emphasis on retention and deletion is a direct response: data that is not held cannot be stolen. See the PCI DSS 4.0 Guide and the GDPR Compliance Guide for Security Teams.

Payment and guest data protection

Most hotel groups can reduce their payment exposure more than they think. The order of preference is: do not touch the card number, then make it unreadable, then protect what is left.

• Free-text fields: run regular discovery scans of PMS comments, email and file shares for card numbers and passport numbers. Free text is where sensitive authentication data and full card numbers end up against requirement 3.3.
• Identity document capture: capture only what the law of the property's country requires, store it in a restricted field rather than a scanned image in a shared folder, and set an automatic deletion period.
• Loyalty accounts: treat points as stored value. Require step-up authentication for redemption, transfer and email or phone changes, and alert on bulk redemptions to new accounts. See the Account Takeover Prevention Guide.
• Encryption at rest: encrypt guest databases and backups with keys held outside the database host; the Starwood passport numbers were stored unencrypted.

See the Tokenisation and Data Masking Guide.

Property networks, Wi-Fi and building systems

A property network carries guest Wi-Fi, conference room AV, card terminals, back-office PCs, door lock encoders, building management, CCTV and in-room devices. The Wyndham order's requirement that franchisee networks be certified as untrusted remains the right model for any brand: central reservations and loyalty systems should accept connections from properties only through authenticated, logged, narrowly scoped interfaces.

• Segmentation: separate VLANs and firewall policy for guest Wi-Fi, payment terminals, corporate PCs, building and lock systems, and IoT. Guest Wi-Fi should have client isolation and no route to any internal subnet. See the Network Segmentation Guide.
• Guest Wi-Fi: WPA3 or a captive portal with per-stay credentials, client isolation, and a separate internet breakout. See the Wi-Fi Security Guide.
• Door locks and in-room IoT: keep lock management servers and encoders on their own segment, change vendor default credentials, and record which supplier accounts can issue master keys. See the IoT Security Guide.
• Front-desk endpoints: EDR, application allowlisting that blocks script hosts such as mshta.exe for standard users, no local admin rights, and named logons with fast user switching rather than a shared "frontdesk" account.

Identity, help desk and third-party access

Identity is where hospitality incidents start and where most of the control value sits. Shift work and turnover create a steady flow of password resets, and outsourced service desks may serve several hotel groups at once.

• Help desk verification: no password or MFA reset on the strength of information an attacker can find (name, employee ID, manager's name). Use a callback to the number on file, a manager approval, or an in-person check at the property. Apply the same script to outsourced help desks by contract. See the Account Recovery and Help Desk Security Guide.
• Phishing-resistant MFA for administrators: FIDO2 security keys or passkeys for identity provider, hypervisor, PMS administration and cloud console roles. AA23-320A recommends FIDO/WebAuthn or PKI-based MFA because it resists push bombing and SIM swaps. See the Phishing-Resistant MFA Guide.
• Identity provider hardening: separate admin accounts, just-in-time elevation, alerts on new admins, new federation trusts and MFA resets. See the Identity Provider and SSO Security Guide.
• Booking platform and extranet accounts: these are shared business accounts at many properties. Enable the platform's two-factor option, give each staff member a named login where the platform allows it, and remove leavers on the same day.
• Vendor remote access: broker PMS, POS and lock vendor access through a single gateway with MFA, session recording and time-bound approval; no always-on vendor VPNs or unmanaged remote tools. See the Third-Party Access Guide and the RMM Tool Security Guide.

Where non-human identities fit

The integrations that run a hotel are machine identities: channel manager API keys that push rates and inventory to OTAs, PMS-to-POS interfaces, payment gateway credentials, revenue management service accounts and SCIM or sync connectors to the identity provider. MGM shut down its Okta sync servers during its 2023 incident, which shows how central these accounts are. Inventory them, give each an owner, rotate keys when staff or vendors change, and store them in a secrets manager rather than in interface configuration files on property servers. See the Third-Party Access Policy Template.

Implementation roadmap

1. Days 0 to 30, find the exposure: inventory properties, ownership model and who runs IT at each; list every vendor with remote access; run card and passport number discovery across PMS notes, email and shares; list all admin accounts on the identity provider and hypervisors.
2. Days 30 to 90, close the front doors: roll out the help desk verification script (pilot at one service desk, then all, including outsourced desks); enforce FIDO2 for admin roles in report-only conditional access first, then enforce with a documented break-glass account; enable two-factor on booking extranets.
3. Months 3 to 6, shrink and segment: move properties to P2PE terminals and tokenised card-on-file; separate guest, payment, corporate and building networks property by property, starting with the highest revenue sites; block unapproved remote access tools with application control in audit mode for two weeks, then enforce.
4. Months 6 to 12, prove recovery: isolate hypervisor management, keep immutable offline backups of PMS and reservation data, and run a tabletop where the identity provider and ESXi are both lost on a Saturday night. Rehearse manual check-in and physical key issuance.
5. Rollback: every enforcement step (conditional access, allowlisting, network ACLs) should have a tested reversal and a named approver, because a front desk that cannot check guests in will be bypassed.

Small versus large: an independent hotel should rely on a hosted PMS, P2PE terminals, its payment provider's tokenisation and an MSP held to written help desk and remote access standards. A brand or management company with hundreds of properties needs central identity, a brand security standard with property audits, and contract clauses that make owners and managers meet it.

Detection and measurement

• Identity signals: password and MFA resets followed within an hour by a new device or location, new authenticator registrations, new identity provider admins or federation changes.
• Endpoint signals: mshta.exe, PowerShell or remote access tool execution on reception and back-office PCs.
• Data signals: bulk reads of guest or loyalty tables, large uploads to cloud storage, loyalty point transfers to newly created accounts.
• Vendor signals: vendor sessions outside approved windows or from unexpected sources.

Framework mapping

Common failure patterns

• Resetting credentials on a convincing phone call. The MGM Resorts breach began, by the attackers' own account, with a help desk call, and ended with reservations, hotel bookings and digital room keys disrupted for about ten days and an estimated $100 million hit to adjusted property EBITDAR.
• Trusting the outsourced support desk by default. In the Caesars Entertainment breach attackers social engineered an outsourced IT support vendor and copied the loyalty programme database, including driver's licence and Social Security numbers.
• Flat franchise networks. The FTC's Wyndham order required franchisee networks to be certified as untrusted precisely because the same entry method had been reused across breaches.
• Keeping everything forever. Passport numbers stored unencrypted and guest records retained for years turned Starwood into a 339 million record breach.
• Shared extranet logins on reception PCs. One phished front-desk PC exposes every booking and every guest conversation on the platform, and leavers keep access.
• Recovery plans that assume the identity provider works. If single sign-on is down, staff cannot reach the runbook, the backup console or the PMS. Keep offline copies and break-glass accounts. See the Break-Glass Account Guide.

Lessons from incidents

The 2023 Las Vegas incidents show the hospitality pattern end to end: social engineering of a help desk or support vendor, takeover of the identity provider, movement to virtual infrastructure, then encryption or data theft. Neither started with a software vulnerability. The controls that would have broken the chain are cheap relative to the losses: a verification script that cannot be satisfied from LinkedIn, phishing-resistant MFA on identity provider admins, alerts on MFA resets, and hypervisor management that is not reachable with an ordinary domain account. See the ESXi Ransomware Playbook.

Practitioner checklist

• Publish a help desk verification procedure that rejects publicly discoverable facts, and bind outsourced desks to it by contract.
• Enforce FIDO2 or passkeys for identity provider, hypervisor, PMS and cloud admin roles, with monitored break-glass accounts.
• Treat every property and franchise network as untrusted by central systems.
• Move card acceptance to PCI-listed P2PE and tokenised card-on-file; scan free text for card and passport numbers quarterly.
• Check direct booking pages against PCI DSS 6.4.3 and 11.6.1.
• Segment guest Wi-Fi, payment, corporate, building and lock systems, and test the segmentation.
• Broker and record all vendor remote access; block unapproved remote access tools.
• Set retention periods for guest identity data and loyalty records, and automate deletion.
• Inventory channel manager, payment and integration credentials with named owners and rotation.
• Rehearse a weekend outage of identity and virtual infrastructure, including manual check-in.

Standards and references

• PCI Security Standards Council: Guidance for PCI DSS E-commerce Requirements Effective After 31 March 2025
• PCI Security Standards Council: Point-to-Point Encryption (P2PE)
• CISA and FBI: Scattered Spider Advisory AA23-320A
• US Federal Trade Commission: FTC Finalizes Order with Marriott and Starwood
• US Federal Trade Commission: Wyndham Settles FTC Charges
• CISA: Commercial Facilities Sector
• Microsoft Threat Intelligence: Phishing Campaign Impersonates Booking.com
• NIST: Cybersecurity Framework 2.0

Related NHI Mgmt Group resources: Cybersecurity for Casinos and Gaming Guide · Retail and E-Commerce Identity Security Guide · PCI DSS 4.0 Guide · Social Engineering Guide · Ransomware Prevention Guide. This guide summarises payment, consumer protection and data protection requirements and is not legal advice.