If anyone in your company logs in to a desktop machine "from home using an IP number" — meaning someone in IT once opened port 3389 on the router — you don't have remote work. You have a save-the-date for ransomware, sent two years in advance.
This isn't fearmongering. It's a statistic we see in client environments every few months. RDP exposed on a public IP has for years been the number one entry vector for attackers hitting Polish SMEs. Not phishing, not a USB stick — RDP. And not because someone uses the password Summer2024!. Simply because legions of bots scan the internet 24/7 for open port 3389 and try every credential that ever leaked.
This article is about what sensible remote access looks like today for a 10–50-person company. Without enterprise-grade overkill, without downplaying the risk.
Where the public-IP RDP came from
The pattern is almost always the same. The company bought a Dell or HP server 10–15 years ago, put Windows Server on it, installed an ERP (most often Comarch Optima or Subiekt GT, sometimes an older enova). A handful of people in finance and sales logged in via RDP. For years it just worked.
Then covid arrived, or the sales lead's first child arrived, and suddenly people needed to log in from home. The IT person — internal or external — asked about budget, heard "minimal", so they opened port 3389 on the router and showed everyone how to type companyname.dyndns.org:3389 into the RDP client. Everything worked. For three years everything worked.
Until one Saturday morning nobody can open any file, because every file now ends in .lockbit3 or .akira. The mandatory path then is backups (if they exist) and five days of downtime.
What's actually wrong with this
The problem isn't that RDP is a bad protocol. Microsoft actively maintains it, it's encrypted. The problem is three things:
- Public exposure of the authentication session. Every bot in the world can attempt to log in. Even if you have long passwords and accounts that lock after 10 attempts, credential stuffing attacks (logins leaked from other services) routinely bypass such guardrails.
- Direct access to the OS layer. Once an attacker is in, they're sitting on the server that hosts the ERP, the database, the file shares. There's no intermediate layer to slow down lateral movement.
- No MFA as standard. Plain RDP doesn't require a second factor. You can bolt one on (Duo, Azure MFA for RDP), but in 9 out of 10 client environments we look at, nobody has.
For contrast — when someone logs in through a proper VPN or ZTNA, they first authenticate to a gateway (with MFA), and only then see anything from the internal network. That's two completely different leagues of risk.
Three paths that make sense for SMEs
There isn't one right answer. There are three, with different cost, complexity and user-experience profiles.
Path 1 — classic VPN on the router/firewall. Most often WireGuard or OpenVPN running on a decent edge router (Mikrotik, Fortigate, Sophos, pfSense, OPNsense). The user connects a VPN client, gets an internal IP, uses the company "as if they were sitting in the office". Cheap, proven, fully under your control. Requires discipline around account and key management — especially when people leave.
Path 2 — ZTNA / mesh VPN (Tailscale, Cloudflare WARP, Twingate). A newer approach where you expose no port to the world at all. Each device connects out to the provider, authenticates through your company identity (Microsoft 365 / Google Workspace), and only then gets access to specific resources. Configuration is simpler than classic VPN, MFA is "free" via the IdP. Cost is typically USD 5–8 per user per month.
Path 3 — RD Gateway + MFA. If for various reasons you must stay on RDP (e.g. a legacy program needs a specific session setup), put a Remote Desktop Gateway in front of the server and enforce MFA. Port 3389 stays closed; users connect to port 443 with a TLS certificate. This is the minimum decency if RDP has to stay.
For most 10–50-person companies we build from scratch today, we go with Path 2 or Path 1. Path 3 makes sense mainly where the existing infrastructure has to stay and the change has to be surgical.
A real example
At one of our clients — a 28-person electrical wholesaler using Comarch Optima and a couple of warehouse apps — the starting situation was textbook. The server in the cupboard-under-the-stairs, port 3389 open with a dyndns name, ten people logging in "from home on Fridays", passwords last changed in 2021.
After the break-in (LockBit, weekend, everything encrypted) recovery took 6 days, of which for the first 36 hours the company didn't know whether the backup was usable — copies were taken locally to a second disk in the same server, the offsite copy on a NAS in the office, which the attackers also encrypted. Direct losses (lost margins, labour, restore costs, one customer who left) landed at around PLN 180,000.
The rebuild after the incident cost less. Closing port 3389, deploying Tailscale authenticated via Microsoft 365 with enforced MFA, a 3-2-1 backup with one immutable offsite copy — the whole package came to PLN 17,000 for project work plus a first-year subscription cost of about PLN 6,000. Implementation time: 9 working days, including a week of smoothly moving users to the new login flow.
This could have been done a year earlier. It would still have paid back — just without learning through pain.
What concretely to do next week
Whichever path you pick in the end, these steps you can do straight away:
- Inventory what's exposed to the world. Check from the outside (e.g.
shodan.ioagainst the company's public IP, or a simple port scan) whether 3389, 5900 (VNC), 22 (SSH) are showing. If they are — turn them off tonight. - Map who logs in remotely and how. Do you have a list? Do you know what they actually do — just the office app? A file? The whole server? That's the first step toward sane restriction.
- Turn on MFA everywhere you can. Microsoft 365, Google Workspace, cloud ERP, the bank. That's 80% of the protection for 5% of the cost.
- Test the backup our way — by restoring something, not by reading a green icon. If you've never restored a document from the backup, you don't know if you have one.
If this sounds like the conversation worth having before rather than after, we can start it on a thirty-minute call, with no promises that you'll "buy something from us".
RDP on a public IP isn't a "frugal solution" today. It's debt that you'll repay sooner or later, at a very inconvenient moment.