A hotel network should segment guest Wi-Fi, staff devices, PMS, POS, electronic locks, guest-room controls, cameras, and building systems into separate VLANs with firewall rules that deny traffic by default. The property only works, though, if a short list of deliberate exceptions is opened between specific systems — PMS to the lock server so credentials get issued, PMS to room controls so occupancy and energy events fire, and a narrow, logged path for payment data. Getting the segmentation right is only half the job; naming the exceptions and handing over documentation for them is the other half.
Why can't a hotel just isolate every system completely?
Full isolation sounds safer, but a hotel's guest-facing systems depend on a handful of cross-system messages to function. A reservation has to reach the lock system to produce a working key, and a check-in status has to reach a guest-room controller to end an energy setback. Oracle's hospitality integration platform exists for exactly this reason — it gives hotels and integration partners OAuth 2.0-secured, application-key-controlled access to specific OPERA Cloud APIs and business events, rather than an all-or-nothing database connection, so a hotel can grant a lock vendor or room-control vendor only the data and events it actually needs (Hospitality Integration Platform - PMS and POS). A hotel network should follow the same logic as that API layer: default-deny between VLANs, then add narrow, named, logged exceptions for the systems that must cooperate.
What exception does the PMS-to-lock connection actually need?
Salto's Space access-control software is built to sit inside a hotel's network and communicate with the PMS over one of three supported protocols — Oracle Hospitality PMS (FIAS), the Industry Standard protocol, or FOLS — and each one opens or connects through a specific, configurable TCP/IP port rather than a generic open link (PMS tab in Salto Space General options). For the Industry Standard protocol over TCP/IP, when the PMS and Space run on separate machines the port number must be 5010 or higher, and the installer can select an option to limit communications to one server — accepting requests only from a specified PMS server IP address rather than from the whole PMS subnet. That "limit communications to one server" setting is the kind of narrow rule a firewall policy should mirror: the lock server's listening port should be reachable only from the PMS host's IP, not from the entire PMS VLAN.
Salto's own system-requirements documentation underlines why this connection should not be treated casually: the Space service is "not an isolated piece of software" — it opens listening ports for PMS, elevator systems, LDAP, and other third-party systems, and Salto explicitly states that "Space has been designed for LAN environments only. Do not expose it directly to the internet," recommending a VPN for any remote access need (System requirements and considerations for installing Space). In practice that means the PMS-to-lock exception belongs on an internal firewall rule between two named hosts and specific ports, never as an exposed public endpoint, and the integrator should confirm with the property's Salto installer which of the three protocols is in use before the VLAN rule is written.
How does the PMS talk to guest-room controls without a wide-open link?
A guest-room platform's integration with the PMS should be scoped the same way as the lock exception: a specific host, a specific port, and a specific direction of traffic, confirmed against the room-control vendor's own integration documentation rather than assumed. Ask the vendor directly which protocol, port, and host it needs opened before the firewall rule is written, rather than opening a blanket allow-rule between the PMS VLAN and the control VLAN — this is a question worth putting to whichever guest-room automation platform a property has chosen, as part of design on a hospitality project.
Oracle's own Integration Platform reinforces the same pattern from the PMS side: it issues scoped application keys and lets external systems subscribe only to the specific OPERA Cloud APIs and business events they need — such as reservation, front-desk, or housekeeping event streams — rather than granting broad data access, and testing happens first in a nonproduction sandbox before any credential touches the live property (Hospitality Integration Platform - PMS and POS). A network segmentation plan should ask every PMS-adjacent vendor for that same level of specificity: which host, which port, which direction, and which event types are permitted to cross the VLAN boundary.
Why does payment data need its own isolation, separate from everything else?
Payment card data is the one exception category that should not be widened for convenience, because every system it touches enters PCI DSS scope. Oracle's Payment Interface addresses this directly by tokenizing card data to limit the use and storage of plain-text sensitive data, most often the primary account number, to as few places in the environment as possible — Oracle describes this as reducing "the scope of PCI security concerns for any customer" (Payment Interface System | Hospitality Point-of-Sale). For network design, that means the POS/payment VLAN should carry only the tokenization path to the payment processor, isolated from the PMS VLAN, the guest Wi-Fi VLAN, and certainly from the lock and room-control VLANs. Ask whichever payment and PMS vendors are selected which parts of the transaction flow are tokenized and which ports the payment interface itself requires, since those are the only connections that should cross into the payment VLAN.
What documentation should the integrator hand over at opening?
Before a property opens, the network design should produce a small, specific set of handover documents rather than a general network diagram: a VLAN/IP address map showing which subnet each system (guest Wi-Fi, staff, PMS, POS, locks, room controls, cameras, BMS) sits on; a firewall rule list stating every permitted cross-VLAN connection by source host, destination host, port, and protocol — including the PMS-to-lock and PMS-to-room-control exceptions discussed above; and the credential and support-contact information needed to maintain those rules after opening. Network infrastructure that is only understood by one departing contractor is a liability the moment that contractor is gone, so the documentation should be written for whoever inherits network support. For a broader view of what a hotel technology integrator scopes end to end, see Cave Group's hospitality service page, and for a related look at the full pre-opening segmentation and testing sequence, see the existing article on what a hotel network must pass before opening.
Frequently asked questions
Does segmenting a hotel network mean PMS, locks, and room controls can never talk to each other?
No. Segmentation means traffic is denied by default between VLANs, and then a small number of named, logged exceptions are opened only where the property genuinely needs them — such as PMS-to-lock credential issuance and PMS-to-room-control occupancy events — rather than leaving broad access open between every system.
Which protocols does a Salto lock system use to connect to the PMS?
Salto's Space software supports three PMS protocols: Oracle Hospitality PMS (FIAS), the Industry Standard protocol, and FOLS, each configured over a specific TCP/IP port (or RS232), with options such as limiting the Industry Standard connection to a single named PMS server IP address.
Can the PMS-to-lock connection be exposed to the internet for remote access?
No. Salto's own documentation states that Space is designed for LAN environments only and should not be exposed directly to the internet; if remote access to the system is needed, a VPN should be used instead.
How does tokenization reduce PCI scope in a hotel network?
Oracle's Payment Interface tokenizes card data at the point of capture so that sensitive data such as the primary account number is not stored or passed in plain text across the PMS, POS, and other hospitality systems it supports, which Oracle states significantly reduces the scope of PCI security concerns for the property's other systems.
What should be in the network documentation handed over when a hotel opens?
At minimum, a VLAN/IP address map by system, a firewall rule list naming every permitted cross-VLAN connection by host, port, and protocol, and the credentials and support contacts needed for whoever maintains the network after opening — questions worth confirming directly with your integrator before go-live.