Internet-wide scanning company Censys published its 2026 FTP Exposure Brief earlier this year, and the headline number is stark: roughly 5.95 million internet-facing FTP servers are still reachable from the open internet. The number is down 40% from the 10.1 million Censys counted in 2024, but it is still nearly six million systems handling files, credentials, and in some cases regulated data, over a protocol with no encryption at all.
If you manage any kind of file transfer infrastructure, the report is worth twenty minutes of your time. Here is what it found, and what to actually do about it.
What Censys Found
Of those ~5.95 million exposed hosts, about 58.9% (roughly 3.5 million) completed a TLS handshake — meaning the rest, an estimated 2.45 million servers, showed no evidence of encryption at all. Plain FTP, on the open internet, in 2026.
Encryption quality varies sharply by region. Hong Kong (87%) and Poland (84%) lead on TLS adoption; the United States sits at 74%. South Korea (14.5%) and mainland China (17.9%) lag far behind. Even where TLS is present, it is not always current: Censys found 115,268 services still running deprecated TLS 1.0 or 1.1, and 71% of those were in Japan.
By country, exposure is led by the United States (1.2 million hosts, 21% of the global total), followed by China (14.6%), Germany (7.9%), Hong Kong (7.0%), and Japan (6.2%). By hosting provider, China Unicom, Alibaba, OVH, Hetzner, and KDDI Web Communications carry the largest shares.
One finding stands out as a genuine gotcha rather than neglect: on a fresh Microsoft IIS FTP install, the controlChannelPolicy defaults to requiring SSL — but no certificate is bound by default. The result is a server that appears to enforce encryption but actually can’t complete a secure connection at all. Censys found 174,298 services returning this exact failure mode, 89% of them running IIS.
Fixing it does not require budget or a procurement process. Let’s Encrypt has issued free, automatable domain-validated TLS certificates since 2015, and tools like win-acme handle the IIS binding step directlym the whole fix is closer to fifteen minutes than a line item. That is about as low as the barrier to entry gets, which says more about how invisible these defaults are to the teams running them than about cost or difficulty.
Why This Isn’t Really About Zero-Days
The report’s own framing is the most useful part: “The dominant story of FTP exposure in 2026 is not purpose-built file transfer infrastructure, it is an accumulation of platform defaults.” In other words, most of what Censys found is not a team that deliberately chose to run insecure FTP, it is a hosting control panel’s default FTP daemon nobody turned off, or a server role that was enabled once for a one-time file drop and never revisited.
That’s actually the encouraging part. A misconfigured default is fixable in an afternoon. A determined attacker exploiting a fresh CVE is a different, harder problem — and this data says the bigger risk to most organizations is the boring one: something running, unencrypted or under-configured, that nobody remembers is there.
Censys puts it plainly: “If FTP is showing up in your asset inventory, the first question is not how to harden it, it is whether it should be running at all.”
A Practical Checklist
- Find it first. Check your own asset inventory (or run an external scan) for anything listening on port 21 or common FTP alt-ports — Censys found meaningful volume on non-standard ports like 2121 and 10397, so do not assume “we do not run FTP” without checking.
- Ask whether it needs to exist. If a plain-FTP listener is a leftover from a hosting control panel default and nothing actually uses it, disable it rather than trying to secure it.
- If it is needed, move to FTPS or SFTP. Both encrypt the credentials and the data in transit; plain FTP encrypts neither.
- Check your TLS version, not just whether TLS is “on.” TLS 1.0 and 1.1 are deprecated for a reason — confirm your server is negotiating 1.2 or 1.3.
- Do not trust a default install to have a certificate bound. As the IIS finding shows, a server can look like it is enforcing encryption while actually being unable to complete a secure handshake at all — verify with an actual test connection, not just a config flag.
- Re-scan periodically. Exposure like this accumulates quietly over time as services get stood up and forgotten; a one-time cleanup won’t stay clean on its own.
Where FileZilla Pro Fits
FileZilla Pro Client and FileZilla Pro Enterprise Server both support FTPS and SFTP with modern TLS out of the box. If part of your cleanup is standardizing how your team connects to servers, that consolidation is worth doing at the same time as the protocol migration, not as a separate project later.
For organizations that need to show a security review or vendor questionnaire that the tooling itself is held to an audited standard, Business Follows srl — the company behind FileZilla Pro — holds ISO/IEC 27001:2022 certification for its information security management system, covering the design, development, support, and sale of the FileZilla Pro product line.
Don’t Let Your Server Be the Next Exposed One
The free FileZilla Server supports FTP and FTPS only; FileZilla Pro Enterprise Server adds SFTP and is administered through a dedicated app, not a default install with an unbound certificate waiting to be found by the next internet-wide scan. It’s also backed by an ISO/IEC 27001:2022-certified ISMS, so the fix is something you can cite in a security review, not just make quietly.