We have recently engaged an external party to undertake a pen test on a recently implemented API. The API is considered internal although it itself is on AWS and is consumed from on-prem resources, the connectivity between the 2 is using multiple security devices to effectively create a single network.

The API is secured by mTLS, we do not check anything further than the validity of the client certificate. This pattern has been approved internally by our Group Security. The PKI infra is all internal and is behind a robust set of processes for issuance of certificates.

The following comment was made in the report;

While mTLS to allows the client and server to establish a secure connection with each other, it would be considered security best practice to include an additional layer of authentication or message signing to ensure that the requests have originated from a trusted source

I have never heard of this as a best practice and wanted to get the opinion of others that are likely to have more experience.

So, is mTLS alone sufficient for client authentication?

  • 2
    It would be interesting to ask the person that wrote this to describe an attack that would overcome mTLS, but would be prevented by this 'additional layer of authentication'. mTLS will fail if the server does not authenticate the client's certificate correctly, or if the client's private key is compromised - but the 'additional layer of authentication' would fail as well in these circumstances. Recommending a roll-your-own solution on top of a a tried-and-true, mature, well-vetted secure protocol like mTLS would seem to add complexity, without adding any real value when it comes to security.
    – mti2935
    Sep 12, 2023 at 19:03
  • Do all clients use the same client cert? Or each client has its own cert? Also, does any client act as a proxy to other entities?
    – user284677
    Sep 13, 2023 at 19:54
  • Each client would have a unique cert and none are proxies.
    – Kinexus
    Sep 13, 2023 at 20:29
  • Just to be clear, when we say "client" we mean "application", right? So, if two clients (applications) run on the same host, they would have different certs, correct?
    – user284677
    Sep 14, 2023 at 7:30
  • Yes, each application that connects to the API has a unique cert. We do have 2 applications that talk to this API and each has their own cert. These applications also talk to other APIs secured with mTLS and those again have a unique cert, so we can revoke a single cert and know exactly what service is then affected.
    – Kinexus
    Sep 15, 2023 at 17:31

3 Answers 3


Summary: in your case, mTLS alone suffices for client authentication; but in principle, the pen-testers' suggestion is not invalid

Explanation: Based on the details provided in the question and your comments (here and here), this is your setup:

  • there are two applications that talk to APIs
  • each application has a different cert for each API that it talks to, no cert is shared between the applications and/or between an application and any two APIs
  • no application acts as a proxy to other applications
  • you're using mTLS as a means to authenticate the peers (clients/servers)

Since each cert is unique per application per conversation (app <-> API), it can be safely used to identify each application; there's no need for another layer of authentication.

Concerning the suggestion from the pen-testers, I'm not sure whether they based it on any info not present in your question, or they provided it as a general remark/best practice. However, in principle, there is a foundation for it:

  • (m)TLS does not operate at the application (OSI) layer, which means that when it comes to application-level logging, getting authentication info per request isn't straightforward. This is a problem when it comes to incident response and forensics. Adding an application identifier that will "escord" each request, will make your life easier. This application identifier usually comes under the umbrella of authentication, because it should (ideally) be pre-approved before it's used (e.g. an API key or access token)

  • there's the concept of multi-layer (or multi-level) authentication (MLA)1. MLA suggests that you should use the same single factor authentication multiple times when a subject requests access to objects. MLA is used extensively in physical security (e.g. an employee accesses restricted building areas by using his id card to open each door leading to each restricted area, after he uses his id card to enter the building). MLA can also be used in cases where there's a TLS termination proxy between a client and an API and you implement zero trust security; there can be an initial client authentication using mTLS, but (because each client request is forwarded to the internal API) the API also has to authenticate the request origin before serving it

Nevertheless, it's clear that the last point does not apply to your case (I'm not sure about the first one, either). So, I don't see how the suggestion is relevant to your case, nor how beneficial it would be to add another layer of authentication.

1 See here (link to a blog page of a company that I'm not affiliated with) and here for explanations on the concept of MLA


Yes, mutual TLS (mTLS) is sufficient for client authentication.

With mutual TLS, the client knows it is actually talking to the server, and the server is actually talking to the client. Both parties have to present a valid certificate. The actual security of this depends on the security of the certificate authority, how easy it is to obtain a valid certificate, and when the client and server consider a certificate valid. For example, certificate pinning can introduce further restrictions on which certificates are valid.

Some security professionals consider mTLS to be better than most other forms of authentication, such as API keys or credentials.

it would be considered security best practice to include an additional layer of authentication or message signing

This is not irrefutably true. There is no consensus that this is a security best practice.

It is perhaps a bit unclear for mTLS, but there is a consensus that single-sided TLS is secure, and you don't need additional (server) authentication or encryption on top of TLS. However, a number of incidents has also shown that it is hard to run a secure CA.

  • 1
    It's a very good answer and I just wanted to add that both sides may not even share the same CA - they can come from separated roots of trust. When their certificates are properly validated, CAs are secure, private keys securely managed, key lengths and ciphers used for authentication and session negotiation are strong enough then mTLS is sufficient. It is also still worth noting, that certificates are not the only option to establish mTLS sessions - pre-shared-key is also available. So it's usually not the mTLS but its usage where things go wrong. Threat model could say if mTLS alone is OK Sep 13, 2023 at 11:59
  • I would add that both client and server do share the same CA in this situation.
    – Kinexus
    Sep 13, 2023 at 20:30

IMHO this can be an infrastructure question. Where is the list of valid client CAs? If it resides in a file on an external machine, could a rogue admin add an additional CA there? If the answer is yes, then despite the robustness of mTLS, you have a possibility of attack by adding new clients.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .