The phrase "zero trust" gets applied to everything in security marketing. But for file transfer specifically, it means something concrete: no transfer should succeed based solely on network position, static credentials, or inherited trust.

Most managed file transfer (MFT) platforms fail this test. They authenticate users with long-lived passwords, maintain persistent SSH/SFTP endpoints, store credentials in centralized databases, and assume that once authenticated, a user is authorized for the duration of their session. This is perimeter-based security applied to data exchange — and it is the reason platforms like MOVEit, GoAnywhere, and Kiteworks have been at the center of major breach campaigns.

What Zero Trust Means for File Transfer

Zero trust file transfer requires three things that legacy MFT platforms structurally cannot provide:

1. No Standing Credentials

The most exploited component in file transfer breaches is credentials. SSH keys that never expire. Service accounts shared across teams. Passwords stored in monolithic databases. When these credentials are compromised — through phishing, credential stuffing, or vulnerabilities in the platform itself — attackers gain persistent access.

Zero trust replaces standing credentials with ephemeral, identity-bound tokens:

• Access tokens that expire in minutes, not months
• Refresh tokens with rotation detection — if a stolen token is replayed, the entire token family is revoked
• Optional hardware-backed mTLS where private keys are non-exportable (TPM, Secure Enclave, YubiKey)
• No SSH keys, no permanent passwords, no credential stores to breach

The blast radius of a compromised credential in this model is measured in minutes, not months.

2. Identity Verification at Every Access

Perimeter-based MFT assumes that authentication at the front door is sufficient. Once you have a session, you can transfer files for the duration. Zero trust challenges this: every file access should verify the identity and intent of the requester.

This means:

• SSO integration (OIDC/SAML) with your enterprise identity provider — not a separate user database
• MFA enforcement at authentication — TOTP and WebAuthn/FIDO2 passkeys, not just passwords
• Dynamic questionnaires that require human validation before each transfer: "Does this file contain regulated data?" "Enter the authorization reference." Answers are captured as immutable compliance evidence.
• Per-access authorization rather than session-based trust

3. Assume Breach — Audit Everything

Zero trust assumes that compromise will occur and designs for containability and evidence. This means:

• Immutable audit trails that cannot be tampered with by compromised administrators
• Cryptographic hash chains linking audit records — any gap, reorder, or modification is detectable
• WORM storage (S3 Object Lock in Compliance mode) where not even the storage account root user can delete evidence
• SIEM export so security operations teams have real-time visibility into file transfer activity

Legacy MFT platforms store audit logs in the same database as the application. If the platform is compromised, the logs are compromised. Zero trust separates evidence from the system that generated it.

Why Legacy MFT Cannot Retrofit Zero Trust

The fundamental problem is architectural. Legacy MFT platforms are monolithic appliances — a single IIS or Java application that handles authentication, file transfer, storage, and logging in one process. This creates several zero trust incompatibilities:

Single blast radius. A vulnerability anywhere in the monolith gives attackers access to everything. CVE-2023-34362 (MOVEit) and CVE-2023-0669 (GoAnywhere) demonstrated this: SQL injection and deserialization bugs gave attackers full platform control because there were no internal trust boundaries.

Credential stores are co-located with data. The same database that stores user credentials stores transferred files (or references to them). Breaching the application layer breaches everything.

Audit logs are application-controlled. A compromised admin can modify or delete audit records. There is no external enforcement of log integrity.

Patching requires downtime. Monolithic architectures cannot be updated without service interruption, creating incentives to delay patching — exactly the behavior attackers exploit.

What Zero Trust File Transfer Looks Like

MnemoShare is designed from the ground up for zero trust file exchange:

• Kubernetes-native microservices with isolated control plane, data plane, and evidence pipeline — a vulnerability in one component does not compromise the others
• Ephemeral credentials with 60-minute access tokens (15 minutes for mTLS sessions) and family-based refresh token rotation
• Application-layer encryption (AES-256-GCM) with customer-controlled keys — the vendor never has access to your encryption keys or data
• Evidentiary audit export to customer-managed WORM storage with cryptographic hash chain integrity
• Dynamic questionnaires that create immutable records of human validation at every transfer

For organizations in Regulated mode, MnemoShare goes further: the application crashes rather than operating without immutable audit export. If SIEM export fails, the system halts. This is an intentional design choice — silent evidence degradation is worse than a visible outage.

Getting Started

If you are evaluating your current MFT platform against zero trust principles, start with three questions:

1. What happens when a credential is compromised? If the answer involves manual key rotation or password resets across multiple partners, you have a standing credential problem.
2. Can an administrator modify audit logs? If application-layer access can alter or delete transfer evidence, your audit trail is not evidence-grade.
3. What is the blast radius of a platform vulnerability? If a single CVE gives attackers access to credentials, file storage, and audit logs simultaneously, your architecture lacks internal trust boundaries.

Compare your current platform against MnemoShare's security architecture: SFTP vs MFT | Security Overview | Request a Demo