Secure File Transfer Best Practices — Engineering Standards for Production

Secure File Transfer Best Practices

Securing file transfer is more than encrypting the connection. It includes verifying partner endpoints, managing credentials carefully, maintaining audit evidence, and running the system with operational discipline.

Verify partner endpoints explicitly

Never skip host key verification for SFTP or certificate validation for FTPS and AS2.

For SFTP: obtain the host key fingerprint from the partner independently. Do not rely solely on ssh-keyscan output from an untrusted path.
For FTPS: obtain the CA certificate from the partner. Pin the server certificate fingerprint for high-assurance partners.
For AS2: bind certificates to roles explicitly via the Certificate inventory.

Disabling verification (e.g., insecure_skip_verify=true) reduces a cryptographic security control to a convenience setting. Track any exceptions and plan to remove them.

Use secret references, not plaintext credentials

Credentials in configuration files that end up in version control, backup systems, or email attachments are a major source of credential exposure.

Use secret references:

env:PARTNER_PASSWORD — from environment variable
file:/run/secrets/partner_key_pass — from a mounted secret file
vault:secret/data/partners/supplier#password — from HashiCorp Vault
aws-sm:prod/mft/supplier#password — from AWS Secrets Manager

In hardened mode, plaintext credentials in sensitive fields are rejected at startup.

Rotate keys and certificates before expiry

Certificate and key expiry causes flow failures at the worst possible time.

Operational requirements:

set a warning window and monitor it (security.key_expiry_warn_days)
plan key rotation at least 30 days before expiry
rebind replacement certificates to partners before the old cert expires
verify the posture engine shows no expiry findings after rotation
run xferity diag to confirm the new material works before disabling the old

Enable idempotency on all production flows

Idempotency prevents reprocessing files that were already successfully handled. Without it, rerunning a flow after a failure may deliver files a second time.

idempotency_mode: hash

Use hash mode for most production flows. Reserve none mode only for flows where duplicate delivery is explicitly acceptable.

Enable audit logging

Audit logging is the primary evidence layer for answering “what happened to this file.”

audit:
  enabled: true
  path: ./audit/audit.jsonl

For higher assurance:

enable tamper evidence (tamper_evidence_enabled: true)
export audit records to an external immutable store
set a retention policy that meets compliance requirements

Lock flows against concurrent runs

Flow locking prevents overlapping executions that could corrupt state or cause duplicate delivery.

lock_wait: true
lock_stale_after_seconds: 300

This is especially important for flows processing the same source directory.

Keep configuration under version control

Configuration drift is one of the most common causes of unexplained behavior in production systems.

Configuration files, partner definitions, and flow definitions should be:

in version control
subject to change review before deployment
validated with xferity validate before promotion to production

Monitor for security posture drift

The security posture engine tracks crypto, secrets, transport, auth, and flow drift findings.

Good practice:

review Active Findings on a regular cadence (at minimum weekly)
address or explicitly suppress each finding with documented justification
alert on posture regressions using notification channels

Ignoring findings until an audit or incident is a reliability and compliance risk.

Run hardened mode in production

security:
  hardened_mode: true

Hardened mode rejects insecure configuration patterns at startup. It is the most direct configuration improvement for a production deployment.