SFTP is not automatically HIPAA compliant, but it can be when configured and managed correctly. The protocol’s built-in encryption covers one of HIPAA’s most important technical requirements, protecting data in transit, but compliance depends on how your entire SFTP environment is set up, who hosts it, and what policies surround it.
What SFTP Gets Right by Default
Standard FTP transmits everything in plain text: usernames, passwords, and the files themselves. Anyone intercepting that traffic can read it. SFTP solves this by encrypting all data and credentials during transfer through an SSH (Secure Shell) tunnel, which directly addresses one of HIPAA’s core technical safeguards: transmission security.
The HIPAA Security Rule requires covered entities to “implement technical security measures to guard against unauthorized access to electronic protected health information that is being transmitted over an electronic communications network.” SFTP’s encryption does exactly this. It also supports unique user authentication, which satisfies HIPAA’s required specification that each user have a unique name or number for identification and tracking. These two features, encryption in transit and individual user accounts, are why SFTP is so commonly used in healthcare file transfers.
Where SFTP Falls Short on Its Own
SFTP only encrypts data while it’s moving between two points. Once a file lands on the server, SFTP does nothing to protect it. HIPAA requires encryption for data at rest too, meaning the files sitting on your SFTP server’s disk need their own layer of protection, typically AES-256 encryption. Without it, anyone who gains access to the server’s storage can read the protected health information directly.
SFTP also doesn’t inherently provide audit logging, automatic session timeouts, or multi-factor authentication. HIPAA’s technical safeguards require all of these in some form:
- Audit controls: You need logs of who accessed what files, when, and whether authentication attempts succeeded or failed. These logs should be stored centrally with tamper-evident protections and retained for at least six years to align with HIPAA’s documentation requirements. Importantly, logs should capture metadata (who, what, when, where) without recording the actual health information itself.
- Automatic logoff: Sessions should terminate after a set period of inactivity, preventing unauthorized access if someone walks away from a terminal.
- Multi-factor authentication: While not explicitly named in the original Security Rule text, MFA has become a practical expectation. Johns Hopkins Health Plans, for example, began requiring MFA for all SFTP users in 2025, offering either an authentication app or email verification as a second factor.
Encryption Standards That Meet HIPAA in 2025
Not all encryption is equal, and older ciphers may not satisfy current expectations. For data in transit, organizations are expected to use TLS 1.3 or higher. For data at rest on your SFTP server, AES-256 is the baseline. For key exchanges and digital signatures, RSA-2048 is the minimum, though RSA-4096 or Elliptic Curve Cryptography offer stronger protection.
Encryption systems should also meet at least FIPS 140-2 Level 2 certification, with Level 3 recommended for higher-risk scenarios. If your SFTP server is running outdated SSH versions or weak ciphers, you may have encryption in name but not in practice.
The Business Associate Agreement Requirement
If you’re using a third-party provider to host your SFTP server, HIPAA requires a signed Business Associate Agreement before any protected health information touches their infrastructure. A BAA is a legal contract that makes the hosting provider directly responsible for safeguarding the data and liable for breaches. Without one, your file transfers are not HIPAA compliant regardless of how strong your encryption is.
When evaluating SFTP hosting providers, the first question to ask is whether they will sign a BAA. If they won’t, or if they don’t know what one is, that provider is not suitable for handling health information. A compliant SFTP solution needs to live within a HIPAA-compliant infrastructure, and the BAA is what formalizes that commitment.
What a HIPAA-Compliant SFTP Setup Looks Like
Putting it all together, a properly configured SFTP environment for healthcare data needs several layers working in concert. The SFTP protocol handles encrypted file transfer. Server-side disk encryption (AES-256) protects files at rest. Each user has a unique account with strong credentials and, ideally, multi-factor authentication. Sessions time out automatically after inactivity. Every file access, transfer, login attempt, and failure is logged with timestamps and stored securely for years. And if any third party hosts or manages the server, a signed BAA is in place.
The HIPAA Security Rule is deliberately technology-neutral. It never names SFTP or any other specific tool as “compliant.” Instead, it sets standards for access control, transmission security, audit controls, and integrity, then leaves organizations to choose the technology that meets those standards. SFTP is one of the most practical choices for file transfer because its core design already covers the hardest part: encrypting data in motion. But treating SFTP as a checkbox rather than one component of a broader security setup is where organizations get into trouble.
The distinction matters. SFTP is a protocol, not a compliance solution. Used correctly within the right infrastructure, policies, and legal agreements, it’s one of the most reliable ways to move protected health information. Used carelessly, with default configurations, no disk encryption, and no BAA, it offers a false sense of security.