Executive Summary
- As of April 2026, Censys observes just under 6 million hosts (~5,949,954) running at least one Internet-facing FTP service. This is down from over 10.1 million in 2024, which is a decline of 40% in two years.
- ~58.9% of FTP hosts had at least one FTP service where Censys observed a completed TLS handshake. The remaining ~2.45 million hosts had no observed TLS handshake on any FTP service, meaning those servers either refused the upgrade, didn’t support it, or were not observed completing one during scanning. This is not a guarantee that all 2.45 million transmit files and credentials in cleartext, but it is the population with no observed evidence of encryption.
- TLS adoption varies by region: mainland China (17.9%) and South Korea (14.5%) show the lowest rates among the top 10 countries hosting FTP, driven primarily by residential ISP and legacy hosting footprints. Japan accounts for 71% of all FTP servers running legacy TLS (TLSv1.0/1.1) globally, likely attributable to hosting operators like KDDI and NTT running older stacks.
- Over 150,000 IIS FTP services return a 534 response, indicating TLS was never set up. IIS FTP’s controlChannelPolicy defaults to SslRequire, but serverCertHash has no default value, meaning no certificate is bound on a fresh install and TLS cannot negotiate. The server accepts cleartext while the configuration appears to require encryption.
- The dominant story of FTP exposure in 2026 is not purpose-built file transfer infrastructure, it is an accumulation of platform defaults. The top ASNs with exposure are big shared hosting networks and broadband providers. The most common daemons are whatever those platforms shipped. The typical Internet-facing FTP server is running alongside mail services, databases, and web hosting.
- If FTP is showing up in your asset inventory, the first question isn’t how to harden it, it’s whether it should be running at all. Use a more secure alternative.
Why FTP Is Still Worth Writing About
It’s the 1990s. You probably use FTP to push website files. Your users use it to grab new software releases. You run wu-ftpd or ProFTPD and think mostly about disk quotas, not encryption. AUTH TLS doesn’t exist yet (RFC 2228 wouldn’t arrive until 1997), and the concept of sending credentials or files in cleartext doesn’t matter so much since the Internet is smaller and less adversarial. FTP was designed for a world where every node on a network was probably going to be a university server or a government computer that you more or less trusted automatically.
Of course, decades later, the Internet is a much different place.
FTP is worth writing about in 2026 precisely because it is boring. It is not a novel attack surface, not a recently disclosed vulnerability, and not the kind of protocol that shows up in threat actor TTPs with any particular frequency. It is infrastructure that predates the web and runs quietly in the background of millions of hosting stacks.
As of April 2026, Censys observes roughly 5.94 million Internet-facing hosts with FTP services visible to our scanners. The interesting question is not whether FTP has problems (it does, and they are well-understood) but how many of those problems seem like structural defaults, and what the actual configuration posture of those servers looks like when you measure it. That is what this piece is about.
FTP and Its Relatives
The first question worth asking about any protocol is whether it’s encrypted, and for FTP, the answer is “sometimes, and it depends on which implementation you’re looking at.”
FTP, FTPS, SFTP, and TFTP are four distinct protocols with different designs, different security properties, and different deployment contexts.The ~5.94 million FTP servers we’re describing here consist of FTP and its encrypted variants; SFTP and TFTP are separate protocol populations entirely.
FTP is the baseline: a two-channel TCP protocol (one for control, one for data) that transmits everything in cleartext. It was designed for reliability and interoperability, not security.
FTPS (FTP Secure) is FTP with TLS bolted on, and it comes in two flavors, explicit and implicit:
- Explicit FTPS (sometimes called FTPES) starts as a regular FTP connection on port 21 and upgrades to TLS via the AUTH TLS command.
- Implicit FTPS wraps the entire connection in TLS from the start, typically on port 990. It is deprecated and is largely out of use.
SFTP (SSH File Transfer Protocol) is not FTP at all, despite the name. It’s basically a subsystem of SSH, runs over a single encrypted channel on port 22, and shares no protocol heritage with FTP. The naming overlap is a historical accident that has caused significant confusion for decades. SFTP is generally the right answer when someone asks “how do I replace FTP with something secure?” because it runs on infrastructure most organizations already have (SSH), requires no firewall exceptions for a data channel, and encrypts both credentials and data by default. We’re not going to discuss it in this particular analysis.
Some side trivia: there is another SFTP that stands for Simple File Transfer Protocol, a historic protocol which actually got the abbreviation first. It was proposed in 1984 as an unsecured file transfer protocol over port 115 but was never widely implemented.
TFTP (Trivial File Transfer Protocol) is the stripped-down sibling of FTP but is essentially a different protocol entirely. It has no authentication, no encryption, is UDP-based, and is designed for environments where simplicity matters more than security. This is usually network devices that use TFTP for configuration management. It should never be Internet-facing, and yet Censys currently observes it on over 68,000 public hosts. However, that is a separate exposure topic, and we’ll focus on FTP in this analysis.
SFTP is the default recommendation for interactive and scripted transfers, but FTPS is a reasonable intermediate step if you have existing FTP infrastructure that you can’t immediately replace.
FTP Exposure Is Declining (Slowly)
The exposure of Internet-facing FTP hosts declined by 40% over the past two years, from over 10.1 million hosts in April 2024 to just under 6 million today.
It’s worth noting how the Internet at large changed in that time: the total number of hosts Censys saw across the Internet shrank by roughly 16% over the same period, from approximately 268 million to 224 million. However, the drop in FTP is still significant. Its share of all Internet-visible hosts dropped from 3.80% to 2.72%.
The most likely explanation for this decline is a combination of forces. SFTP has become the recommended default in most modern tooling, and the rise of object storage (S3-compatible APIs, cloud buckets) has eliminated the use case for FTP entirely in a large share of environments where it would historically have been the answer.
The hosts that remain are plausibly the ones where none of those forcing functions have applied yet: legacy shared hosting stacks, ISP-managed CPE, and long-running VPS images where FTP was provisioned once and still works. That is not inherently a problem. FTP being Internet-facing is not the concern: FTP being Internet-facing with default configurations that accept cleartext credentials is.
Either way, a 40% decline in two years means a lot of FTP was turned off somewhere.
Geography and Infrastructure
The distribution of where FTP is hosted tells us something useful about what kind of infrastructure we’re actually looking at.
The United States leads with just over 1.2 million FTP-visible hosts (~21%), followed by China (~14.6%), Germany (~7.9%), Hong Kong (~7.0%), and Japan (~6.2%). Those top five countries account for more than half of all FTP hosts globally.
China Unicom’s CHINA169 backbone alone accounts for roughly 405,000 FTP hosts (~6.8% of the global total), followed by Alibaba (~227,000), OVH (~177,000), Hetzner (~138,000), KDDI Web Communications (~127,000), and GoDaddy (~126,000).
That these are some of the largest hosting and broadband providers in the world is not surprising, but it does mean that the security posture of the world’s FTP servers is likely heavily influenced by the default configurations of a small number of large operators.
Meet the Daemons
An FTP daemon is the server-side process that handles incoming FTP connections and manages authentication. Different daemons have different default configurations and different typical deployment contexts. A Pure-FTPd instance provisioned by cPanel is more likely to have TLS enabled as a function of the panel’s configuration. An instance on an unmanaged VPS image is less likely to. It is a reasonable starting point for prioritizing which FTP hosts in your inventory are most likely to warrant closer review.
Pure-FTPd is the most commonly running FTP server by far, appearing on approximately 1.99 million services (about a third of all FTP services globally). ProFTPD follows with 812,000 services.
This is likely a function of the popularity of cPanel, the industry standard for web hosting control panel software. cPanel offers Pure-FTPd and ProFTPD as its default FTP server options on Linux.
The next most popular is vsftpd (~379,000 services), the standard FTP daemon shipped with most major Linux distributions and common in embedded device firmware. Its presence is less a deliberate choice than a system default that comes with the operating environment.
Back in 2011, vsftpd was hit with one of the earlier high-profile supply chain compromises on record: a backdoored version of vsftpd 2.3.4 was distributed via the official SourceForge mirror for a window of roughly three days, between June 30 and July 3. Any installation pulled from that mirror during that window contained code that would open a root shell on port 6200/TCP when a username containing the string :) was sent during the login sequence, tracked as CVE-2011-2523. Censys observes 1,744 Internet-facing hosts still running vsftpd 2.3.4, not all of which are necessarily running the backdoored build, since the malicious tarball affected only a narrow distribution window, but these still warrant investigation. Fifteen years of patch debt on an Internet-facing FTP server is alarming regardless of whether the backdoor specifically is present.
IIS (Internet Information Services) (~259,000 services) is Microsoft’s legacy web and FTP server platform, first shipped with Windows NT 3.51 in 1995 and now bundled as a built-in Windows Server role. Its FTP component has been part of that bundle ever since, which means any Windows Server deployment that enables the FTP role is running IIS FTP by default. Its presence in this dataset is largely a reflection of Windows hosting providers in China, the United States, and Hong Kong.
FileZilla Server (~184,000 services) has a different profile from the others: it is primarily a Windows daemon with a GUI configuration interface, more commonly found in SMB environments and self-managed servers than in large-scale hosting infrastructure. Where vsftpd and IIS FTP tend to appear as provisioned defaults, FileZilla is more often a deliberate installation choice by an administrator who wanted a graphical FTP management tool.
A few entries in the long tail are worth noting.
Multicraft is the built-in FTP server that comes with Minecraft. It appears on ~20,000 FTP services, of which 97.5% were observed completing a TLS handshake. This is another reminder that “FTP service” in this context includes a wide variety of applications that happen to speak FTP, not just traditional file servers, and that some of those applications have apparently done a better job of TLS provisioning than the traditional Unix daemons At the opposite extreme, bftpd appears on ~51,000 services with an observed TLS rate of 0.02% — effectively eight hosts in the entire dataset. bftpd is a minimal Unix FTP daemon designed to work out of the box with little to no configuration.
A few archaic implementations also linger. 10 hosts were observed running IBM’s z/OS FTP server, a mainframe FTP implementation that has shipped as part of z/OS Communications Server since at least the 1980s.
If cPanel or a similar hosting control panel is in your environment, there is a meaningful probability that FTP was enabled at provisioning time and has been running since, whether intentionally or unintentionally. This configuration is worth checking.
The Good News: Most FTP Uses Encryption
The good news is that 58.9% of FTP hosts (approximately 3.5 million) had at least one FTP service where Censys observed a completed TLS handshake on the control channel. This is a higher percentage than most practitioners would expect.
97% of these are using up-to-date versions, meaning TLSv1.3 or TLSv1.2.
The remaining ~3.3% (115,268 services) are still negotiating TLSv1.0 or TLSv1.1, both deprecated since 2021. Japan accounts for roughly 71% of that legacy TLS volume (81,822 services), concentrated in KDDI hosting infrastructure and NTT-affiliated business networks.
Implicit FTPS, also deprecated, is also a shrinking population, only running on 65,590 hosts (~1.1% of total). It’s worth noting that 66% of these also run explicit TLS on a different port on the same host – they’re likely just supporting implicit TLS to maintain compatibility with legacy systems rather than as a main configuration choice. The fact that it’s overall so rare suggests the ecosystem has largely moved on, which is the right direction.
There are some interesting regional differences in TLS adoption. Hong Kong leads at 87% of FTP hosts completing a successful negotiation, followed by Poland at 84%. The United States is at 74%.
The outliers are mainland China (17.9%) and South Korea (14.5%). This means over 80% of FTP hosts there show no observed TLS negotiation on any FTP service.
A possible explanation for this is in configuration defaults for the most popular daemons and platforms used in these regions. China’s FTP footprint is heavily concentrated in Alibaba Cloud and China Unicom, where Windows Server VMs running IIS FTP (which defaults to TLS disabled) and vsftpd deployments on Linux hosting images are both common. South Korea’s concentration in Korea Telecom residential infrastructure points toward consumer CPE and small hosting stacks where TLS was maybe never configured. These are the same default-configuration problems visible in these platforms in the global dataset, probably just geographically concentrated in ways that reflect those providers’ platform choices.
2.35 Million FTP Services With No Evidence of TLS
For the remaining ~41% of hosts, no TLS handshake completed on any FTP service during scanning. To be precise about what that means: those hosts are not necessarily transmitting credentials in cleartext. A daemon could support TLS but fail to negotiate it with our scanner for reasons unrelated to its configuration. What the absence of an observed handshake does mean is that there is no recorded evidence of encryption, and the data about what each service actually returned when AUTH TLS was issued gives a more granular picture of why.
The largest group is the 530 response (“Please login with USER and PASS”). This means the server wants credentials before negotiating anything, which is arguably backwards from a security standpoint since it asks for a password before the encrypted channel that would protect it exists. But it does not definitively mean TLS is not supported on that server. Whether those hosts could negotiate TLS with a different client flow is not determinable from scan data alone. What is determinable is that a client that completes the connection could potentially send credentials in cleartext. However, a well-configured client set to require explicit TLS will typically see the 530, abort, and not proceed.
The 500-family responses are more varied. About 994,000 services returned a 500 code (“AUTH not understood”, “’AUTH TLS’: command not understood”, or “This security scheme is not implemented”), indicating servers that do not implement AUTH TLS on the scanned control port. Combined with 502 (“SSL/TLS authentication not allowed”, observed on 67,000 services) and 504 (“Command not implemented for that parameter” ~106,000 services), these are FTP implementations that either were never built with explicit TLS support or have it disabled at the build or configuration level.
Enabling TLS on an FTP daemon and enforcing it are two different configurations. A daemon that supports AUTH TLS but does not explicitly refuse cleartext sessions will accept both, meaning credentials can still travel unencrypted depending on what the client requests. The auth_tls_response field in Censys data shows what each service returned when asked to negotiate TLS.
IIS FTP and the 534 AUTH_TLS Response
The 534 response (“Local policy on server does not allow TLS secure connections”) is the most unambiguous signal in this dataset: 174,298 services return it, and 89% of them are running Microsoft IIS FTP. Understanding what is actually happening here requires a small, wonderful detour into IIS FTP’s configuration model, because the default behavior is less straightforward than it appears.
IIS FTP’s controlChannelPolicy attribute carries a schema default of SslRequire, which on its face suggests TLS is required out of the box. It is not. The serverCertHash attribute, which specifies the certificate bound to the FTP site, has no default value, meaning no certificate is bound on a fresh installation. Without a bound certificate, TLS cannot be negotiated regardless of what controlChannelPolicy says, and IIS responds with 534 when a client issues AUTH TLS.
The practical outcome of this is a server that accepts cleartext credentials while appearing, at the configuration level, to require encryption. An administrator reviewing controlChannelPolicy = SslRequire without also checking serverCertHash could reasonably conclude TLS enforcement is in place when it is not. Fixing this requires obtaining or generating a certificate, binding it to the FTP site in IIS Manager, and then verifying the SSL policy is configured appropriately.
This is a bit different from how other major daemons handle the same setup. vsftpd sets ssl_enable to NO by default.
Pure-FTPd’s man page documents -Y 0 as the default, which explicitly disables SSL/TLS.
ProFTPD’s TLSRequired directive defaults to off; without it, both TLS and non-TLS connections are accepted.
In all three cases the default is clearly stated: TLS is off. IIS FTP’s default is functionally the same outcome but configured in a way that may be easier to misread.
The one thing IIS FTP does better in this situation is transparency toward the network. Unlike daemons that silently accept cleartext without any indication that TLS was attempted and refused, the 534 response is an explicit advertisement of the server’s posture. That is a useful signal for anyone scanning infrastructure from the outside.
The geographic distribution confirms where Windows Server hosting is concentrated. China accounts for 35.7% of 534-returning hosts, the United States for 12.9%, and Hong Kong for 7.4%. This is consistent with a large footprint of Windows Server VMs on Chinese cloud infrastructure running IIS FTP without TLS.
If IIS FTP is running anywhere in your fleet, check serverCertHash first. If it’s empty, it’s recommended to verify the SSL policy is set to enforce TLS once a certificate is in place.
What’s Running on Nonstandard Ports?
About 94.7% of FTP services in this dataset use port 21, 20, or 990. The remaining are distributed across a tail of nonstandard ports, and the topology of that tail clusters by geography, provider, and device class in ways that reveal distinct deployment stories.
Port 10397 is the largest nonstandard FTP port by service count (~57,000 services) and is essentially a single-provider phenomenon: 100% of services on this port belong to KDDI Web Communications (CPI-NET), a major Japanese telecom operation. This is KDDI’s shared hosting FTP product line.
Port 2121 (~53,000 services) is more heterogeneous: Thailand’s National Telecom (NTPCL) and TOT together account for roughly 40% of the cohort, with Korean, Chinese, French, and other hosting ASNs in the remainder. Synology and aaPanel (BT-PANEL) certificate fingerprints appear in the subject DN data, suggesting a mix of NAS devices and shared hosting panel deployments sharing this port by convention.
Port 40029 (~31,500 services) is almost entirely Alibaba Cloud running IIS FTP. There’s no documentation about what this port is specifically for, but it might be associated with an Alibaba Cloud base image that defaults to this port assignment alongside port 21.
Port 10021 (9,127 services) is mostly running vsftpd and concentrated in Korean ISP ASNs (Korea Telecom and LG Dacom) and the Japanese VPS provider Xserver. The commonly co-occurring protocol mix of VNC, DAYTIME, RDATE, and Telnet on over 2,600 hosts points to home servers and small NAS devices rather than commercial hosting. Deeper in the tail, ports 31021 and 55011 are both ~98–100% vsftpd and concentrated in Japanese consumer ISP ASNs (BEKKOAME, So-net, IIJ, BIGLOBE): residential fiber customers with FTP enabled on alternate ports.
Port 521 (9,107 services) is largely found open on US-based budget VPS and reseller infrastructure, including HugeServer, Voxility, Sentris, Network Transit, and eNET. Most of these services don’t advertise which FTP server they’re running, and their certificate subject DNs are patterned on hosting provider-generated self-signed hostnames like voxility.net, highboost.net, and famechill.net. This looks like a bulk hosting template convention, where FTP runs on 521 as a secondary listener alongside port 21.
The takeaway here is that scanning only port 21 will miss the meaningful long tail of your FTP attack surface.
The Big Picture
The geography, ASN distribution, and server technology mix in this dataset all point toward the conclusion that most Internet-facing FTP configurations are a byproduct of commodity hosting and broadband defaults.
The top ASNs are consumer broadband carriers, hyperscale cloud providers, and shared hosting networks. The most common daemons are whatever those platforms shipped: the defaults in cPanel-class Linux stacks, unmanaged VPS templates, and Windows hosting panels. The typical Internet-facing FTP server is running alongside mail services, databases, and web hosting. It was not deployed to be a dedicated file transfer appliance, but rather left running as an additional capability.
More specialized uses like seedboxes and managed file transfer hosts exist, but make up a smaller fraction in comparison.
The exposure story here is not primarily about organizations that chose FTP and configured it badly, or about a zero-day or advanced threat actor. It is about default configurations shipped along with popular hosting stacks that were likely never revisited.
What Can Organizations Do?
For enterprise defenders running FTP infrastructure, there are a few questions to ask.
The first is whether FTP is necessary at all. SFTP (SSH File Transfer Protocol) and FTPS both provide encrypted file transfer with broadly compatible client support. For most use cases, FTP can be replaced without significant disruption. If FTP must remain, enabling Explicit TLS is a configuration change, not a protocol upgrade, and both Pure-FTPd and vsftpd support it natively.
IIS FTP administrators need to configure a server certificate and set the controlChannelPolicy to SslRequire or SslAllow; defaulting to SslAllow could be a first step for environments where legacy clients may not support TLS.
The Censys Platform query for monitoring your own FTP exposure posture:
host.services.protocol="FTP" AND host.services.ftp.implicit_tls=false AND NOT host.services.ftp.auth_tls_response: "234"This surfaces FTP hosts in your asset inventory that neither support Implicit TLS nor respond affirmatively to an AUTH TLS probe, covering both the outright-no-TLS and TLS-explicitly-disabled populations.
FTP won’t be gone from the Internet anytime soon. But understanding where it lives, who’s running it, and whether encryption is configured is the first step toward making the parts of it that are exposed a little more robust.
Censys Platform Queries
All Internet-facing FTP hosts:
host.services.protocol = "FTP"FTP hosts with no observed TLS negotiation:
host.services: (protocol = "FTP" and not (tls.version_selected: *))FTP hosts running legacy TLS (TLSv1.0 or TLSv1.1):
host.services: (protocol = "FTP" and (tls.version_selected = "TLSv1_0" or tls.version_selected = "TLSv1_1"))IIS FTP deployments:
host.services: (protocol = "FTP" and software.product = "internet_information_services")References
- RFC 959 — File Transfer Protocol (FTP). Postel, J. & Reynolds, J. October 1985.
- RFC 2228 — FTP Security Extensions. Horowitz, M. & Lunt, S. October 1997.
- RFC 4217 — Securing FTP with TLS. Ford-Hutchinson, P. October 2005.
- RFC 8996 — Deprecating TLS 1.0 and TLS 1.1. Moriarty, K. & Morton, A. March 2021.
- Pure-FTPd README.TLS (upstream source).
- Pure-FTPd default configuration file (pure-ftpd.conf.in).
- Configuring vsftpd with SSL/TLS on Red Hat Enterprise Linux. Red Hat Customer Portal.
- ProFTPD: FTP and SSL/TLS (mod_tls documentation).
- Microsoft IIS FTP documentation (ftpServer.security.ssl.controlChannelPolicy).
- Securing FTP Access on a cPanel Server. The cPanel Admin.
- Introduction to IBM z/OS Communications Server (2024). IBM.
