Use SFTP, or FTPS when a partner mandates it, instead of plain FTP for any automated report delivery. Set up a dedicated service account with SSH key authentication, then gather the host, port, destination path, and credential type before touching your reporting tool. Test connectivity first. Everything else, scheduling, retries, verification, follows from that one decision.
TL;DR:
- Using SFTP is the safest default for automated report delivery due to its single encrypted SSH channel and straightforward firewall configuration.
- Gather server information, permissions, and credentials, including port 22 and SSH key setup, before configuring your reporting tool.
- First test connectivity with command-line tools or file managers like FileZilla, then configure transfer behavior and run a small dummy upload to validate setup.
- Scheduled or event-driven triggers should be chosen based on data consistency needs, with detection of delivery issues relying on checksum verification and log monitoring.
- Rely on secrets management and comprehensive logging to prevent security breaches and ensure reliable, auditable delivery workflows.
Table of Contents
- FTP vs. FTPS vs. SFTP: Which One Should Handle Your Reports?
- What to Gather Before You Configure Anything
- Setting Up and Testing Your Delivery Destination
- Scheduling Report Delivery: Fixed Time vs. Triggered Events
- Locking Down Credentials and Access
- Verifying Delivery: Checksums, Retries, and Cleanup
- When Report Delivery Breaks: Where to Look First
- ChristianSteven Software's Track Record on Secure Delivery
- What IT Teams Get Wrong About Automating Delivery
- Automate Delivery Without Building It From Scratch
- Where to Verify These Technical Details
- Sources
- FAQ
FTP vs. FTPS vs. SFTP: Which One Should Handle Your Reports?
FTP, defined in RFC 959, sends both commands and data in plain text across two separate channels, one for control on port 21, another for the actual file transfer. Anyone watching network traffic can read the file contents and the login credentials. That's not a theoretical risk; it's the default behavior of the protocol.
FTPS bolts TLS encryption onto that same two-channel structure. RFC 4217 spells out how a client negotiates protection using AUTH, PBSZ, and PROT commands before any data moves. It works, but it still requires a range of open ports for firewalls to manage.
SFTP throws out the FTP model entirely and runs everything, commands and data, over a single encrypted SSH connection on port 22. That single channel is why firewall administrators generally prefer it: one port to open, no dynamic port ranges, simpler NAT traversal.
For most report delivery use cases, SFTP wins:
- Plain FTP: avoid for anything containing business data, financials, or personal information
- FTPS: use when a partner's infrastructure requires it or legacy systems demand TLS-wrapped FTP
- SFTP: default choice for new automated deliveries, given its encryption and simpler firewall footprint
- Managed File Transfer (MFT): consider when you're delivering to dozens of partners, need audit trails for compliance, or require centralized RBAC across teams
What to Gather Before You Configure Anything
Nail down these details before opening your reporting tool's configuration screen. Skipping this step is the single biggest cause of failed first attempts.
- Server address and port. Get the exact FQDN or IP, plus the port (22 for SFTP, 21 plus a passive-mode range for FTP, often 990 for FTPS).
- Destination path and permissions. Confirm the exact folder path and that your service account has write access there, not just read.
- Account type and directory scope. Ask whether the account is chrooted to a specific home directory. A misunderstanding here causes half of all "file not found" complaints downstream.
- Network rules. For FTP, get the passive-mode port range from your network team. For SFTP, confirm port 22 is open outbound from your reporting server to the destination.
- Credential type. Decide password or SSH key upfront. Key-based auth is stronger and it's what most enterprise destinations expect now.
Pro Tip: Never paste credentials directly into a scheduled task or a script's config file. Even a "temporary" hardcoded password tends to outlive the person who wrote it. Pull credentials from a secrets manager at runtime instead.
Setting Up and Testing Your Delivery Destination
Configuration goes faster when you validate the connection path before you touch your BI tool's scheduler.
- Confirm raw connectivity first. Use a quick
telnet host 22or an SSH test from the command line, or open the destination in FileZilla or WinSCP to confirm the server accepts your credentials outside of any automation layer. - Add the destination in your reporting platform. Enter the host, protocol (SFTP recommended), port, and full destination path exactly as given by the server admin.
- Configure authentication. For key-based auth, generate a key pair, upload the public key to the server's authorized keys, and store the private key and passphrase in a secrets vault rather than the tool's local config.
- Set transfer behavior. Choose passive mode if you're stuck with FTP, set a reasonable timeout, and define a filename template that includes a timestamp or run ID to avoid overwrites.
- Run a test upload. Push a small dummy file and confirm it lands in the right path with the right name, then check the destination server's own logs, not just your tool's success message.
Products like PBRS and ATRS from ChristianSteven Software walk through this exact sequence when adding an SFTP destination, which is worth a look if you want a reference against your own setup.
Scheduling Report Delivery: Fixed Time vs. Triggered Events
A fixed schedule works fine when your report has a predictable data cutoff, say, a nightly sales summary that always runs at 6 a.m. But rigid cron-style schedules break down the moment your data pipeline runs late or a holiday shifts a batch job.
- Cron-like schedules are simplest to set up but need explicit timezone handling; a job set for "6 a.m." during daylight saving time can silently drift an hour if the scheduler isn't timezone-aware.
- Event-driven triggers fire off the completion of an upstream job, like an ETL pipeline finishing, rather than a clock. This avoids delivering a report built on half-loaded data.
- Data-driven bursting generates and delivers parameterized versions of the same report, one per region or one per client, often triggered by a change in the underlying dataset rather than a schedule.
- Deterministic filenames matter more than people expect. If a downstream system ingests your files automatically, an unpredictable filename pattern or out-of-order delivery breaks their parsing logic just as easily as a missing file does.
Locking Down Credentials and Access
Security failures in automated transfers rarely come from a broken encryption algorithm. They come from a hardcoded password in a script that got copied into three other scripts, or a service account with far more access than the job actually needs.
- Default to SFTP or FTPS. Plain FTP's control and data channels transmit everything unencrypted per its original RFC 959 design, a real gap compared to SFTP's single encrypted channel.
- Treat SSH keys as inventory, not secrets you set once and forget. NIST IR 7966 recommends dedicated service keys per integration, scheduled rotation, and a documented process for revoking a key when an employee or vendor relationship ends.
- Use a secrets store, HashiCorp Vault, Azure Key Vault, AWS Secrets Manager, rather than embedding credentials in a config file or scheduler task.
- Log every transfer and feed it to your SIEM. CISA's ransomware guidance flags unmonitored automated transfer pipelines as a common blind spot attackers exploit for data exfiltration.
Security teams increasingly treat any plain FTP traffic on a network as a red flag worth investigating on its own, not because FTP itself is malicious, but because legitimate modern workflows rarely have a reason to still use it.
For a deeper look at how SOC 2 controls intersect with SFTP delivery specifically, this breakdown of secure delivery practices covers the audit angle IT teams often get asked about.
Verifying Delivery: Checksums, Retries, and Cleanup
A file landing in the right folder isn't proof the transfer actually succeeded. Verification closes that gap.
- Check existence, then check integrity. A file-exists check catches obvious failures; comparing an MD5 or SHA256 checksum against the source catches silent corruption that a size check would miss.
- Upload as
.partial, then rename. This atomic pattern means downstream systems never accidentally read a half-written file mid-transfer. - Build in retry with backoff. A transient network blip shouldn't fail the whole job; three retries with increasing delays handles most temporary outages.
- Alert on failure, not just success. Silence is not confirmation.
- Set a retention policy. Old report files pile up fast on a landing directory; automate cleanup on a schedule rather than manually pruning folders every few months.
Pro Tip: Route failure notifications to a channel your team actually watches, not just an inbox filter that silently archives them. A retry that fails three times and nobody sees is functionally the same as no monitoring at all.
When Report Delivery Breaks: Where to Look First
Most FTP and SFTP delivery failures trace back to one of four causes.
- Firewall and port issues. For FTP, confirm the passive-mode port range is open in both directions; NAT devices often mangle the PASV response and block the data channel even when the control channel connects fine.
- Path and permission problems. Chrooted accounts can make a path look correct in your config while the server interprets it relative to a different root; a patched path-normalization vulnerability in SFTPGo is a good reminder that server-side directory handling deserves scrutiny, not just client-side config.
- Authentication mismatches. A key generated in the wrong format (PuTTY's .ppk versus OpenSSH format) or a passphrase mismatch fails silently in some clients with unhelpful error messages.
- Unread logs. Both the reporting tool's transfer log and the destination server's own log usually tell a more complete story than the error message shown in the scheduler UI.
ChristianSteven Software's Track Record on Secure Delivery
ChristianSteven Software has spent more than two decades automating BI reporting workflows across PBRS, ATRS, CRD, and IntelliFront BI. The company holds SOC 2 Type II certification and publishes step-by-step guides for configuring FTP and SFTP destinations, including how to set up an FTP destination in ATRS for teams automating Tableau report delivery.
What IT Teams Get Wrong About Automating Delivery
Most teams over-invest in scheduling logic and under-invest in secrets management and post-transfer verification. Prioritize SFTP with service keys and centralized monitoring first. Escalate to enterprise automation once compliance or scale outgrows a script.
— Christian Ofori-Boateng
Automate Delivery Without Building It From Scratch
Building your own SFTP delivery pipeline from scheduled scripts means you're also on the hook for maintaining key rotation, retry logic, and failure alerts yourself, indefinitely. Some product lines handle that operational layer directly, supporting secure destinations, flexible scheduling, automatic retries, and failure notifications built in.
Instead of stitching together a scheduler, a secrets vault, and custom retry logic, you configure the destination once inside the tool your reports already run through. If you're automating Power BI delivery specifically, the Power BI scheduled report tutorial shows the exact setup flow. For a broader look at what's available across products, visit ChristianSteven Software's product overview and request a demo to see how it handles your specific delivery destinations.
Where to Verify These Technical Details
- RFC 959 and RFC 4217 for FTP and FTPS protocol behavior
- NIST IR 7966 for SSH key lifecycle management
- CISA's Stop Ransomware guidance for monitoring and incident response
- Guidance on securing files exposed to AI tools and automation on shared company storage
Sources
- NIST IR 7966 - SSH-Based Access Management Planning and Implementation
- CISA Stop Ransomware Guide
- NVD - CVE-2026-30914
- FTP vs SFTP - Red Hat blog
FAQ
What Does FTP Stand For?
FTP stands for File Transfer Protocol, a standard defined in RFC 959 for moving files between a client and a server over a network. It predates modern encryption standards, which is why it transmits data and credentials in plain text.
What Is FTP File Delivery?
FTP file delivery is the automated or manual process of pushing files, such as scheduled business reports, from one system to a server folder using the File Transfer Protocol or one of its secure variants. In practice, most organizations now use SFTP or FTPS for this instead of plain FTP because of the encryption gap.
Why Is Plain FTP No Longer Used for Sensitive Transfers?
Plain FTP sends both login credentials and file contents unencrypted across the network, a design baked into the original RFC 959 specification. Security teams now treat unencrypted FTP traffic as a risk indicator and favor SFTP's single encrypted channel instead.
Is SFTP the Same Thing as FTPS?
No. SFTP runs entirely over SSH on a single port, while FTPS wraps the older FTP protocol in TLS encryption but still relies on FTP's separate control and data channels. Both encrypt data in transit, but SFTP's single-port design generally simplifies firewall configuration compared to FTPS.
How Do I Automate Report Delivery to an SFTP Server?
You configure a delivery destination in your reporting tool with the server's host, port, path, and an SSH key or password, then attach a schedule or trigger to it. Tools like PBRS and ATRS from ChristianSteven Software handle this natively, including retries and failure notifications, without requiring custom scripts.