Who can reach your hotel systems? A review of vendor remote access, integrations and API keys

A third party access review lists every outside person and system that can reach a hotel's software, what each one can read or change, how it connects, and whether it is still needed. It is repeated twice a year and whenever a vendor, agency or employee leaves.

The web agency that built your booking page two years ago still has the login. A channel connection from a trial nobody cancelled is still open. Neither appears on any list, because no list exists yet. This article shows you how to build that list, how to judge each connection on it, and how to close doors without breaking the systems behind them.

Who outside your hotel can reach your systems?#

More parties than most hotels can name. The first step is not fixing access but writing down every outside party that holds a credential, a connection or a remote-support tool pointing at your systems.

Walk the list by category, not by memory: software vendors, your IT provider, the web agency, channel and booking connections, payment and e-invoice integrators, and anyone who worked for you in the past. For each party, record four things: what it can reach, how it connects (a login, a remote-support tool, an integration key), who inside the hotel approves its use, and the date it was last reviewed.

Separate read from change. A party that can only read reports is a different risk from one that can change rates, cancel reservations or move money. Include the connections nobody remembers approving: a trial channel connection, an old review-widget script, a mailing tool a former marketing agency installed.

Name one owner for the list. A list with no owner is a document, not a control. Expect the list to be longer than the number of contracts in the drawer; the gap between the two is the finding.

Is remote support access always on, or only when you ask for it?#

Always-on remote access is a common gap in hotel systems, because it turns a support contract into a permanent open door that nobody at the property can see.

Distinguish two modes. Unattended access lets a vendor connect at any hour with a stored credential. On-request access needs a person at the hotel to approve each session. Prefer on-request for anything that touches guest data or billing, and reserve unattended access for equipment that genuinely needs it, such as a server that must be reachable overnight.

Make the approver different from the requester, and give the approval a time window: a session that opens for two hours and closes itself is better than one that stays open until someone remembers. Ask for a session log: who connected, when, from where and for how long. A log you never read still changes behavior, because the vendor knows it exists.

Screen sharing and full machine control are not the same permission; the second lets someone install software or change settings while your staff watch. Review the remote-support tool's user list itself, not only the software it reaches. Removing a departed technician from that list is a quick, low-cost improvement.

What can an integration or an API key actually do?#

An integration is one system talking to another without a person in between, and an API key is the password it uses to prove it is allowed in. Whatever that key can reach, anyone holding it can reach too.

Gloss the terms once for the team: an API is a defined way for two systems to exchange requests; a key is a long string that identifies the caller; a scope is the list of things that key may do. If you want a fuller explanation in plain words, see Hotel PMS integrations explained: APIs in plain words.

Write down what each key can read and what it can change. A key that only pushes rates is not the same as one that can create, modify or cancel reservations. Give each integration its own key: a single key shared by the website, the channel connection and a reporting tool means you cannot revoke one without breaking all three.

Where the other system allows it, choose read-only scope and an expiry date; a key that dies in ninety days forces a conversation you would otherwise skip. Find where keys are stored. A key pasted into a website plugin, a spreadsheet on a shared drive or an email thread is a key that has already leaked further than you think. Never place a key in a public web page or a guest-facing page; anything a browser downloads can be read by whoever opens it.

What happens to access when a person or a vendor leaves?#

Usually nothing, which is why former staff and former agencies are a frequent finding in an access review. Access survives the relationship unless someone deliberately ends it.

Build the revocation list before the departure, not after: PMS user, hotel email, website admin, channel connection, payment and e-invoice portals, social accounts, the business profile on search engines, door-lock software, the Wi-Fi controller. Disable accounts rather than deleting them where the system allows it, so the history of what that person did stays readable. For how to set narrow rights for these accounts inside the PMS in the first place, see PMS user roles and permissions: a setup checklist for hotels.

Handle agencies as a group. A marketing or web agency often holds several logins, and the account is in the agency's name, not the hotel's. Ask for ownership transfer at the start of the contract, not at the end. Kill shared accounts: a login called admin or info@ cannot be attributed to a person, so it cannot be reviewed, and it usually survives every departure.

Change passwords that the leaver could have seen, including ones written on a card in the back office, and check the domain registrar, which is easy to forget and damaging to lose. Record the date of each revocation. A review that cannot show a date is a promise, not evidence.

How do you change keys and passwords without breaking the hotel?#

Rotate in a fixed order: create the new credential, connect it, confirm the data flows, then revoke the old one. Doing it in the other order is how a hotel loses a night of channel updates.

Change one integration at a time and verify it with a real test, not an assumption: a rate pushed to a channel, a test reservation, a report that still loads. Pick a quiet hour and tell the front desk, so a failed connection is reported in minutes rather than discovered at check-in. To understand what a channel connection actually sends back and forth, read How a channel manager connection works: messages, delays and errors.

Keep a break-glass credential for the systems you would need in an emergency, stored offline and known to two named people, and change it when either of them leaves. Rotate on events, not only on a calendar: a departure, a contract ending, a vendor telling you its staff changed, or any sign of unusual activity. Write the date of the last rotation next to each entry on the list, so the next review starts from facts.

Expect one thing to break. The purpose of the sequence is to make the break small, visible and reversible.

The twice-yearly review sheet#

Two sessions a year, on fixed dates, with the same sheet and a named owner, are enough to keep outside access from drifting. The sheet is short on purpose; a long one does not get filled in.

Set the dates in advance, for example the first week of March and the first week of September, and put them in the general manager's calendar rather than the IT provider's. Run the same five questions over every entry: who is this, what can it reach, is it still needed, who approved it, when was it last changed. Add a line for anything new since the last review, and a line for anything that should have been removed and was not.

Keep the completed sheets. Two years of dated sheets answer most questions an owner, an insurer or an auditor will ask. Treat the review as a business decision, not a technical one: the person who decides whether an agency still needs website access is the person who pays the agency.

For a wider look at security practices around the property, pair this with the Hotel cybersecurity checklist for owners and general managers.

What to do next#

Book two hours with the person who holds the passwords, open a blank sheet and fill in the first column: every outside party that can reach your systems. You do not need to fix anything in that session. You need the list, an owner and a date, because the review only works when it becomes a habit with a calendar entry rather than a reaction to an incident.