mTLS, API Security and Secure Connectivity

Mutual TLS, known as mTLS, is TLS where both sides prove their identity with certificates. In ordinary TLS, only the server proves who it is. In mTLS, the client also presents a certificate, and the server checks that certificate before it accepts the connection. A payment hub that connects to a clearing system, or a corporate treasury system that connects to a bank API, should use mTLS so that an attacker cannot pretend to be a trusted partner. If the certificate is expired, revoked or issued by an untrusted authority, the connection must be refused, and the failure must be logged. API security starts with strong authentication and authorisation for every call. An API that creates a payment must check that the caller is authenticated, that the caller has permission to create payments for that account, and that the payment is within the agreed limit. A read only token that can view balances must never be able to create a payment of 250,000 pounds. Scopes in OAuth2 enforce this separation, and the API must check the scope on every request, not only at login. An API that trusts the client to behave correctly is not secure, it is only hopeful. APIs also need protection against abuse, replay and injection. Rate limiting stops an attacker from sending thousands of requests in a minute to guess account numbers or to overwhelm the system. A unique idempotency key on each payment request stops a retry from creating a duplicate payment, so that a 40,000 euro payment sent twice with the same key is processed only once. Input validation must reject unexpected fields, oversized amounts and malformed JSON, and error messages must not reveal internal details such as database names or stack traces that help an attacker. Secure connectivity also covers the network path between systems. Payment APIs should be exposed only through an API gateway that enforces authentication, logging, rate limiting and IP allow listing. Internal payment services should sit in a private network segment, with no direct access from the internet, and with firewall rules that allow only the specific ports and hosts that are needed. A bank that exposes a payment service directly to the internet, without a gateway or network controls, has removed several layers of defence that would otherwise slow an attacker down. A reviewer should test API security with real calls, not only with documents. The reviewer should try to call the payment API without a token, with an expired token, with a token for a different customer, and with a token that has read only scope. Each attempt must fail with a clear 401 or 403 response and no money movement. The reviewer should also try to replay a payment request, to send a duplicate idempotency key, and to exceed the rate limit. If any of these tests succeeds when it should fail, the API is not ready for production, and the finding must be fixed before real payments flow through it. API abuse protection is a layered defence, and each layer stops a different attack. Rate limiting stops an attacker from sending thousands of requests in a minute to guess account numbers or to overwhelm the system; a typical limit is 100 requests per minute per client, with a 429 Too Many Requests response when it is exceeded. Idempotency keys stop replay attacks: every POST that creates a payment must carry a unique Idempotency-Key header, and resending the same key returns the original response instead of creating a duplicate payment. Input validation stops injection: every field is checked against its expected type, length, and format before it reaches the business logic. Secure connectivity also covers the network path between systems, and the API gateway is the control point. Payment APIs should be exposed only through an API gateway that enforces authentication, logging, rate limiting, and IP allow listing. The gateway should reject any request that does not come from an allow-listed IP address, and it should log every request with a timestamp, a client identity, and a payment reference. Direct access to the payment engine, bypassing the gateway, must be blocked at the network level. A business analyst specifying an API integration must define the gateway rules, the allow list, the rate limits, and the logging requirements, because these are the controls that keep the API from being abused. A worked example shows mTLS in action. A corporate treasury system connects to the bank API to pay 500 suppliers. The connection uses mutual TLS: the bank presents its server certificate, and the treasury system verifies it against its trust store, confirming it is talking to the real bank and not an impostor. The treasury system then presents its client certificate, and the bank verifies it, confirming the caller is the registered treasury system and not an attacker. Only after both certificates are verified does the TLS handshake complete and the API call proceed. The client certificate is issued by the bank, has an expiry date of one year, and is stored in a hardware security module at the client, so it cannot be copied. If the certificate expires, the connection fails and the treasury system cannot send payments until a new certificate is installed. For a business analyst, the requirement is to define the certificate issuance process, the expiry notification, the rotation procedure, and the error returned when a certificate is expired or revoked. A failure scenario tests certificate handling. A bank revokes a client certificate because the client reports it may have been compromised. The client continues to use the revoked certificate, because its system was not updated. The bank's API gateway checks the certificate revocation list on every connection and rejects the call with a TLS handshake failure. The client receives no HTTP response at all, because the connection is refused before HTTP begins. The client's system must handle this: it must log the TLS failure, alert the operator, and not retry indefinitely, because retrying with a revoked certificate will fail every time. The operator must install the new certificate and verify the connection works. A client that does not monitor its certificate expiry will discover the problem when payments stop, which is the worst time to discover it. Last reviewed 7 November 2026. Further reading: RFC 5246 TLS; bank API developer documentation; SWIFT Customer Security Programme.