Mutual Authentication

Mutual authentication is a security process in which two parties each prove their identity to the other before they exchange sensitive data or instructions. In ordinary web browsing only the server proves who it is, by presenting a certificate to the browser; the user's identity, if checked at all, is confirmed later with a password. With mutual authentication, the client must also prove its identity at the start of the connection, usually with its own certificate and private key. Banks, payment processors, open banking platforms and card systems use it wherever both sides need strong assurance about who they are dealing with.

The best-known form is mutual Transport Layer Security, often written mTLS, in which both the client and the server present digital certificates during the encrypted handshake. Mutual authentication is a specific case of authentication and depends on a working public-key infrastructure to issue, check and revoke the certificates involved.

In a standard Transport Layer Security connection, the server sends a certificate, the client checks that it was issued by a trusted certificate authority and matches the server's name, and the two sides agree encryption keys. Mutual TLS adds a step: the server asks the client for a certificate, and the client sends one and proves it holds the matching private key by signing part of the handshake. The server then checks the client's certificate against its list of trusted issuers and, often, against a list of specific clients it has agreed to serve.

If either check fails, the connection is refused before any application data is sent. This protects against attackers who have obtained a password or API key but do not hold the client's private key, and against attackers who try to impersonate the server.

Open banking regimes rely heavily on mutual authentication between banks and the third parties that access customer accounts. Under the Second Payment Services Directive (PSD2), account providers must allow licensed third-party providers to identify themselves when using the bank's dedicated interface. In the European Union this is done with qualified certificates issued under the eIDAS regulation, which record the provider's licence number and its authorised roles.

In the United Kingdom, participants use certificates issued through the open banking directory, which also lists which firms are authorised. Security profiles such as the Financial-grade API (FAPI) profile, developed by the OpenID Foundation, use mutual TLS to bind access tokens to the client's certificate, so a stolen token cannot be used by another party. A bank's open banking API therefore usually checks both the certificate on the connection and the token in the request.

Connections between banks, clearing houses, card processors and large corporate clients commonly use mutual authentication. Host-to-host links for sending payment files, connections to real-time payment systems, and links between payment facilitators and their acquirers often require client certificates in addition to network controls. The SWIFT network uses its own public-key infrastructure so that each institution's messages can be authenticated, and the institution in turn authenticates the network. These arrangements support merchant authentication and partner authentication in high-value channels.

The idea also appears in EMV chip transactions. During an online authorisation, the card produces a cryptogram that the issuer checks to confirm the card is genuine. The issuer can return its own cryptogram in the response, which the card checks to confirm the reply really came from its issuer, a step called issuer authentication. Together, these checks give both the card and the issuer confidence that neither the card nor the response has been forged.

Mutual authentication offers strong protection against impersonation, credential theft and some interception attacks, and it gives each party a reliable record of who connected. It is particularly useful for machine-to-machine connections, where there is no human to complete a one-time passcode.

The main challenge is certificate management. Each client must obtain, install and protect a private key and certificate, renew it before it expires and replace it if it is compromised. Expired certificates are a common cause of outages in payment connections. Systems such as load balancers and API gateways must be configured to pass certificate details correctly, and certificate revocation lists or online status checks must be maintained. For these reasons, organisations usually automate certificate issuance and renewal and keep an inventory of every certificate used in their payment links.