To secure FTP, replace plain FTP with a protected transfer method, restrict who can connect, and keep the server and its accounts maintained. These steps help prevent passwords and files from being exposed or altered while they move across a network.
Traditional FTP does not encrypt its traffic, so it is not appropriate for sending sensitive information over an untrusted network. The practical goal is to use a secure alternative, configure it deliberately, and test access without disrupting legitimate users. Exact settings vary by server software, operating system, and hosting environment; check the official documentation for the versions you use.
What You’ll Need
- Administrative access to the FTP server or its hosting control panel.
- A secure transfer protocol supported by both the server and client: usually SFTP over SSH, or FTPS with TLS.
- A client application that supports the protocol you choose.
- A way to back up the current server configuration and restore it if a change causes an outage.
- A list of people, systems, and folders that genuinely need transfer access.
- Network or firewall access to allow the required connection method, coordinated with whoever manages that network.
Step-by-Step
- Confirm what service you are running. Find out whether the current service is plain FTP, FTPS, or SFTP. The names are easy to confuse: FTPS adds TLS protection to FTP, while SFTP is a separate file-transfer protocol that operates through SSH. They are not interchangeable, and they use different server settings. Check the service configuration and the client connection profile rather than relying on a label such as “secure FTP.”
- Choose one protected method that fits your setup. SFTP is often a straightforward option when SSH is already managed and the server supports file-transfer access. FTPS may suit a system that must retain FTP-compatible workflows, but it needs TLS certificates and careful firewall configuration. Ask your hosting or system administrator which option is supported and approved. Do not enable plain FTP as a fallback for clients that cannot connect securely.
- Back up the configuration and plan the change. Save the existing server settings and note the current connection details, user permissions, and firewall rules. If others depend on the service, agree on a change window and tell them how they will connect afterward. Keep a separate administrative path available so you can correct settings if the transfer service stops responding. Avoid changing several unrelated security controls at once.
- Enable encryption and reject unprotected sessions. For SFTP, enable the server’s SFTP subsystem through its SSH service and ensure the service is maintained. For FTPS, configure TLS with a valid certificate and require encryption for both authentication and data transfers. Set clients to verify the server certificate or host key; accepting any certificate defeats an important identity check. Disable plain FTP, including any insecure fallback or downgrade option, once secure access is confirmed.
- Limit accounts and privileges. Give each person or integration its own account rather than sharing a login. Remove accounts that are no longer needed, and use strong, unique credentials or approved SSH keys according to your organization’s policy. Grant only the folders and actions required: a user who only uploads should not automatically be able to browse or delete unrelated files. Where the server supports it, confine accounts to their assigned directories.
- Restrict network access. Permit connections only through the network paths and ports required by the selected protocol. With SFTP, administrators typically manage access through the SSH service. FTPS can require additional data-connection ports, especially in passive mode; configure those ranges consistently on the server and firewall. Do not open broad port ranges or expose administrative services to the entire internet without a clear need. If users connect from changing locations, ask the network administrator about an appropriate access method.
- Protect credentials and server keys. Do not put passwords in scripts, shared notes, or command histories. Use a secure credential store or a managed key arrangement where available, and protect private keys so only their intended owner can use them. Verify a server’s host key or certificate through a trusted channel when setting up a new connection, especially if a client warns that it has changed. A warning could indicate a routine replacement, but it should be checked before proceeding.
- Test with a limited account. Connect from the same network and client conditions your users will have. Confirm that the server identity is verified, encryption is active, and the account can perform its required task. Then try an action it should not be allowed to perform, such as accessing another user’s folder or deleting a protected file. A good test checks both successful access and effective restrictions.
- Review logs and maintain the service. Check authentication and transfer logs for failed attempts, unexpected accounts, or access outside normal expectations. Avoid recording secrets in logs. Keep the server software, operating system, and client applications updated through your normal maintenance process. Revisit accounts, access rules, certificates, and keys when staff roles or system needs change.
Common Mistakes
Assuming FTP over a trusted network is automatically safe: Network location alone does not encrypt traffic. A compromised device or network path can still expose unprotected credentials and files. Use encryption even when access is limited to an internal network.
Confusing SFTP and FTPS: A client configured for one cannot necessarily connect to the other. Confirm the exact protocol with the server administrator, then select the matching mode in the client.
Allowing insecure fallback: A setting that retries with plain FTP when a secure connection fails can quietly undo the protection you intended. Configure the client to fail closed and fix the secure connection instead.
Ignoring certificate or host-key warnings: Clicking through a warning without checking can expose a connection to impersonation. Verify whether the server identity changed through an administrator or another trusted channel.
Giving every account broad access: A successful login is not proof that permissions are appropriate. Restrict folders and operations, and test with an account that has limited privileges.
Opening firewall access too widely: Broad rules increase exposure and can make troubleshooting harder. Allow only the traffic the chosen service needs, and document why each rule exists.
Tips
- Write down the selected protocol and connection requirements in an internal setup guide, without including passwords or private keys.
- Use separate accounts for people and automated transfers so you can revoke one without interrupting every connection.
- For automated jobs, test how credentials are stored and how failures are reported before scheduling recurring transfers.
- Keep a known-good configuration backup and a recovery plan before changing authentication or firewall settings.
- Use a staging environment when available to test client compatibility and permissions before changing a production service.
- Agree on a process for reporting unexpected login prompts, identity warnings, or unexplained connection failures.
Troubleshooting
The client cannot connect: Confirm that the server is running and that the client is set to the correct protocol, host, and port according to the administrator’s instructions. Check whether a firewall, network rule, or VPN requirement is blocking the connection. Do not solve the problem by switching to plain FTP.
Login fails after enabling secure access: Check the username, authentication method, and account status. For SFTP, confirm that the account is permitted to use the SSH service and that its key or password is configured as expected. For FTPS, verify that the client is using the required TLS mode. Consult server logs for the reason, while taking care not to expose credentials.
The connection works but directory listings or transfers hang: This can indicate a data-channel or firewall problem, particularly with FTPS. Confirm the server’s passive-mode configuration and the matching firewall rules with the network administrator. For SFTP, check whether a proxy, security appliance, or server restriction is interfering.
The client reports a certificate or host-key change: Stop and verify the change with the responsible administrator using a trusted communication channel. If the server was intentionally rebuilt or its certificate was renewed, update the client only after confirming the new identity. If no change is expected, treat the warning as a security concern.
Users can connect but cannot do their work: Check folder ownership, permissions, account confinement, and whether the required upload, download, or rename operation is allowed. Test a representative task with a limited account. Change only the permission needed rather than granting broad access.
A configuration change locks out administrators: Use the backup or recovery route planned before the change, and involve the system administrator or hosting provider. Restore the last known-good settings if necessary, then test a smaller change in a controlled environment before trying again.
Frequently Asked Questions
Is ordinary FTP secure?
Ordinary FTP does not encrypt its login details or file transfers. Use SFTP or properly configured FTPS when protection in transit is required.
Is SFTP the same as FTPS?
No. SFTP transfers files through SSH; FTPS adds TLS protection to FTP. Choose the method the server supports and configure the client to match.
Which should I use, SFTP or FTPS?
There is no universal choice. Consider what your server and clients support, your firewall and certificate requirements, and your organization’s policies. Ask the administrator responsible for the service.
Does encryption protect files after they arrive?
No. Encryption in transit protects the connection, not files stored on either system. Use appropriate storage permissions, backups, and any required at-rest protection separately.
Can I keep plain FTP available for older clients?
That leaves an unencrypted route that may be used accidentally or intercepted. Prefer updating or replacing incompatible clients. If an exception is unavoidable, have an administrator assess and tightly limit the risk rather than exposing the service broadly.
How can I tell whether a connection is really protected?
Check the client’s connection details and server logs for the negotiated protocol and encryption status, and confirm that certificate or host-key verification is enabled. A successful login alone does not prove that the connection is encrypted.