Security series by Axway MFT experts — SecureTransport Authentication

Axway MFT product experts are continuing the MFT Security Series. At the end of last year, we kicked off the series with a deep dive into external stores, a separate centralized location for your credentials and keys.  

Today, we are continuing the series, and we return to the essential basics.  

Security starts with authentication 

When people and organizations consider security in the MFT context, they often focus on encryption algorithms, protocol security features, or addressing security audit recommendations needed to meet compliance standards. Several controls may be introduced early in the sequence of steps required to transfer a file securely. Load balancers, firewalls, IP whitelisting, along with other perimeter decisions, are all important measures to secure the flow of your data.  

Although these features are essential for a modern file transfer platform, security ultimately begins with establishing a trusted identity through strong authentication mechanisms. 

While files can be encrypted, safely routed, scanned, and audited, there’s still one question to ask: can we trust an identity before allowing access to a file? Or granting this identity access to control the entire system? Before we can trust a person or system enough, how do we know they are really who we think they are — is a password entered somewhere by someone or something sufficient for us to trust it with our business? 

In Axway’s SecureTransport, authentication functions as a gatekeeper that determines who can log in to the system, which systems can automate transfers, and which partners are allowed to connect.  

MFT systems, particularly gateways, are attractive targets for security attacks. Sitting at the intersection between organizations, gateways manage a large amount of sensitive data and connect to internal systems directly. Often, file transfer systems run unattended while handling sensitive data. A gateway opens the door into files and the entire integration system.  

Different identities, different authentication 

Let’s start with the basics: Who are your users? How many categories of MFT users do you have? If your answer is “none” or “one”, it may indicate a flaw in the authentication infrastructure.  

The first and primary distinction that users encounter when they log in to SecureTransport is the differentiation between Administrators and End Users. We also usually subdivide users into three categories:  

• Human users: administrators and operators of MFT inside your organization 
• Automated service users: APIs, batch jobs, scheduled transfers 
• Internal and external partners: customers, suppliers, regulators outside of your organization 

When it comes to authentication, treating these categories as one is incorrect. Each of these users may constitute a risk, and mitigation requires a system of authentication that is cognizant of the particular danger that each category may present. Correctly implemented authentication applies correct controls to each corresponding category of users.  

In this post, we will cover traditional authentication methods like username/password and certificates, and modern identity integration methods like single sign-on, OAuth, and multifactor authentication. We will then break down which methods are the best for each user group outlined above, and how Axway’s SecureTransport supports targeted authentication for best security.  

Traditional authentication 

We distinguish two types of traditional authentication: password-based and certificate-based. 

Basic password-based authentication 

The first and most tried-and-tested authentication method is a simple combination of a username and a password. They are easy to deploy, so familiar that we all use a password for an online service every day, and sometimes unavoidable even in most secure modern systems. 

Even if you have a state-of-the-art, modern security system, it is very likely that you have that one external partner that still relies on a legacy solution. SecureTransport supports connectivity even with legacy systems, but from a security standpoint, it is important to remember that passwords are the most frequently targeted authentication methods. Knowing that, here are a few situations where using a username/password combination is still widely used in low-risk scenarios, like read-only view for limited admins or test cycles 

Passwords need to be strengthened by strict password policies, frequent rotation, or external controls such as access through a hardened bastion host or VPN gateway. 

In general, however, organizations now move towards more sophisticated, privileged, and internet-facing access toward federated identity and away from the username/password approach.  

Certificate-based authentication 

Certificate-based authentication is commonly used for system-to-system automated communication. It is often implemented through mutual TLS or protocol-level mechanisms. Certificates provide a strong cryptographic identity, removing the risk of sharing secrets. This feature makes certificates a natural fit for automated integrations, high-volume file transfers, and regulated partner connections. 

However, using certificates brings in an operational trade-off. The security success of certificates relies not on using certificates, but on the correct management of their lifecycles. Your system security is just as strong as your process of issuing, rotating, and revoking certificates.  

Axway SecureTransport offers certificate-based authentication for client- and server-initiated transfers, integrations with external databases, and other system-to-system interactions. It also sends advanced notifications for certificate expiration to ensure timely certificate management. 

Modern authentication methods 

The latest security advancements and organizational movement towards strategies like Zero Trust and Identity and Access Management (IAM) force a shift from individual applications to centralized identity platforms. This shift has introduced modern and more secure methods of authentication like single sign-on (SSO), OAuth 2.0, OpenID Connect (OIDC), and multifactor authentication (MFA).  

Axway SecureTransport integrates these features to support organizations’ move toward more secure file transfer systems and partner communication. 

Single sign-on (SSO) 

Single sign-on is a feature that has become just as familiar to everyday online users as entering username/password combinations. SSO allows organizations to have their authentication handled by an external Identity Provider. That way, your MFT system becomes a part of the organization’s broader identity.  

SSO is best used for centralized access governance and consistent onboarding and offboarding of partners and employees. Integrating SSO into your MFT system helps reduce password sprawl and makes the enforcement of conditional access policies easier. SSO provides stronger protection for higher‑risk scenarios than a simple password. We recommend using SSO for all internal administrator‑level access as well as for end‑user authentication within the organization. Axway SecureTransport supports consistent authentication policies and centralized identity governance through the enterprise IAM system.  

OAuth 2.0 with OpenID Connect 

The talk about automation is everywhere, and our conversations with security architects illustrate this trend well. Automation tools like scripts, data pipelines, or scheduled tasks tend to store lots of secrets. When this process has been happening for years, the sprawl of these unmonitored credentials gets out of control. As highly automated environments that store static credentials, MFT systems tend to fall into this category. OAuth was introduced to mitigate the risk of scattered credentials with regained control and high visibility.  

OAuth replaces the need to share static secrets and instead issues short-lived tokens that provide temporary and limited access to your systems. This technology gives far more control over access and authentication than traditional APIs and other methods. However, OAuth doesn’t fully eliminate risks, as tokens can be misused if the system has poor governance.   

Multifactor authentication  

Multifactor authentication, or MFA, has a reputation for causing slight annoyance for users. But the need to enter a one-time password from a text message or verify your login in an app is a small price to pay for a strong security system. 

Multifactor authentication is a strategy rather than a single technology. It mitigates the loss or theft of an authentication method by requiring two or more independent authentication methods to verify the identity of these three categories of user authentication: 

• Something a user knows: a password or a PIN. 
• Something a user has: a cryptographic key, a certificate, or a hardware token. 
• Something a user is: biometric information, like a fingerprint or face. 

That way, if a password had been compromised or a certificate that should have been revoked is still valid, it wouldn’t help a malicious actor get into your system. However, MFA is not a one-size-fits-all full security solution either, and there are still security risks associated with this strategy. 

Risks associated with multifactor authentication 

There are traditional and widespread MFA methods that we all see in our daily lives. A one-time password (OTP) sent over a text message or an email has become a regular event for all Internet users. Some users get push notifications on their phones that require them to verify a login using their fingerprint or face. This practice, however, is also well-known to malicious actors.  

Not all MFA methods are created equal. Less sophisticated methods, like the ones described above, are still susceptible to phishing and push bombing, or “MFA fatigue.” While MFA is a useful security strategy, it is not a replacement for other security measures like limited and least privilege access in low-to-medium risk situations. 

In high-risk situations, security teams can align their MFA methods to the risk itself. Privileged and admin access can be protected using phishing-resistant MFA methods like FIDO2/WebAuthn that can be supported with an external IdP like Okta or Keycloak. These methods provide password-less access with a user’s biometrics as verification, or by verifying a private hardware token, enforced consistently through a single sign-on/IAM layer. For push bombing prevention, use prompt context or number-matching controls. Non-interactive users like automation and partners that can’t use interactive MFA, use possession-based cryptographic factors like certificates or keys, and ensure least privilege access.  

MFA is one of the simplest and one of the most effective controls to deploy. But it is also one of the fastest to degrade over time if it is unattended. The best way to use MFA is to treat it as an operational loop by monitoring authentication events, defining recovery procedures, and reassessing factors periodically as threats evolve.  

Multifactor authentication in SecureTransport 

Axway SecureTransport supports multifactor authentication patterns directly at the file transfer layer. The most common combination of factors we see in SecureTransport usage is a combination of a knowledge factor and a possession factor, usually requiring both a username/password and a client certificate. That way, a compromised password is insufficient, and theft of a certificate is useless, as the possession factor alone is not enough.   

But notice how this approach doesn’t rely on the interactive MFA process and factors that people use in their everyday lives, like a one-time password or a biometric scan. This authentication strategy is not susceptible to MFA phishing and push bombing methods, and such a model suits well for system-to-system integrations, automated transfers, and partner connections.  

For interactive users, such as MFT administrators and end users, SecureTransport has an option to integrate with enterprise Identity and Access Management platforms that enforce MFA externally via single sign-on. MFA can also be enforced via the external Identity Provider. This strategy helps teams apply MFA consistently across systems, keeping authentication decisions centralized. It also helps evolve MFA strategies as threats evolve without changing applications.  

All these methods use MFA, but they differentiate between different kinds of users that we covered at the beginning of this post. Human users (administrators and operators) are authenticated with IdP-enforced MFA, while automated users and external partners utilize non-interactive possession-based options combined with credentials.  

Custom authentication 

Sometimes the common methods are not enough. Some environments require custom authentication logic, for example, special partner onboarding or non-standard identity sources.  

SecureTransport supports custom authentication logic with a pluggable framework for different scenarios. As custom authentication is implemented in SecureTransport, it still relies on the same security principles as the common methods described in this post:  

• Strong identity proofing 
• Least privilege access 
• Auditability 

Keep in mind that a correctly executed custom authentication doesn’t bypass security controls, it should be integrated with them. 

Choosing the right authentication strategy 

As we covered throughout this post, different kinds of users and different kinds of situations require different kinds of authentication. We have noticed this pattern in our customers — most SecureTransport deployments use multiple authentication methods.  

This is a common breakdown of authentication methods for each role: 

• End users: OAuth 2.0 / OIDC with MFA 
• Administrators and operators: OAuth 2.0 with MFA 
• APIs and automation: OIDC 
• External partners: certificates or SSH keys 
• Legacy access: credentials with password complexity requirements 

We recommend that organizations combine a strong authentication strategy with the Zero Trust methods and focus on protecting high-impact identities like administrators.  

Security Series continues 

Last month, we covered external stores and how they can strengthen your security posture amidst the evolution of threats. This post covers the foundations of authentication and how identities are verified in Axway Managed File Transfer and SecureTransport before any transfer can even begin. 

In the next parts of the Security Series, we will take a closer look at the following topics: 

• OAuth and OpenID Connect (OIDC), and how they help enable secure, token-based access for MFT automation and API-driven workflows. 
• Transport security and cryptographic strength, including TLS version and cipher suites, and why enabling TLS is not a replacement for a well-governed security system. 
• Certificate-based authentication and machine identity, covering system-to-system authentication, certificate lifecycles, and how certificates are used in modern MFT. 

Our goal is to build a layered security story throughout this series: from human users in legacy systems using a 20-character password to authenticating modern automations and workflows.