Hospitality Identity Security: Hotels, Guests and Staff

Hotels run on identities that change every shift and every season, and most of them were never designed to be individually accountable: a shared front-desk logon, a booking extranet password taped inside a drawer, a property system vendor account that has worked for ten years. The sector's best-known incidents began with an identity, not a software flaw: a help desk call, an outsourced support vendor, a phished reception PC. This guide goes deep on the identity layer only: workforce accounts across brand, management company and property; shared front-desk and back-office devices; property management system (PMS), point-of-sale and lock system roles; booking platform accounts; guest and loyalty accounts; and the machine credentials that connect them. It is written for identity, IT and security teams at hotel groups, management companies and independent properties. Payment scope, network segmentation and the sector's regulatory picture are covered in the Cybersecurity for Hospitality Guide, which this guide builds on rather than repeats.

Source note: this page summarises regulator, standards body and official sources listed at the end, as of November 2026. Confirm against the official text before relying on it.

Key takeaways

Map identities by who employs the person, not where they stand. A front-desk agent may be employed by a management company, work under brand standards and use the owner's equipment. Decide which directory is authoritative for each population before choosing controls.
Shared logons are the sector's default and its biggest accountability gap. Replace generic front-desk accounts with fast individual sign-in on shared devices, so every reservation change, refund and key issued traces to a person.
Seasonal and agency staff need lifecycle automation, not goodwill. Pre-set end dates, same-day removal across PMS, extranets and email, and periodic reconciliation against rosters close the gap that turnover creates.
Loyalty accounts are stored value. Treat points redemption, transfer and contact-detail changes as high-risk actions with step-up authentication, and defend login against credential stuffing.
Property integrations are machine identities with broad reach. Channel manager, payment, PMS interface and identity sync credentials each need an owner, a scope and a rotation plan.

The identity populations in a hotel

Hospitality identity is unusually fragmented because one property can involve a brand, a management company and an owner, each with its own systems. Start with an inventory that names every population and its authoritative source.

Population	Typical systems	Authoritative source	Main identity risk
Brand corporate staff	Brand identity provider, central reservations, loyalty platform, cloud consoles	Brand HR system	Help desk social engineering leading to identity provider admin access
Property staff (managed or franchised)	PMS, POS, email, booking extranets, key encoders	Management company or franchisee HR, often several	Shared logons, slow leaver removal, no MFA on extranets
Seasonal, agency and event staff	PMS front office, POS, banqueting systems	Agency rosters, often spreadsheets	Accounts that outlive the contract
Vendors and outsourced IT	Remote access to PMS, POS, lock management, building systems; outsourced service desk	Contracts, rarely a directory	Standing remote access and reset authority without verification
Guests and loyalty members	Booking engine, loyalty app, mobile key, guest Wi-Fi portal	Customer identity platform	Credential stuffing, points theft, contact-detail takeover
Machine identities	Channel manager APIs, payment gateway, PMS interfaces, identity sync connectors, mobile key back end	Usually nowhere: discovered by audit	Long-lived keys with no owner

For franchised and managed properties, the brand rarely controls the property directory. A practical model is federation: the brand identity provider trusts the management company's identity provider for brand systems, with the brand enforcing MFA and session rules through conditional access, while property-only systems stay with the operator. Write the split into the management or franchise agreement, including who removes leavers and within what time.

Front desk and shared devices

Reception and back-office workstations are used by several people per shift, and the historical answer has been a generic "frontdesk" Windows logon with the PMS left signed in. The consequences are concrete: no individual accountability for rate overrides, refunds or room moves; any phished session exposes everything the shared account can do; and leavers keep working credentials because the password is common knowledge.

Patterns that work at a front desk

Individual sign-in with fast switching: each agent has a named account, and the workstation or tablet supports quick user switching with a badge tap, a FIDO2 security key or a short PIN bound to the device. For example, on iOS, iPadOS and Android, Microsoft Entra shared device mode lets an employee sign in once to all supported apps and, at the end of a shift, sign out of the device and every supported app in one action, ready for the next user. See the Passwordless for Frontline and Shared Devices Guide.
Application-level identity in the PMS: even where Windows remains shared for a transition period, require a personal PMS login, and configure the PMS session timeout to match the pace of the desk (short enough to stop walk-up misuse, long enough not to drive staff to workarounds).
Role design in the PMS and POS: separate roles for front office agent, supervisor, night auditor, revenue manager, accounts and system administrator. Restrict rate overrides, refunds, folio transfers, comps and deposit releases to supervisor roles, and require a second user to approve above a value threshold.
Key encoder accounts: issuing a guest key is an identity decision. Require a named login on the lock management software, restrict master and emergency key issuance to named supervisors, and review the issuance log daily.
Payment card scope: PCI DSS Requirement 8.2.2 allows shared or generic IDs only where needed for an exceptional circumstance, and the PCI Security Standards Council states that it applies to all shared authentication credentials, not only administrators. Any front-desk system that can connect into the cardholder data environment also needs MFA under Requirement 8.4.2. See the PCI DSS 4.0 Guide.

The device side, including kiosk lockdown and self-service check-in terminals, is covered in the Kiosk and Shared Device Security Guide.

Booking platform and extranet accounts

Online travel agency extranets hold reservations, guest messages, rates and payout details, and attackers target them directly. Booking-themed phishing aimed at reception staff is described in the hospitality guide linked above. The identity controls that matter are simple and often missing:

Named users instead of one shared login: extranets increasingly support multiple users with per-area permissions. Booking.com's partner help, for example, documents extranet account types with access rights set per user. Give each staff member their own user, and keep finance and user management rights to a small set.
Two-factor sign-in on every extranet account: Booking.com's partner safety guidance, for example, asks properties to enable two-factor authentication and states that its partner service representatives will never ask for the account password.
Dedicated browser profile or device: keep extranet access off the reception PC used for guest email where possible, because guest-message lures are the delivery route.
Leaver removal: extranet users rarely appear in the HR leaver process. Add every extranet, channel manager and revenue system to the leaver checklist with an owner per property.

Seasonal staff, agencies and vendors

Turnover is the defining identity problem for hotels. The Joiner-Mover-Leaver Guide covers the general process; the hospitality-specific adjustments are below.

End dates at creation: every seasonal, agency and event account gets an expiry date set from the contract, so access lapses even if nobody files a leaver form.
Roster reconciliation: weekly comparison of active PMS, POS and extranet users against the property's current rota and agency timesheets, with differences disabled pending confirmation.
Role templates per job: pre-built access packages (front office agent, housekeeping supervisor, banqueting captain) so new starters receive the same, minimal access every time instead of a copy of a colleague's account.
Vendor access through a broker: PMS, POS and lock vendors connect through a single gateway with MFA, named vendor users, time-bound approval and session recording. See the Third-Party Access Guide and the Contractor Identity Lifecycle Guide.

Help desk and outsourced support

The FBI and CISA advisory AA23-320A describes Scattered Spider pressuring help desk staff by phone to reset passwords and MFA, exploiting contracted IT help desks, and push-bombing users until they approve. The MGM Resorts breach began, by the attackers' own account, with a help desk call and ended with administrator access to the identity platform and about ten days of disruption to reservations and room keys. In the Caesars Entertainment breach an outsourced IT support vendor was socially engineered and the loyalty programme database copied. The advisory recommends phishing-resistant MFA (FIDO/WebAuthn or PKI-based) for all services to the extent possible. For hotels, the reset procedure itself must also change: no reset on facts an attacker can research, a callback to the number on file or a manager or in-person check at the property, and the same rules written into outsourced desk contracts. See the Account Recovery and Help Desk Security Guide.

Guest and loyalty identity

Loyalty points behave like currency, and loyalty accounts hold contact details, stay history and sometimes stored payment tokens. The FTC's December 2024 final order against Marriott and Starwood requires, among other things, a way for US customers to request deletion of personal data linked to their email address or loyalty number, and that Marriott review loyalty accounts on customer request and restore stolen points.

Guest journey step	Identity risk	Control
Login to booking engine or app	Credential stuffing with passwords from other breaches (T1110.004)	Breached password screening, risk-based MFA for new devices and unusual locations, graduated rate limiting, bot and connection fingerprinting, as set out in OWASP's Credential Stuffing Prevention Cheat Sheet
Change of email, phone or password	Account takeover made permanent	Step-up authentication, notification to the old contact details, short cooling-off before redemption
Points redemption or transfer	Points drained to attacker accounts	Step-up on redemption and transfer, alerts on transfers to newly created accounts and on bulk redemptions
Mobile key issuance	Room access granted to the wrong person	Bind mobile key to the verified booking holder's authenticated app session and device; reissue only after re-authentication
Front desk lookup by phone	Caller impersonates a guest to change bookings or obtain details	Verify with booking reference plus a factor not on the confirmation email, and log the agent who made the change

OWASP also recommends notifying users when the correct password was used but MFA failed, and avoiding email addresses as usernames where possible. See the Loyalty Points and Gift Card Fraud Guide and the Account Takeover Prevention Guide.

Property system and machine credentials

Every hotel system that talks to another does so with a credential: channel manager API keys that push rates and availability to OTAs, payment gateway keys, PMS to POS and PMS to lock interfaces, revenue management service accounts, guest Wi-Fi portal integrations, and identity sync connectors. According to the attackers' account, MGM shut down its Okta sync servers during its 2023 incident, which shows how central such connectors are.

Inventory: list every interface on the PMS, POS, lock and identity platforms, the credential type and where it is stored.
Assign owners: one named owner per integration at the brand or management company, not the vendor.
Scope: one credential per property and per integration, never a group-wide key shared across properties.
Rotate and vault: move keys out of configuration files and spreadsheets into a secrets manager; rotate on vendor change, staff departure of anyone who saw the key, and on schedule.
Monitor: alert on use from new IP ranges, outside expected schedules, or at volumes that suggest bulk extraction of guest data.

See the API Key Management Guide.

Rolling it out

Days 0 to 30, inventory: populations and authoritative sources per property, shared accounts on PMS, POS, Windows and extranets, admin accounts on the identity provider, vendor accounts, and integration credentials.
Days 30 to 90, close the front doors: help desk verification procedure live (pilot with one service desk, then all, including outsourced desks); phishing-resistant MFA for identity provider, PMS administration and cloud admin roles in report-only mode first, then enforced with monitored break-glass accounts; two-factor on every extranet account.
Months 3 to 6, individual accountability: named PMS and POS logins at pilot properties, shared-device sign-in at the front desk, role templates for each job, and expiry dates on all seasonal and agency accounts.
Months 6 to 12, guests and machines: step-up on loyalty redemption and contact changes, credential stuffing defences on login, integration credentials vaulted with owners.
Rollback: every enforcement change has a named approver and a tested reversal, and properties keep a documented manual check-in and key issuance procedure, because a front desk that cannot serve guests will create its own workarounds.

Small independents and large groups

Independent hotel: a hosted PMS with named users and MFA, a password manager for the few shared vendor and utility accounts that remain, two-factor on every extranet, and an MSP bound by contract to written reset and remote access rules.
Management company or brand: central identity with federation to operators, access packages per role, automated leaver feeds from each employer's HR, a brand identity standard audited at properties, and a central register of integration credentials.

Detection and measurement

Identity provider: password or MFA resets followed within an hour by a new device or location, new authenticator registrations (T1098.005), new administrators or federation changes, and MFA prompt floods (T1621).
PMS and POS: rate overrides, refunds and comps by user against peers, activity by accounts of staff not on the rota, and logins outside shift times.
Extranets and loyalty: payout detail changes, logins from new countries, failed login surges, and points transfers to new accounts.
Machine identities: integration credentials used from new networks or at unusual volumes.

Metric	Target direction
Shared or generic accounts remaining on PMS, POS and front-desk Windows	Falling to documented exceptions only
Median time from last shift to account disablement for seasonal and agency staff	Same day
Extranet accounts with two-factor enabled	100 percent
Admin roles on phishing-resistant MFA	100 percent
Integration credentials with a named owner and rotation date	100 percent
Loyalty account takeover reports per 10,000 active members	Falling

Framework mapping

Control area	NIST CSF 2.0	NIST SP 800-53 Rev. 5	ATT&CK v20 threat addressed
Individual accounts on shared devices	PR.AA-01	IA-2, IA-4, AC-2	T1078 Valid Accounts
Help desk verification and phishing-resistant MFA	PR.AA-02, PR.AA-03	IA-2, IA-5	T1566.004 Spearphishing Voice, T1621
PMS and POS role design	PR.AA-05	AC-6	T1657 Financial Theft
Seasonal and agency leavers	PR.AA-01	PS-4, PS-7, AC-2	T1078 Valid Accounts
Vendor and outsourced desk access	GV.SC-07	AC-17, PS-7	T1199 Trusted Relationship
Guest and loyalty accounts	PR.AA-03	IA-8	T1110.004 Credential Stuffing
Monitoring	DE.CM-03	AC-2	T1098.005 Device Registration

Common failure patterns

One "frontdesk" password for every shift: no accountability, and every former employee knows it.
Help desk trusts what can be researched: names, employee IDs and managers from social media satisfy the script, as the MGM Resorts breach illustrates.
Outsourced desk outside the security model: the vendor can reset credentials but is not held to the same verification rules or monitored.
Extranets left out of the leaver process: HR removes email but not the OTA, channel manager or revenue system users.
Group-wide integration keys: one channel manager or payment key reused at every property, so one leak exposes the group.
Loyalty treated as marketing, not finance: no step-up on redemption, so stolen passwords convert straight into stolen points.

Practitioner checklist

Inventory identity populations per property with the authoritative source and the employer responsible for leavers.
Replace shared front-desk and PMS logons with named accounts and fast shared-device sign-in.
Design PMS and POS roles so overrides, refunds and master keys need supervisor rights.
Set expiry dates on all seasonal, agency and event accounts and reconcile weekly against rotas.
Give every extranet user a named login with two-factor, and add extranets to the leaver checklist.
Enforce a help desk verification procedure, including for outsourced desks, and phishing-resistant MFA for admins.
Add step-up authentication to loyalty redemption, transfers and contact-detail changes.
Vault and own every integration credential, one per property and integration.

Hospitality Identity Security: Guest Accounts, Front Desk Access and Property System Credentials