The PCI Security Standards Council's latest small business entry targets a familiar villain: unsecured remote access. According to the Council, it remains one of the leading causes of payment data breaches, and the fix is mostly about discipline rather than new tools.
For a small merchant, remote access usually means a vendor — a POS provider, a payment processor, an IT contractor — reaching into the network from somewhere else. That convenience is also the door attackers walk through.
Key facts
- The Council is running a back-to-basics SMB series; this installment focuses on remote access.
- Unsecured remote access is named as one of the top causes of information compromises for small businesses.
- Many POS and payment vendors keep remote access tools always on, reachable from the public internet.
- Default or shared credentials on remote access tools are a common breach pattern.
- The Council's prescription: enable remote access only when needed, demand MFA, and require unique credentials per customer.
Why remote access keeps ending in incident reports
The typical setup is a remote support tool that is always on, always reachable, and protected by a password the installer set years ago. Attackers scan the internet for exactly this footprint. Once they are in, they pivot to the POS or the payment host and exfiltrate card data over the same remote access channel the vendor uses.
The Council's framing is direct. You, the merchant, own the risk. The vendor may be a well-known brand, but the connection is on your network and the data is your liability.
The Council's three rules
First, restrict when remote access is allowed. Ask each provider how to enable remote access on demand, and how to disable it when the work is done. If the only answer is "it stays on," that is itself a finding.
Second, require multi-factor authentication for any remote session. Username and password alone is not enough. Add a smart card, a hardware token, a one-time code from an authenticator app — anything that means a stolen password is not the whole key.
Third, require credentials that are unique to your business. Shared credentials that the same vendor uses across hundreds of customers are a single breach away from being in every one of those customers' networks. Each merchant should have its own access identity.
Our analysis
The trade-off here is operational, not financial. Vendors resist enabling and disabling per session because it adds friction to support calls. The fix is to write the requirement into the contract, not leave it to the support ticket. Compared with the SMB norm — always-on tools, default passwords, shared credentials — the Council's three rules represent a meaningful uplift in attacker cost.
Who benefits: the merchant, the vendor's other customers, and the acquirer who has to sign off on compliance. Who loses: attackers and the small number of vendors whose support model depends on the door staying open. Watch for vendors who cannot scope access per merchant — that limitation is a security finding regardless of how polished the rest of their stack looks.
A worked example: tightening the vendor's hand on the keyboard
Say your POS vendor wants remote access for routine maintenance. Currently, they can connect any time, and the password has never been changed. This week, you change the password to a unique value, store it in a password manager shared with one internal owner, and require the vendor to start sessions through a jump host with MFA. You add a calendar entry: every Friday, remote access is reviewed and disabled until needed.
The first month is mildly annoying. The second month, it is invisible. The third month, you have an audit trail that survives a card brand inquiry.
What to watch next
Watch how your vendors respond when you ask for per-merchant credentials and MFA. The meaningful signal is not the price quote but the speed and clarity of the security answer. Bottom line: if remote access is always on with shared passwords, you are not a customer, you are a soft target.
Key takeaways
- Treat remote access as an on-demand capability, not a default state.
- Require multi-factor authentication on every remote session.
- Ensure every vendor uses credentials unique to your business.
- Document the enable/disable process and review it on a schedule.
Frequently asked questions
What is the most common remote access weakness at small merchants?
Always-on remote support tools protected by default or shared passwords that the vendor uses across many customers.
Is multi-factor authentication really necessary for vendor support sessions?
Yes. Passwords alone are routinely phished or stolen, and vendor accounts are a high-value target.
Can I turn remote access off completely?
In many cases, yes, by scheduling support windows and requiring on-demand enablement. Some integrations genuinely need persistent access, but most do not.
How do I know if a vendor uses shared credentials?
Ask directly. A mature vendor will scope access per customer and provide named accounts. A vague answer is a finding.