Situatie

A payment-terminal network is not just “a VLAN for card machines.” It is a tightly controlled path between the POS/terminal, payment gateway or acquirer, terminal-management system (TMS), and a small set of operational services. The main security objective is to prevent a compromise of a workstation, Wi-Fi network, or back-office server from reaching payment devices or affecting payment traffic. PCI guidance strongly recommends segmentation: without effective isolation, a much broader network can fall into PCI scope.

Before implementing controls, map each payment-data flow: terminal to processor, terminal to TMS, POS to payment middleware, DNS/NTP/DHCP dependencies, logging, monitoring, and vendor-support paths. An asset inventory should identify every point-of-interaction device, its model, serial number, owner, location, firmware, network identity, and support status.

Use separate zones with default-deny controls between them:

• Terminal zone: Dedicated wired switch ports or a dedicated SSID/VLAN for payment terminals only. No corporate laptops, printers, guest devices, or general POS browsing systems.

• Payment services zone: The payment gateway, payment middleware, and/or approved connector. Permit only required terminal-to-service flows.

• Management zone: A hardened TMS, monitoring system, patch repository, and a jump host. It should not be reachable directly from normal administrator workstations.

• Corporate zone: Office users, back-office systems, and standard endpoints. Treat this zone as untrusted relative to the payment environment.

• Internet/processor edge: Allow outbound connections only to documented acquirer, processor, DNS, time, certificate-status, and update destinations.

Segmentation can be physical, logical, or both, but it must stop out-of-scope systems from communicating with—or influencing—the cardholder-data environment. A useful rule is: the terminal may initiate only the precise connections needed to process a transaction and receive authorized management updates; everything else is blocked. 

Avoid broad rules such as “terminal VLAN to Internet: allow.” Replace them with allowlisted flows that have a documented business purpose:

Build policy around both network and identity. For example, a TMS server should be the only system that can manage terminals, and a named, MFA-protected administrator should be the only identity allowed to access that TMS. PCI guidance specifically calls for MFA for access into the cardholder-data environment, including remote access to terminals or terminal-management systems.

Treat the terminal as an embedded security appliance, not as a generic network device.

• Change vendor-default credentials and disable unused local, web, SSH, Telnet, Bluetooth, Wi-Fi, USB, debug, and remote-management interfaces.

• Keep vendor-supported firmware and payment applications current through a controlled, authenticated update path; unsupported terminal software is a serious operational and security risk.

• Enforce certificate validation and modern TLS for terminal-to-processor and terminal-to-TMS communications. Do not accept invalid certificates “to make connectivity work.”

• Use device certificates, mutual TLS, or equivalent strong device identity when supported; IP allowlisting alone is not enough because IP addresses can be spoofed or reassigned.

• Remove sensitive card data from POS logs, error messages, packet captures, databases, and support tickets. Prefer processor tokenization so business systems handle tokens rather than primary account numbers.

• Protect terminals from substitution and tampering: maintain a device inventory, inspect devices regularly, train staff to spot altered equipment, and investigate unexpected reboots, serial-number changes, or new network identities.

Remote vendor support is a high-risk integration path. Never expose a terminal, POS controller, or TMS directly to the public internet. Instead, require an approved remote-access gateway or VPN, MFA, a hardened jump host, time-limited approval, session recording where feasible, and centralized logs. Give vendors a narrowly scoped role: a support account should access only the specified terminal group or TMS function, not your full internal network.

If a payment processor requires a static inbound path, terminate it in a dedicated edge zone and forward only the required protocol to a purpose-built integration component. Do not make a firewall exception from the internet to the terminal VLAN.

Hardening is incomplete until it is tested. Monitor firewall-deny events, new MAC addresses, terminal certificate failures, firmware changes, repeated transaction errors, unusual outbound destinations, TMS admin logins, and configuration drift. Review whether each terminal is communicating only with its allowlisted destinations; a terminal making DNS requests to arbitrary resolvers or HTTPS connections to unfamiliar hosts deserves immediate investigation.

Run segmentation validation from a compromised-user perspective: place a test device in the corporate or guest network and verify it cannot discover, route to, scan, administer, or reach terminal-management interfaces. PCI guidance emphasizes that segmentation should be documented, tested, and maintained—not merely shown as a diagram. Re-test after switch changes, firewall changes, new terminals, processor migrations, TMS upgrades, or vendor remote-access changes.

Solutie

Tip solutie

Permanent