Remote Access and Card Terminals: the Do's and Don'ts

Being able to log into the till system from home is genuinely useful. It saves your IT supplier a drive across the county, it gets a broken price file fixed before opening, and it means a software update does not need somebody standing at the counter. It is also, consistently, one of the most reliable ways attackers get into a small business's payment environment — not by defeating the remote access tool, but by walking through it using a password somebody reused. This guide covers the habits that make remote support safe, and the ones that quietly undo everything else you have done. For the broader picture, start with our complete PCI DSS compliance guide.

Why is remote access such a common way in?

Three reasons, and they compound. It is deliberately reachable from the internet, because that is the point of it. It usually runs with high privileges, because support work needs them. And it is very often left switched on between jobs, because turning it off means a phone call next time. An always-on, internet-facing, administrator-level door is exactly what an attacker scanning the internet is hoping to find.

Add the human factor and it gets worse. Remote access credentials are frequently shared between an IT provider's engineers, sometimes reused across every client that provider supports, and rarely changed when someone leaves. A single compromised support account can therefore open a great many businesses at once — which is why this route is worth attacking in the first place.

What should you do?

• Turn it on for the job, then off again. Remote access that exists only while work is happening cannot be found by somebody scanning at three in the morning.
• Require multi-factor authentication on every remote connection, without exception — this single control defeats the overwhelming majority of these attacks.
• Give every engineer their own named account. Shared logins destroy accountability and survive staff changes at the supplier.
• Keep the remote access software itself patched. It is security software with administrative reach; an out-of-date version is a serious exposure.
• Log the sessions and look at the log occasionally — who connected, when, and for how long.
• Agree in writing with your supplier what they may access, and how they will tell you when their staff change.
• Separate the payment environment from everything else on your network, so a compromise of the office Wi-Fi does not lead straight to the till.

What should you never do?

• Leave remote access enabled permanently 'because it is easier'. This is the single most common finding and the most consequential.
• Use the credentials the system shipped with, or a password that also opens something else.
• Share one login between your team and your supplier's team.
• Browse the web or read email on the machine that processes payments. A till is a payment device, not a computer that also takes payments.
• Let the payment system share a flat network with the guest Wi-Fi, the CCTV recorder or a smart device somebody plugged in.
• Assume your supplier has handled security because they installed it. Their obligations are whatever your contract says they are.

What does PCI DSS require here?

The standard is explicit about multi-factor authentication. Under PCI DSS v4.x, multi-factor authentication is required for all remote network access originating from outside your network that could reach the cardholder data environment — and, separately, for all non-console access into the cardholder data environment, including from inside your own network. That second obligation was one of the changes businesses felt most when the remaining v4 requirements became mandatory in March 2025, because it removed the old assumption that being on the office network was itself sufficient proof of identity.

The standard also expects accounts used by third parties for support to be enabled only during the period needed and disabled when not in use, and monitored while active. In other words, the 'switch it on for the job' habit is not merely good practice — it is close to a literal restatement of what the standard asks. For how this fits alongside the rest of your network controls, see our guide to network security controls under PCI DSS v4.

Do you need network segmentation?

Segmentation means separating the systems that handle card payments from the rest of your network, so that the two cannot freely talk to each other. Strictly speaking it is not mandatory — you can be compliant with one flat network. But then everything on that network is in scope, which means every device, every laptop and every smart plug has to meet the standard. That is a much bigger job than putting the payment systems on their own segment.

For a small business, sensible segmentation is usually straightforward and cheap: guest Wi-Fi on its own network with no route to anything internal, payment devices separated from general office computers, and cameras, digital signage and other connected equipment kept away from both. If you already have a business-grade router, you may be able to do most of this with the equipment you own.

Is your POS doing things it should not?

A payment system should do one job. In practice, tills acquire browsers, email clients, music streaming, social media and the occasional game, because the screen is there and the shift is quiet. Every one of those is a route for malware to arrive on the device that handles card transactions, and none of them belong there. The fix is a rule everybody understands — this machine processes payments and nothing else — plus, where the system supports it, removing the software that makes anything else possible.

The same logic applies to what the POS is allowed to reach. It needs to talk to your payment provider; it does not need to reach the whole internet. Restricting outbound connections to what the system genuinely requires is one of the highest-value changes a small business can make, and it is one of the areas PCI DSS v4.0.1 tightened.

Your supplier's access is your risk

If an incident starts through your IT provider's remote access account, it is still your breach, your customers and your acquirer's questions. PCI DSS reflects that: you are expected to keep a list of the third parties with access to your card environment, to have written agreements covering their responsibilities, and to monitor their compliance status rather than assume it.

None of this needs to be adversarial. A good supplier will already use individual accounts and multi-factor authentication and will be happy to confirm it. A supplier who cannot tell you which of their engineers has access to your systems, or who asks you to leave a permanent connection open with a shared password, has told you something important about how they work.

Key takeaways

• Remote access left permanently on is the most common and most damaging finding in this area — enable it for the job, then disable it.
• Multi-factor authentication is required under v4.x for remote access and for all access into the cardholder data environment; it is also the control that stops most of these attacks outright.
• Individual named accounts for every engineer, never a shared support login.
• Segmentation is not mandatory, but without it your whole network is in scope — which is usually the more expensive option.
• Your payment device should process payments and nothing else, and reach your provider rather than the open internet.

Working out which of these controls actually apply to your setup — and which your provider already covers — is the part most businesses find hardest. Fraud Defence First's fully managed PCI compliance service maps your payment environment, identifies what is genuinely in scope, completes the right questionnaire with you and files it with your acquirer, for a flat £100 + VAT a year.