Security series by Axway MFT experts — Manage ciphers, keys, and algorithms with SecureTransport

Cryptographic Strength — The Next Layer of MFT Security 

Axway’s MFT product experts continue the Security series by Axway MFT experts. Earlier, we covered secret storage and identity & authentication. This installment focuses on the cryptographic layer — the ciphers, certificates, and algorithms that protect data in transit and at rest.

Why does this matter?

Most file transfers must be protected and secure. In Managed File Transfer (MFT), authentication alone is not enough. Communication between systems must be encrypted and private. Your protocol version, cipher suites, key lengths, and algorithms determine actual security. Using TLS is not the same as using TLS correctly.

Locking the door to your house doesn’t help if everyone has the key — and it’s even worse if you don’t realize they do. 

Axway SecureTransport provides the tools for strong encryption, but IT and security teams must configure and maintain secure configuration. Strong algorithms must be enabled, while weak and obsolete ones must be disabled to avoid communication happening over insecure channels. Partner systems may not be configured securely, and when sensitive data leaks or gets tampered with, the impact will be shared. 

Encryption in Transit: TLS Protocol Versions and Cipher Suites 

Encryption in Transit protects data as it moves across networks, ensuring confidentiality and integrity during transmission. 

SecureTransport provides multiple file transport protocol servers: HTTPS, FTPS, AS2, SSH, PeSIT, S3, and many more protocols acting as a client, allowing it to accept and route files to a variety of partner systems and services. Ensuring these connections are secure means configuring them with the right protocol versions and cipher suites. 

TLS versions 

TLS (previously SSL) stands for Transport Layer Security. This is the encryption in transit layer for all file transfer protocols, the only exceptions being SSH (SFTP/SCP) and SMB. 

Best practice is to enable only TLS 1.2 and TLS 1.3. Older versions should be disabled due to known vulnerabilities. SecureTransport’s recent updates have disabled insecure TLS versions by default. 

TLS cipher suites 

Cipher suites are the actual set of algorithms and details that two communicating systems negotiate to use for the encryption of the data they exchange. The negotiation called “handshake” happens before the actual data is transmitted. SecureTransport features all modern approved cipher suites for TLS 1.2 / TLS 1.3. Administrators can customize which ones are allowed, adding outdated ciphers for compatibility with legacy systems. These exceptions should not be left in place without triggering remediation action, even if it involves contacting partners. 

Client and Server Certificates 

TLS secure tunnel is often established by using a specific Client Certificate authentication or Mutual (mTLS) authentication.  

A TLS secure tunnel is often established using client certificate authentication or mutual TLS (mTLS). In a previous post on SecureTransport Authentication & Identity, we discussed how certificates are used to authenticate systems and users. The public and private keys contained in these X.509 certificates participate in the TLS handshake to establish trust and derive the session keys that encrypt the traffic. The way certificates are generated, it matters which algorithms and key sizes are used. 

SecureTransport supports both self-signed certificates and certificates issued by trusted Certificate Authorities for TLS and mTLS authentication. Certificates that rely on outdated or weakened algorithms — such as RSA-1024, DSA keys, or SHA-1 signatures — no longer provide the strength or trust properties required for secure file transfer. 

See also: Here’s how Axway MFT compares to other MFT vendors

Encryption in Transit: SSH security settings 

SSH (SFTP) is the most prevalent file transfer protocol in MFT nowadays.  

Similar to TLS, it has a few settings defining the security of communication. SecureTransport supports all modern algorithms and provides secure-by-default configuration recommendations. 

• Key Exchange (KEX): Establishes the shared session key between client and server.
  Recommended: curve25519-sha256
  Avoid: diffie-hellman-group1-sha1, diffie-hellman-group14-sha1 

• Host Key Algorithm: Allows the server to prove its identity to the client.
  Recommended: ssh-ed25519, ecdsa-sha2-nistp256
  Avoid: ssh-dss (DSA), rsa-sha1 

• Cipher: Encrypts the SSH session traffic.
  Recommended: aes256-gcm@openssh.com
  Avoid: 3des-cbc, aes128-cbc 

• MAC (Message Authentication Code): Ensures the integrity of transmitted data.
  Recommended: hmac-sha2-512
  Avoid: hmac-sha1, hmac-md5 

Encryption at Rest 

Encryption at Rest protects stored data using methods like disk, database, or file-level encryption, including PGP, so that it remains secure even if the storage is accessed by illegitimate actors. 

See also: How to safeguard file transfer from an MFT cyber breach

Repository Encryption 

SecureTransport allows for storing all data encrypted symmetrically with AES-128/256. For more information, refer to the Administrator’s Guide. 

PGP Encryption 

PGP Encryption is widely used in the context of Managed File Transfer as additional protection and guarantee of origin and integrity of individual files or archives. It provides end-to-end encryption by securing the content so that only the intended recipient can decrypt and read it, ensuring confidentiality and authenticity regardless of where the data is stored or transmitted. 

SecureTransport supports PGP encryption and signing directly within routing flows. Each organization manages its own key pair: public keys are shared with partners to encrypt data or verify signatures, while private keys remain confidential and are used for decrypting received data or creating digital signatures. 

The algorithms used to generate the key, its sizes, and the encryption algorithm preferences included in the metadata matter for the cryptographic strength.
RSA with key size 3072/4096 and AES128/256 preferred encryption is the common, secure, and compatible combination. Elliptic curve keys such as Ed25519 are gaining popularity for new systems due to their efficiency and strength, and will be supported by SecureTransport in the near future. Best practice is to avoid DSA keys and 3DES encryption. 

SecureTransport default settings and updates 

Axway SecureTransport provides secure-by-default settings with cipher lists updated regularly as part of the regular product updates. Follow release notes and security announcements to align with best practices. 

FIPS Mode 

SecureTransport allows operating in FIPS 140-3 mode, using only certified algorithm implementations, which is a compliance requirement in regulated industries. It uses the certified cryptographic module BC-FJA (Bouncy Castle FIPS Java API). 

Certificate number: 4943 

Key Management 

Secure key storage 

SecureTransport stores certificates and private keys securely within its internal database, supports lifecycle management via REST APIs, and can integrate with external vaults or HSMs, allowing organizations to build centralized key management and lifecycle aligned with Zero Trust principles 

Certificate lifecycle management 

SecureTransport provides RBAC (role-based access controls), audit logging, certificate and key management, and automatic expiry alerts. However, the establishment of healthy key management practices, log audits, the principle of least privilege, and rotation cadence remains a human responsibility. In SecureTransport, certificates are managed globally or on a per-account basis, allowing importing X.509 certificates in .p12 format, public keys in .pem format, PGP key pairs in .asc (ASCII-Armored) format, and SSH keys in OpenSSH and SSH2 format. 

They fall into the following three types: 

• Login – X.509 certificates or SSH public keys used to establish client identity, authenticating to SecureTransport. 
• Partner – X.509 certificates or PGP public keys – used for PGP and AS2 encryption and signature verification. 
• Private – X509, SSH, and PGP full certificate including private keys – used as Client certificates to login to remote servers, decryption and signing PGP and AS2 data.  

For more information, see the Administrator’s Guide User Certificates section.

External key and secret management: integrating with Vaults and HSM 

SecureTransport can integrate enterprise key management solutions such as HashiCorp Vault, CyberArk, and other vault systems to securely manage encryption keys. For high-assurance environments, it also supports storing private keys in Hardware Security Modules (HSMs), providing an additional layer of security and tamper-resistant key protection. 

Visibility and monitoring 

A system can provide superb visibility over the security settings in use, but it remains a human responsibility to monitor and act when vulnerabilities are identified. 
SecureTransport provides secure default configuration recommendations and alerts administrators with warning log messages when insecure algorithms are used, allowing them to investigate and react. 

Operational reality: managing cryptography at scale 

Managing cryptography at scale across multiple servers, regions, and partner connections is operationally complex. Updating cipher suites across an enterprise requires auditing every SecureTransport instance, identifying active ciphers, assessing partner compatibility, updating configurations, validating the changes, and continuously monitoring the environment. These tasks are slow and error-prone when performed manually.  

SecureTransport’s REST APIs address this by enabling automated auditing, bulk configuration updates, compliance verification, partner onboarding, and controlled temporary exceptions. These APIs also position the platform for emerging automation models, where AI-driven tools can access and orchestrate operations through exposed REST interfaces, including MCP-based integrations. 

Upcoming deprecations 

In 2026, SecureTransport will phase out: 

• SSH DSA host keys 
• CBC-mode SSH ciphers 

Best practices:

• Enforce encryption on all protocols. 
• Audit configurations regularly. 
• Treat exceptions as temporary – not permanent. 
• Rotate keys and certificates proactively. 
• Document cryptographic policies. 
• Train operations teams. 
• Leverage REST APIs for scale. 
• Track SecureTransport updates, release notes, and announcements for security fixes.