SFTP has been the default protocol for moving protected health information (PHI) between healthcare organizations for decades. It works. Files get from point A to point B. But the question auditors and compliance officers are increasingly asking is not whether the transfer completed — it is whether the transfer was defensibly secure.

The answer, for most SFTP deployments, is no.

The SFTP Compliance Gap

HIPAA's Security Rule (45 CFR 164.312) requires covered entities and business associates to implement technical safeguards for electronic PHI. The relevant controls include:

• Access controls (§164.312(a)) — unique user identification, emergency access procedures, automatic logoff, encryption
• Audit controls (§164.312(b)) — mechanisms to record and examine activity in systems containing ePHI
• Integrity controls (§164.312(c)) — mechanisms to authenticate ePHI and protect against improper alteration
• Transmission security (§164.312(e)) — integrity controls and encryption for ePHI in transit

SFTP covers transmission security reasonably well — SSH encrypts data in transit. But it fails or underperforms on every other control:

Access controls: SFTP authenticates users with SSH keys or passwords. SSH keys are permanent until manually rotated, often shared across teams, and difficult to audit. There is no built-in MFA. When a contractor leaves or a key is compromised, organizations rarely know which keys to revoke because key inventories are incomplete.

Audit controls: SFTP server logs record filenames, timestamps, and IP addresses. They do not record who authorized the transfer, whether the recipient was verified, what was in the file, or whether the data was supposed to leave the organization. These logs are stored on the server itself — mutable, not tamper-evident, and not designed for evidentiary use.

Integrity controls: SFTP provides no native content scanning. PHI, PII, and malware pass through undetected. There is no mechanism to verify that the file received matches what was sent beyond SSH's transport-layer integrity.

What HIPAA Auditors Actually Want

When OCR (Office for Civil Rights) investigates a breach, they ask for evidence of controls at the time of the incident. "We use SFTP" is a starting point, not an answer. Auditors want to see:

1. Identity verification — proof that the person who accessed the data was authorized, verified through strong authentication
2. Access justification — evidence that each access was for a legitimate purpose, ideally captured at the time of transfer
3. Tamper-evident logs — audit records that cannot be modified after the fact, stored independently of the system that generated them
4. Content awareness — evidence that the organization knew what data was being transferred and had controls to prevent unauthorized disclosure

SFTP provides none of these natively.

The Identity-Bound Alternative

MnemoShare replaces SFTP's credential model with identity-bound, ephemeral access:

SSO + MFA replaces SSH keys. Users authenticate through your existing identity provider (Azure AD, Okta, Ping, Google) with enforced multi-factor authentication. No SSH keys to manage, rotate, or lose track of. Access tokens expire in 60 minutes — there are no permanent credentials anywhere in the system.

Dynamic questionnaires capture intent. Before every file transfer, senders and recipients answer context-specific questions: "Does this file contain PHI?" "Enter the case reference number." "Confirm you are authorized to share this data externally." Answers are captured as immutable snapshots — even if questions are later modified, the historical record remains intact.

Application-layer encryption with customer-controlled keys. Files are encrypted with AES-256-GCM before reaching storage. Encryption keys are customer-controlled — provided via Kubernetes secret, never stored in the database. A compromised storage account yields only ciphertext.

Content scanning detects PHI before storage. Built-in ClamAV scanning catches malware. The three-tier DLP engine (regex patterns, named entity recognition, optional AI classification) detects PHI patterns including SSNs, MRNs, NPI numbers, ICD-10 codes, and medication names — with configurable policies to quarantine, redact, or alert.

Evidentiary audit export. Audit events are exported to customer-managed WORM storage (S3 Object Lock) with cryptographic hash chain integrity. Once exported, records cannot be modified or deleted by anyone — including MnemoShare, the storage account administrator, or a compromised admin credential. This is the kind of audit evidence that survives breach investigations.

Migration Path

You do not have to rip out SFTP overnight. The practical approach:

1. Identify regulated flows first. Which SFTP transfers carry PHI? Which have audit requirements? Prioritize these.
2. Connect your identity provider. MnemoShare integrates with your existing SSO — users authenticate with credentials they already have.
3. Move sensitive exchanges incrementally. Partners access files through identity-verified links. No software to install, no keys to exchange.
4. Decommission SFTP servers as flows migrate. Every server removed eliminates credential sprawl and reduces attack surface.

For a detailed comparison of SFTP and MnemoShare's security model, see our SFTP Replacement guide.

The Bottom Line

SFTP was designed in the 1990s for a perimeter-based security model. HIPAA compliance in 2026 requires identity verification, content awareness, and tamper-evident audit trails — none of which SFTP provides natively. The gap between "files were encrypted in transit" and "we can prove who accessed what, when, and why" is where compliance risk lives.

Organizations that have already moved beyond SFTP are not doing so because SFTP is broken. They are doing so because the evidence requirements for regulated data exchange have outgrown what a file transfer protocol can provide.

Request a demo to see how MnemoShare handles HIPAA-compliant file exchange, or explore our pricing to get started.