Xferity Overview — Secure Managed File Transfer (MFT) Platform

Xferity Overview

Xferity is a secure, self-hosted managed file transfer (MFT) platform for teams replacing fragile scripts, manual transfer workflows, and legacy partner exchange systems with a controlled, auditable, and secure operating model.

It is designed for environments where partner exchange must be automated, reviewed, secured, and traced without outsourcing the runtime to a third-party service.

What Xferity is

Xferity provides a structured way to define, validate, run, and operate partner-facing file exchange.

Xferity includes:

a CLI for validation, diagnostics, execution, tracing, and operator workflows
an authenticated Web UI and HTTP API
a flow runner for scheduled and on-demand execution
partner configuration for SFTP, FTPS, AS2, S3-compatible storage, and local endpoints
Certificate and PGP Key inventory
Partner Crypto Policy and Flow Crypto Requirements views
security posture evaluation, suppressions, trends, and regression alerts
file-backed and Postgres-backed runtime modes
audit logging and run history

Problems it addresses

Xferity is intended for teams that need to replace:

fragile shell or PowerShell scripts
cron-driven file exchange jobs
WinSCP-style automation
older MFT installations that are difficult to review or change

The goal is not just moving files. The goal is making repeated partner exchange predictable under failure, change, and security review.

Supported protocols

Xferity supports:

SFTP
FTPS
S3-compatible storage
AS2

See Protocols.

Core capabilities

Partner and flow control plane

Xferity models exchange around two main objects:

partners: reusable remote endpoint definitions
flows: executable transfer workflows

This lets teams separate connection and trust settings from scheduling and transfer behavior.

Crypto lifecycle management

Xferity manages two crypto asset types:

Certificate
PGP Key

Lifecycle operations include generation, import, export, binding, rotation support, expiry tracking, capability validation, and audit history.

Partner Crypto Policy

Partner pages expose a unified Partner Crypto Policy view showing required and bound roles across:

This gives operators a single place to understand whether a partner is correctly configured for secure exchange.

Flow Crypto Requirements

Flow pages expose Flow Crypto Requirements derived from the canonical role-definition model used by validation, UI policy views, runtime preflight, and runtime crypto resolution.

Security posture engine

Xferity includes a posture engine that evaluates:

crypto
secrets
transport
auth
flow drift

Across these scopes:

platform
partner
flow

The engine produces:

Posture Findings
Active Findings
Suppressed Findings
hourly snapshots in supported backends
posture trends
regression detection
alerts

Notification channels

Regression alerts can be delivered through:

Email
Slack
Webhook
Ntfy
Gotify
Pushover

Runtime modes and storage backends

Xferity supports two main backend models:

File backend

The file backend is suitable for simpler single-node operation. It provides local state and basic runtime behavior, but advanced control-plane features are limited.

Postgres backend

The Postgres backend enables the full production-oriented feature set, including:

persisted auth and sessions
queued jobs and workers
Certificate and PGP Key inventory
posture snapshots and suppressions
regression alerts based on snapshot history
AS2 persistence and richer shared-state operation

Security posture at a glance

Xferity includes:

SSH host verification for SFTP
TLS certificate validation for FTPS
AS2 certificate roles and HTTPS trust configuration
OpenPGP payload protection where configured
secret references and redaction
hardened mode
audit logging

See Security for the security model and Architecture for the runtime design.

What makes Xferity different

Most MFT alternatives require accepting one of these tradeoffs: give up infrastructure control, accept unreviewable configuration, or manage a heavyweight installation that costs more to maintain than the transfers it runs.

Xferity is built around different defaults.

Single canonical role model — no config drift

FlowRoleSpecs() is the single source of truth for PGP role requirements. The same definition is used by config validation, the UI policy view, runtime preflight, and runtime crypto resolution. There is no way for the UI to show a policy that the runtime enforces differently. Configuration drift between display and execution is structurally prevented.

Strict YAML parsing — no silent misconfiguration

The configuration loader rejects unknown YAML fields. A misspelled key causes a startup failure, not a silent no-op. In script-based and legacy MFT deployments, silent misconfiguration has historically been one of the most common sources of undetected behavioral drift.

Hardened mode — enforcement, not just advice

When security.hardened_mode: true is set, Xferity refuses to start if any security rule is violated: plaintext secrets in config, sslmode: disable for PostgreSQL, insecure TLS settings on partners, missing auth configuration. Security requirements are enforced at startup rather than communicated as documentation recommendations.

Tamper-evident audit log — verifiable by default

Audit events are linked by a SHA-256 hash chain. The chain can be verified with standard JSON tooling without any proprietary tooling. Any modification, deletion, or insertion of an event breaks the chain and is detectable. This is built in, not an add-on.

Isolated GnuPG execution — no shared keyring side effects

When GnuPG is used, each operation runs in a temporary isolated GnuPG home. There is no shared keyring that one flow’s operation can corrupt for another. No GPG agent side effects between jobs. No host-profile dependency. If workspace cleanup fails, the event is surfaced through structured log fields rather than silently ignored.

Security posture engine — continuous misconfiguration detection

Xferity evaluates your full security posture across 6 domains (crypto, secrets, transport, auth, flow, lifecycle) every evaluation cycle. Findings are suppressed separately from being detected — suppressed findings remain visible in the full audit trail. Posture snapshots are stored over time. When security state worsens, regression alerts are delivered to configured notification channels before a partner escalation arrives.

7 secrets providers — no hardcoded credentials required

Credentials are resolved at runtime from any of: environment variables, files, AES-256 local vault, HashiCorp Vault KV v2, AWS Secrets Manager, Azure Key Vault, or literal (testing only). This works across all config layers: global config, partner config, flow config, auth config. In hardened mode, plaintext credentials in any sensitive field reject startup entirely.

No mandatory outbound connections — air-gap ready

License validation is local by default. No outbound calls to external services are required during normal operation. An Xferity deployment can run indefinitely in an air-gapped network with only secrets providers and partner endpoints that your network already permits.

Who Xferity is for

Xferity is most relevant for:

operations teams replacing transfer scripts
DevOps teams standardizing self-hosted file exchange
implementers onboarding trading partners
security teams reviewing crypto and audit posture
organizations that want managed partner exchange without giving up infrastructure control

Scope

To keep this overview precise:

Xferity is not a general-purpose application integration bus
Xferity is not a replacement for network security, identity systems, or SIEM tooling
Xferity is not a cluster manager or general orchestration platform
Xferity is not a compliance guarantee by itself

It is a transfer workflow engine — one designed to be auditable, reviewable, and secure by default for the class of problems that MFT platforms address.