When a Client Asks for FTP Access: Lena's Story
Lena is a freelance web designer who built a clean, modern site for a boutique bakery. Six months after launch the owner wanted to "move some images and update a few menu items" and asked for FTP access. Lena hesitated. She had tightened file permissions, used a staging environment, and kept nightly backups. Still, she had handed FTP credentials to collaborators before and ended up spending entire weekends reversing accidental deletions and chasing down a broken PHP include.
She remembered one evening when a well-meaning intern used FTP to replace a css file with an older version, which broke layouts across the live site. Meanwhile, the owner complained the site wasn't displaying properly for customers. Lena spent four hours restoring files from backups and locking down accounts. As it turned out, the problem wasn't malice - just lack of control and insufficient processes for client edits.
That experience changed how Lena handled requests for server access. Rather than an immediate "yes" or "no," she developed a pragmatic approach that balanced security, client autonomy, and the practicalities of maintenance. This guide follows that approach and shows when to grant access, how to restrict it safely, and when to refuse outright.
The Hidden Cost of Unrestricted Server Access
Giving a client full FTP access might seem like a simple way to empower them. It can feel fair: they own the content, so they should be able to move files. But there are real costs to handing over unrestricted access.
- Security exposure: Plain FTP sends credentials in clear text unless FTP over TLS is enabled. That opens the door to interception, especially on public networks. Accidental damage: Users without technical knowledge can overwrite or delete key files, break permissions, or change ownership, creating downtime or data loss. Operational risk: When multiple people have identical credentials, it becomes impossible to track who made which change. That complicates troubleshooting and accountability. Maintenance burden: You may end up supporting issues caused by client edits, effectively doing extra unpaid work. Compliance and data protection: Certain industries require strict access controls and audit trails. Unrestricted FTP access may violate those requirements.
Imagine a thought experiment: a client with FTP access accidentally replaces the site index with an old development build on Black Friday. Revenue drops and trust erodes. Who pays? Who fixes it? This scenario is more common than people realize.
Why Giving Full FTP Access Backfires More Often Than Not
Common quick fixes - handing over the main FTP account, sharing a cPanel login, or setting a universal password - sound efficient but they create more problems than they solve. Here are the core reasons simple solutions usually fail.
First, FTP is often misconfigured. Many hosting setups still allow unencrypted FTP or weak passive mode settings. Clients may use public Wi-Fi or older FTP clients without TLS support, exposing credentials.
Second, FTP is coarse-grained. It grants file-level power without context. Users don't see deployment pipelines, database migrations, or cache layers. Overwriting files may not trigger necessary rebuilds or cause orphaned resources.
Third, rollback procedures are rarely user-friendly. If a client deletes something, restoring a site often requires backend access and technical knowledge. Meanwhile, the public sees a broken site.
Finally, sharing credentials undermines good practices like least privilege and separation of duties. That leads to compliance gaps and harder incident response. In short, convenience now can become expensive later.
Common Bad Outcomes
- Lost or corrupted data that requires manual restoration Downtime during high-traffic periods Security incidents due to leaked credentials Conflicts between developers and client edits
How One Developer Reworked Client Access for Safety and Clarity
Jon, a senior developer at a small agency, created a repeatable policy that avoided the typical pitfalls. His strategy relied on three principles: least privilege, auditability, and clear workflows.
Step 1 - Stop using vanilla FTP whenever possible. Jon pushed clients to SFTP or FTPS, which encrypt credentials and file transfers. On modern hosts he used SSH keys for SFTP and disabled password authentication for service accounts.
Step 2 - Create role-based accounts. Instead of one shared account, the agency set up separate accounts for each role: content editor, developer, QA. Each account had a tailored home directory and strict file permissions through chroot jails or equivalent isolation.
Step 3 - Introduce a staging environment. Clients could make changes on staging without risk to production. When updates were approved, a deployment process moved changes to production with automated backups and health checks.
Step 4 - Use version control where practical. For anything beyond static assets, Jon's team moved files into Git. That gave them a clear history and easy reverts. For clients reluctant to use Git, they provided a simple upload interface that committed changes on the server side.
This led to predictable handoffs. When a client requested access, Jon's team evaluated what they needed to accomplish and matched the access level accordingly rather than defaulting to FTP credentials.
Practical Controls to Implement
- Require SFTP or FTPS with TLS - disable plain FTP Use per-user credentials and avoid shared accounts Limit accounts to specific directories with chroot or equivalent Use SSH keys for developers and require 2FA for control panels Set up automated daily backups and test restore procedures Enable logging and centralize logs for auditing Rotate passwords and keys on account changes or project completion
From Confusion to Clear Rules: A Client Access Policy That Works
Jon distilled his approach into a short policy that he shared with clients during onboarding. It cut disputes and reduced emergency work. You can adapt the following checklist to your workflow.
Assess the request - what exactly does the client need to change? Images, copy, templates, or code? Offer a safe alternative - for content updates, give a CMS user role; for images, provide an upload form or S3 bucket with restricted access. If file-level access is unavoidable, create a temporary, scoped SFTP account with expiry and directory limits. Require an approval and deployment process for production changes. Staging first, then promotion to production. Log all access and send notifications for significant actions - file deletions, permission changes, large uploads. Schedule training or provide a short guide for any client account, explaining do's and don'ts. Include a clause in the contract specifying responsibilities and incident handling for client edits.As it turned out, simply documenting this policy saved both time and money. Clients felt empowered while the team kept control over critical systems.
Template: Quick Access Decision Flow
- Need: Content only? -> CMS/editor account Need: Images/marketing assets? -> Upload form or restricted S3 Need: Theme tweaks or code? -> Staging access + PR for review Need: Emergency fix? -> Temporary SFTP with automatic expiry and logging
From Daily Firefights to Predictable Maintenance: Real Results
After implementing these controls, Jon's agency recorded measurable improvements. Downtime incidents related to client edits fell by 85 percent. Time spent on emergency restores dropped from an average of three hours per month to under 30 minutes. Client satisfaction improved because edits were safer and rollbacks were faster when mistakes occurred.
One bakery client stopped requesting FTP entirely after seeing the staging workflow. They found the uploader UI easier and appreciated having a simple approval step that prevented accidental site breaks. This reduced friction and freed the agency to focus on planned improvements instead of reactive fixes.
Another client, a small e-commerce shop, read more required occasional product CSV uploads. The agency created a secure SFTP drop folder that only allowed uploads to a quarantine directory. An automated process validated CSV formats, rejected bad data, and triggered import jobs. This eliminated manual review work and avoided malformed data hitting production databases.
These outcomes show that controlled access doesn't hinder clients - it protects them. A well-defined access plan reduces risk while preserving the ability to make changes quickly when needed.
Thought Experiment: Two Paths
Consider two project paths. Path A grants permanent full FTP access to the client. Path B provides role-based SFTP accounts, a staging environment, and a clear change approval process. Think about the following possibilities:
- On Black Friday, a client accidentally deletes a product file - who recovers it and how long does recovery take? When you hand over the site at project end, how do you ensure long-term maintainability and incident response? If an account is compromised, what is the blast radius under each path?
Path B contains the blast radius, enables fast recovery, and keeps responsibilities clear. Path A looks simple up front but compounds risk over time.
Final Recommendations - Practical, No-Nonsense Rules
If you need a short checklist to follow right now, here it is:
- Never give plain FTP. Insist on SFTP or FTPS with TLS. Ask "what outcome does the client want?" before deciding access type. Prefer application-level tools (CMS, upload forms) over server-level access. If server access is required, scope it narrowly, use temporary accounts, and require logging. Put a rollback and backup plan in place before granting access. Document the process in the contract and share a one-page user guide with clients.
Short and blunt: granting FTP by default is lazy and costly. Protect your work and your client's business by choosing controlled, auditable methods for access.
When You Should Still Say No
- Client demands full root or control panel access without a valid, documented reason Client refuses secure transport (SFTP/FTPS) or insists on plain FTP Client wants shared credentials or refuses 2FA for control panel accounts Industry compliance prohibits the proposed access model
In those cases, refuse politely and offer alternatives. Most clients will accept a secure, limited path once you explain the risks and the easier alternatives.
Protecting a website is about managing trade-offs, not blocking client autonomy. This approach keeps sites stable, reduces surprise work, and preserves trust between you and the people you serve. If you want, I can draft a one-page client-facing access policy or a short email template you can use the next time a client asks for FTP credentials.