What is PCI-DSS v4.0.1 and What Actually Changed?

PCI-DSS – the Payment Card Industry Data Security Standard – is the global framework governing how organisations that handle cardholder data must protect it. It is maintained by the PCI Security Standards Council, a body founded by the major card schemes: Visa, Mastercard, American Express, Discover, and JCB.

Version 4.0 was published in March 2022 and replaced v3.2.1 as the active standard. Version 4.0.1, a minor clarifying update, followed in June 2024. The full set of requirements became mandatory on 31 March 2025, with no grace period for the new controls that were previously listed as “best practice”.

The headline shift from v3.2.1 to v4.0 is the move from periodic compliance to continuous security. Under v3.2.1, many controls were assessed at a point in time – an annual QSA assessment would review a snapshot of the environment. v4.0 introduces the concept of customised implementation and ongoing assurance, with controls that require continuous monitoring, automated testing, and demonstrable evidence of operational security – not just a configuration review taken once a year.

The key changes that affect IoT and connected payment environments

Why IoT Payment Devices Are a Different Security Problem

Traditional PCI-DSS compliance was designed for a relatively contained environment: servers in a data centre, POS terminals on a local network, staff at fixed workstations. The threat model was about protecting data in transit and at rest within a known, bounded perimeter.

The modern payment environment does not look like that. Payment devices are distributed across hundreds or thousands of locations. They communicate over cellular networks rather than fixed LAN infrastructure. They are physically accessible to members of the public in retail, hospitality, and transport environments. They are managed remotely by vendors, acquirers, and IT teams who may be in different countries. And they share network infrastructure with other IoT devices – building management systems, environmental sensors, CCTV, access control – that may have very different security postures.

Each of these characteristics creates attack surface that did not exist in the traditional PCI model.

The distributed physical attack surface

A POS terminal in a busy retail environment is touched by hundreds of people per day. Physical tampering – attaching a skimming overlay, replacing the device with a cloned unit, inserting hardware into a peripheral port – is a persistent real-world threat. Unlike a server in a locked data centre, a payment terminal on a shop counter has no physical access control beyond the vigilance of staff. PCI-DSS has always required physical security controls for payment terminals, but the distributed nature of modern retail and hospitality deployments makes consistent enforcement genuinely difficult.

Cellular connectivity as an attack vector

Many modern payment devices and the gateways that connect them use cellular connectivity as their primary data path – either directly (a SIM card in the terminal) or indirectly (a cellular router providing internet connectivity to the payment network segment). Cellular connectivity introduces attack vectors that do not exist on fixed LAN infrastructure:

• SIM swapping – an attacker who gains access to the account management systems of the mobile network operator can reassign a SIM card to a device they control, redirecting traffic from the legitimate device.
• IMSI catching – rogue base stations (IMSI catchers or “stingrays”) can intercept cellular traffic from devices in range. While modern LTE and 5G include protections against the most basic IMSI catcher attacks, sophisticated variants remain a concern for high-value targets.
• Rogue APN configuration – if an attacker can modify the APN configuration on a cellular router or terminal, they can redirect traffic to an infrastructure they control rather than the legitimate payment processor.
• Management interface exposure – cellular routers with management interfaces exposed to the internet (rather than behind a VPN or private APN) are discoverable via tools like Shodan and represent a direct route to reconfiguring the payment network.

Shared IoT network infrastructure

In many retail, hospitality, and transport environments, payment devices share network infrastructure with other IoT systems. A hotel might have CCTV cameras, guest Wi-Fi, building management sensors, and payment terminals all on the same router and cellular connection. If any of those non-PCI devices is compromised, an attacker has potential lateral movement paths toward the payment environment. PCI-DSS requires network segmentation precisely to prevent this – but in IoT deployments, segmentation is frequently incomplete or poorly documented.

The Attack Vectors: What Threats Actually Look Like

Understanding the specific attack vectors helps move security decisions from abstract compliance requirements to concrete defensive measures. These are not theoretical risks – they represent documented attack patterns observed in real payment security incidents.

Physical skimming and terminal tampering

The oldest attack in payment security and still among the most common. Physical skimming devices are overlays or inserts designed to capture card data at the point of interaction – either the magnetic stripe data from swipe, the PIN from keypad entry, or increasingly the NFC/contactless transaction data. Modern skimmers are sophisticated: they can be 3D-printed to match specific terminal models, they transmit captured data via Bluetooth or cellular, and they can be installed and retrieved within minutes by a trained operative.

Beyond skimmers, full terminal replacement is a documented attack – where a legitimate terminal is swapped for a cloned or modified unit that appears identical but routes transactions through attacker-controlled infrastructure while passing them to the legitimate processor to avoid immediate detection.

Man-in-the-middle on cellular traffic

If payment traffic traverses the public internet – even encrypted – it passes through infrastructure an attacker may be able to influence. TLS provides strong protection against passive interception, but man-in-the-middle attacks that exploit certificate validation weaknesses, or that operate at the network layer before TLS termination, remain a concern. Cellular-connected devices that communicate with payment processors over the public internet have a larger attack surface than devices on private network paths. This is one of the primary technical arguments for private APN connectivity in payment environments – traffic never reaches the public internet.

Firmware and software compromise

Payment terminal firmware that has been modified – either through a supply chain attack, through exploitation of an update mechanism, or through physical access to the device – can capture card data at the point of entry before encryption, bypass security controls, or establish persistent remote access for the attacker. Firmware integrity verification – checking that the firmware running on a device matches an authorised, signed version – is a requirement under PCI-DSS v4.0.1 and is the primary defence against this attack vector.

Credential attacks on management interfaces

Cellular routers and IoT gateways in payment environments frequently have web-based management interfaces. Default credentials on these devices are well-documented in vendor manuals that are publicly available. A router with a default username and password, a management interface accessible from the internet, and PCI-scope devices behind it is a straightforward compromise waiting to happen. Shodan – a publicly accessible search engine for internet-connected devices – indexes thousands of cellular routers with exposed management interfaces at any given time.

Lateral movement from non-PCI IoT devices

As described above, the initial compromise of a payment environment frequently does not target the payment devices directly. It targets adjacent IoT infrastructure on the same network, uses that foothold to map the internal network, identifies the payment segment, and moves laterally toward the higher-value target. Inadequate network segmentation – or segmentation that exists on paper but has not been validated – is the enabling condition for this attack pattern.

Supply chain and third-party risk

Payment devices pass through multiple hands before reaching their installation location – manufacturer, distributor, installer, and maintenance provider all have physical access to the hardware at various points. A device tampered with in the supply chain may appear legitimate on delivery. PCI-DSS v4.0.1 places increased emphasis on third-party and supply chain risk, requiring documented assessment of service providers and their security controls.

Router and Device Hardening for PCI Environments

Connectivity architecture defines the perimeter. Device hardening defines what happens within it. Every router, gateway, and connected device in or adjacent to a payment environment needs to meet a baseline security configuration before deployment and maintain it throughout its operational life.

Change all default credentials immediately

This is Requirement 2.1 of PCI-DSS and it is non-negotiable. Default usernames and passwords on network hardware are documented in publicly available vendor manuals. Every device must have its default credentials changed before being connected to a live network. Passwords must meet complexity requirements: minimum 12 characters, combination of uppercase, lowercase, numbers, and symbols, no dictionary words, not reused from other accounts.

Disable all unnecessary services

A cellular router running in a payment environment does not need Telnet, FTP, or HTTP management access enabled. It should run HTTPS for management (if web UI is required at all) and SSH for CLI access. All other management protocols should be disabled. Any port that is not required for the device’s operational function should be closed. This applies to every device in the environment – routers, switches, terminals, and any IoT device on the same network segment.

Maintain a firmware update cycle

Firmware vulnerabilities on network hardware are regularly discovered and patched by vendors. A router running firmware from 18 months ago may have known vulnerabilities that have been publicly documented – and therefore known to attackers. Establish a firmware update cycle for all network hardware: subscribe to vendor security advisories, test updates in a non-production environment where possible, and deploy security patches within a defined timeframe from release.

For large fleets of cellular routers, remote firmware management via a platform like Teltonika RMS is the only practical approach. Manual firmware updates across hundreds of remote devices are not operationally viable and will inevitably fall behind.

Enable tamper detection and integrity verification

PCI-DSS v4.0.1 Requirement 9.9 requires that payment terminals are protected from tampering and substitution. Physical controls include anti-tamper seals, device serial number verification, and regular visual inspection of terminals by trained staff. Logical controls include firmware integrity verification – automated checks that confirm the firmware running on a device matches an authorised, signed version – and configuration drift detection, which alerts when device configuration changes from its known-good baseline.

Implement logging on all network devices

Every router, switch, and gateway in or adjacent to the payment environment must have logging enabled and logs must be forwarded to a centralised, tamper-evident log management system. Logs must capture: all authentication attempts (successful and failed), configuration changes, connectivity events (link up/down, failover), and any security control failures. Under PCI-DSS v4.0.1, log review must be automated – manual daily log review is not sufficient for environments with significant log volumes.

Restrict management access by source IP

Management interfaces on network hardware should only be accessible from known, authorised IP addresses – ideally the IP range of a jump server or management network, accessed via VPN. A firewall rule allowing management access from any source is not acceptable in a PCI environment. If the management interface cannot be restricted by source IP at the device level, a network-level firewall rule must enforce this restriction upstream.

Questions to Ask Your Providers

Compliance in a distributed payment environment is a shared responsibility across multiple vendors – POS hardware supplier, payment software provider, acquirer, cellular connectivity provider, and managed service provider. Each has a role in the security posture of the overall environment. These are the questions to ask.

Questions for your POS hardware supplier

Questions for your cellular connectivity provider

Questions for your router and gateway supplier

Questions for your acquirer or payment software provider

Sensible Security for All Connected Devices: Beyond PCI Scope

PCI-DSS scope covers a defined subset of your connected infrastructure – the devices that store, process, or transmit cardholder data, and the network infrastructure that connects them. But the attack vectors described above do not respect PCI scope boundaries. A poorly secured CCTV camera or environmental sensor can be the entry point for a breach that ultimately reaches your payment environment.

The security principles below apply to every connected device in your organisation – not just those in PCI scope.

Maintain a complete device inventory

You cannot secure what you do not know you have. Every connected device – router, gateway, sensor, camera, terminal, building management controller, smart display – should be in a documented inventory with its network address, firmware version, last update date, owner, and physical location. The inventory needs to be maintained actively: devices added without being inventoried are the ones that create security gaps.

Automated network discovery tools can help maintain inventory accuracy, but they need to be run against all network segments – including the cellular-connected segments that may not be visible to a LAN-based discovery tool.

Segment networks by function and risk

Not all IoT devices need to communicate with each other. A temperature sensor does not need network access to your payment terminal. A guest Wi-Fi network does not need access to your operational IoT network. Segment your network by function and apply firewall rules that permit only the specific traffic each segment legitimately requires. The default rule should be deny-all; permitted traffic is explicitly allowed.

In practice, a well-segmented small business or multi-site retail network might have: a payment segment (PCI scope, restricted access), an operational IoT segment (CCTV, access control, environmental monitoring), a staff network (computers, printers, phones), and a guest network (public Wi-Fi, isolated from everything else). None of these should have unrestricted access to any other.

Change default credentials on everything

The single most exploited vulnerability in IoT security is default credentials. Manufacturers ship devices with documented default usernames and passwords because it simplifies initial setup. Every device that retains its default credentials is a device that can be compromised in seconds by anyone who can reach its management interface. This applies to every device without exception – routers, cameras, sensors, printers, smart displays, access controllers. If a device does not support credential changes, it should not be deployed on a network that connects to anything sensitive.

Keep firmware and software current

Vulnerabilities in IoT device firmware are discovered regularly. Most IoT security incidents involving exploitation of known vulnerabilities could have been prevented by applying available patches. Subscribe to security advisories from every vendor whose equipment you operate. Define a maximum time from advisory publication to patch deployment – 30 days for critical vulnerabilities is a reasonable baseline. For devices that cannot be updated remotely, include firmware verification in your physical maintenance schedule.

Disable remote management interfaces you are not actively using

A device with its management interface disabled cannot be remotely compromised through that interface. If you are not actively using remote web management on a device, disable it. Where remote management is required, restrict it to VPN access from known IP addresses. Remote management interfaces exposed directly to the internet – even on ports other than 80 and 443 – are routinely discovered and attacked by automated scanning tools.

Monitor connectivity and behaviour baselines

Establish what normal looks like for each device and each network segment: typical data volumes, connection destinations, active hours, and configuration state. Deviations from baseline – a sensor suddenly transmitting ten times its normal data volume, a router establishing connections to an unexpected IP address, a device active outside its normal operational window – are indicators of potential compromise that should trigger investigation.

For cellular-connected devices, per-SIM usage monitoring from your connectivity provider gives you the data needed to detect anomalous behaviour at the network level. For LAN-connected devices, network monitoring tools providing flow analysis and anomaly detection serve the same purpose.

Have and test an incident response plan

When a security incident occurs, the decisions that matter most are made in the first hour. Who is notified? Who has authority to isolate a network segment? Who contacts the payment processor? Who engages external forensic support? Who handles communications to customers, regulators, and card schemes? These decisions should be documented, assigned, and rehearsed before an incident occurs – not worked out under pressure while an active breach is in progress.

Test your incident response plan at least annually with a tabletop exercise. Walk through realistic scenarios: a payment terminal that has been tampered with, a router with an unknown configuration change, a SIM transmitting data to an unexpected destination. Identify the gaps in your response process before an attacker finds them for you.

Maintaining Business as Normal: Continuity Under Security Controls

Security controls and operational continuity are not inherently in conflict, but poorly implemented security can create operational disruption that undermines adoption and maintenance of those controls. The goal is a security architecture that is operationally transparent in normal operation and provides clear, fast response paths when something goes wrong.

Design for graceful degradation

If your primary connectivity fails, your payment environment should have a defined, secure fallback mode. Dual-SIM cellular routers with automatic failover maintain connectivity through single-MNO outages without any operational disruption. If all cellular connectivity fails, define what happens: does the terminal queue transactions for later submission, switch to a backup fixed broadband connection, or suspend card acceptance and switch to alternative payment methods? The answer should be documented and tested, not discovered during an actual outage.

Remote management reduces response time

A centralised remote management platform – covering all routers, gateways, and network devices – means that a configuration issue at a remote site can be diagnosed and resolved without dispatching an engineer. For a multi-site payment environment, this is the difference between a 20-minute remote fix and a four-hour site visit. Platforms like Teltonika RMS provide the remote CLI access, configuration management, and health monitoring needed for this capability across a fleet of cellular routers.

Security events should not require physical response as the first step

If a security event – a failed authentication attempt, a configuration change alert, a connectivity anomaly – requires an engineer to visit the site to investigate, your response time is measured in hours or days. Logging and monitoring infrastructure should provide enough remote visibility to triage security events and determine whether physical response is actually needed. In most cases, remote investigation and remediation should be possible for the common security event types.

Staff training is a security control

The human layer is part of the security architecture. Staff who handle payment terminals need to know what tampered devices look like and what to do if they suspect one. Staff who receive calls from people claiming to be from the payment provider or IT support need to know that legitimate providers do not ask for credentials over the phone. PCI-DSS v4.0.1 requires security awareness training for all personnel, including role-specific training for those with payment security responsibilities. This is not a compliance checkbox – it is one of the most cost-effective security controls available.