Your biggest security risk has a login to your PMS.

Chapter 01

Every integration is a door. Most were installed and never reviewed again.

A modern hotel runs on supplier connections: the PMS vendor with remote support access, the channel manager syncing rates, the POS integrator, the lock system, building automation. Each connection was opened for a good reason, usually years ago, usually with broad access and a shared account. Individually reasonable, together they form an attack surface nobody owns. NIS2 makes chain security an explicit duty, but the real argument is simpler: breaches love the door nobody watches.

Think about who can reach your PMS tonight. The vendor’s support team, probably through a VPN that is always on. The channel manager, through an API key created three general managers ago. The POS integrator, with an account named after a company instead of a person. The lock system engineer who did the retrofit years back. None of these people are your employees. Most of them you have never met. All of them hold a key to the system that stores every guest name, card token and reservation you have.

Attackers have learned this. A supplier’s credentials open the same doors as yours, and the route is quieter: nobody blinks at a vendor account logging in, even at 2am on a Sunday. The hotel watches its own front door and forgets the service entrance. Once inside the PMS, the playbook is short: export guest profiles, read upcoming reservations, plant a foothold for later. Both fraud and ransomware start there.

The second column is not exotic. Every control in it exists in mature IT organisations today. That is what hotel PMS security comes down to: a process question, not a technology question. The rest of this piece is about getting there without disrupting the suppliers you depend on.

Chapter 02

Not paranoia. Housekeeping.

Inventory every supplier with access: what they reach, how, with which account and why. Include the informal ones: the AV company with a router in the meeting room, the spa system that syncs bookings, the consultant who still has a login from last year’s project. Most hotels find connections nobody remembers approving. Write down the shared logins at the front desk too: nobody can say who used a generic account, so nobody answers for it. You cannot secure what you haven’t listed.

Least privilege and time bound sessions: the PMS vendor gets the PMS, during the change window, with a named account and MFA. Standing broad access is a habit, not a requirement. Vendors rarely object when you ask. Time bound access with MFA is what their own security teams recommend, and a named account protects their engineer as much as it protects you. The same discipline applies inside the house: staff turnover is high, and a login that survives its owner’s departure is a liability with a password.

Segmentation keeps supplier connections away from everything they don’t need, and monitoring makes vendor sessions visible. This is where segmentation earns its keep: a compromised supplier account on a flat network reaches everything, while on a segmented network it reaches one system and the alarm sounds before it moves. An unusual login from a supplier account should raise an alarm like any other.

Assess suppliers on security, put requirements in contracts and revisit them yearly. Make the annual review boring and standard: which accounts exist, which were actually used this year, which can close. A supplier that pushes back on that conversation is telling you something worth knowing. The same chain logic your corporate clients apply to you, as described in NIS2 is live, applies to your suppliers.

None of this requires new technology. It requires an afternoon of inventory, a few honest phone calls and the willingness to treat access as something that expires. The hardest part is starting: the current state stays invisible until someone writes it down. After the first supplier moves, the second conversation is easier.

Chapter 03

Simple rules that close most of the surface.

When the inventory is done and the accounts are restructured, what does good look like? Not a fortress, and not a bureaucracy that turns every vendor visit into a negotiation. The target state is a small set of rules that every supplier connection follows, without exception, because exceptions are exactly where breaches start. Guests never see any of it: good PMS security is invisible at the front desk and visible in the audit trail.

No more accounts called support or vendor01. Every login belongs to a person, carries MFA and can be switched off the day that person changes jobs. When something odd appears in a log at night, you know exactly who to call, and the supplier knows exactly which engineer was in. The front desk deserves the same rule: shared logins quietly outlive the people who used them, and a leaver process that closes accounts the same week does more for PMS security than most hardware.

Access is granted for a task and a window, then closes on its own. The PMS vendor gets in for the Tuesday night update, not for the quarter. If they need in again, they ask again. Asking takes minutes. Standing access takes years to notice, and by then nobody remembers why it was granted. The audit trail becomes readable too: when access maps to tasks, anything without a reason stands out on its own.

Vendor sessions are logged and monitored like any other privileged activity. Unusual timing, unusual volume or an unusual source raises an alert. Most vendors will never trigger one. The point is that the one who does gets noticed the same night, not in next quarter’s audit. It also limits the damage when an attacker does get in: with a monitored session the question is minutes, with an unmonitored one it is months.

Hold this target state up against your current estate and score it honestly. Most hotels start far from it, and that is fine. Each rule can be introduced supplier by supplier, starting where the value is highest. Honest scoring matters more than a high score: an estate that knows its gaps can plan. The distance between here and there is the work plan of the next chapter.

Chapter 04

Every step reduces real risk on its own.

Within Secure360, third party risk is a standard discipline: we inventory the connections, restructure the access, segment the network and keep vendor activity inside the same 24/7 SOC monitoring as everything else.

List every supplier connection, account and access path. Pull the list from firewall rules, VPN configurations and account exports, not from memory. The connections nobody remembers are the reason you are doing this. Include dormant accounts and finished projects: those are the doors attackers look for first, precisely because nobody else does.

Score each connection on access, necessity and vendor security. A rate sync that reads prices is not the same risk as a remote desktop into the PMS server. Score them differently and spend your attention where the score is high. This is where hotel PMS security earns its priority: the system holds guest identities and payment references, so any path into it scores high by default.

Move to named accounts, MFA, least privilege and time bound sessions. Do it with the supplier, not to them: a short call, a new account, a scheduled window. Most transitions take days, not months. Named accounts also absorb supplier staff churn: you close one person’s access without breaking the integration.

Log and watch vendor sessions continuously, with alerts on anomalies. Odd behaviour from a vendor account looks exactly like odd behaviour from a staff account: wrong hour, wrong volume, wrong place. The SOC treats them the same. When a regulator, an insurer or a corporate client asks who accessed the PMS and when, the answer is a query, not a reconstruction.

Start with the PMS and payment chain: highest value, most connections, fastest risk reduction. Then work outward through locks, building automation and the long tail of small integrations. By the time an auditor or a corporate client asks how you manage third party access, the answer is a report, not a promise. Each step already reduces risk on its own, so there is no reason to wait for the perfect programme before taking the first one.

Chapter 05

Trust is a fine basis for a partnership. It is a poor basis for access control.

Good suppliers understand security requirements; the best ones expect them. Making access managed and visible protects both sides of the relationship, and it prepares you for the assessments your own clients increasingly run. See how an attack actually unfolds in ransomware at 2am, and how to prove your posture in the NIS2 Quality Mark. Verification is not an accusation. It is the difference between believing your access is under control and being able to show it.

None of this needs to strain the relationship. Share the inventory with your key suppliers, explain the new access model and agree a date to switch. The good ones will match it without drama, because they run the same model with their other clients. The conversation itself tells you which category each supplier belongs to. Set a date and hold it, because a migration that drifts becomes a migration that never happens.

There is a commercial upside too. Corporate clients and booking partners increasingly send security questionnaires before they sign, and third party access is always on them. A hotel that can show named accounts, time bound access and monitored sessions answers in an afternoon. A hotel that cannot loses deals it never hears about.

And your best suppliers will thank you. A well run vendor would rather work through a clean, logged, time bound door than hold a standing key that makes them the suspect whenever anything goes wrong. Managed access is not a sign of distrust. It is what professional partners recognise in each other.