|No such thing as a small change|
I think a better step is to minimize the power of the information that needs to be exposed to the client. If the client needs to upload files to the FTP server, then give the client access only to upload files and only the files it should be updating. And make that access only work when exercised from the system where the client is run.
If your FTP server software doesn't support such fine-grained access control, then have the client upload via some other means. You can configure ssh such that connections using a specific key file only allow very specific actions and only from certain IPs. On my OS, "man authorized_keys" (like http://man.he.net/man5/authorized_keys) gives details.
If the FTP server can even verify the uploaded files in some way, that may also be worth implementing. You could place restrictions on the naming and size of the files. You could examine the files to verify that they appear to be the correct type of file. Perhaps whoever is providing the files to the client could also provide cryptographic signatures for the files that the FTP server would verify. You could have the server send out an e-mail notice if rejected files get uploaded.
If you think this client is actually likely to be an attack vector, you could even honey-pot the client such as by giving it an 'access list' that it uploads if it gets updated. But never update this file and have the FTP server e-mail if such an update is received (and the FTP server doesn't actually honor the access list, just to be clear).
You could also have the FTP server send notifications of any updates to a third location so you can periodically review the pattern of updates for unexpected activity (if anybody will actually continue to bother to do that).
Also, you should run the client from a relatively secure host. Don't run the client from a shared-hosting service, for example. A better choice is a host that requires one layer of authorization just to get through the firewall (such as a VPN) and that has few logins permitted.
(Though, I was a bit surprised and disappointed that a recent employer had the VPN using LDAP authentication so somebody getting hold of my corporate username and password could get through both the firewall and into hosts behind the firewall -- though I suspect their motivation was certainty of timely revocation of all access upon termination of employment.)
I doubt your specific upload access case is serious enough of a security concern for even most of these steps to be warranted. But at least you've got a large list to pick from, if you so choose.