Mutual TLS turns the usual one-way trust of HTTPS into two-way: not only does your app verify the server, the server verifies the client. For a high-security API, that means only clients holding a valid client certificate can connect at all, which raises the bar against unauthorized callers. The catch on mobile is the client certificate's private key: if it ships the same in every install and can be extracted, the control is hollow, like a shared secret. So mTLS is powerful for the right case and only as strong as how you protect the client key. Here is what mTLS is and how to use it on mobile.
Short answer
Mutual TLS (mTLS) is TLS where both sides present certificates: the client verifies the server, as in normal HTTPS, and the server also verifies the client's certificate, so only clients with a valid client certificate can connect. Per OWASP MASVS, it adds client authentication at the transport layer, which suits high-security APIs, but its strength on mobile depends entirely on protecting the client certificate's private key. A static client certificate shipped identically in every install can be extracted, like a hardcoded secret, so the key should be provisioned per device or user and stored in the Keystore or Secure Enclave where it cannot be exported. mTLS authenticates the client or device, not the user, so keep your normal authentication too.
What you should know
- mTLS is two-way TLS: the server verifies the client, not just the reverse.
- It restricts who can connect: only clients with a valid certificate.
- Different from pinning: pinning verifies the server; mTLS verifies the client.
- The client key is the weak point: a shared, extractable cert is not a real control.
- It authenticates client or device, not the user: keep user auth too.
What is mTLS, and how does it differ from TLS and pinning?
It is TLS with client authentication added. In ordinary HTTPS, only the server presents a certificate and the client verifies it, which authenticates the server to the client. In mutual TLS, the client also presents a certificate and the server verifies it, so the connection only succeeds if the client holds a certificate the server trusts. That is a different control from certificate pinning, which is still about the client verifying the server, restricting which server certificate the app accepts to resist interception. mTLS instead restricts which clients the server accepts, so the two are complementary: pinning hardens the app's trust in the server, and mTLS lets the server require a trusted client. For a high-security API, mTLS can ensure that only your authorized app or devices can even reach the endpoint.
When does mTLS help, and what is the mobile challenge?
It helps for high-security APIs, and the challenge is protecting the client key. The table frames it.
| Situation | mTLS value |
|---|---|
| High-security or enterprise API | Strong; only certified clients connect |
| Per-device or per-user client certificate | Strong; the key is unique and protected |
| Static client cert shipped in every install | Weak; the key is extractable, like a shared secret |
| Client key in the Keystore or Secure Enclave | Strong; the key cannot be exported |
| Authenticating the human user | Not its job; mTLS authenticates the client |
The decisive factor on mobile is the client certificate's private key. If you ship the same client certificate in every copy of the app, an attacker can extract it from the binary and present it just like your app would, so the control adds little, the same problem as a hardcoded secret. mTLS becomes a real control when each device or user gets a unique client certificate whose private key is generated and stored in the Keystore or Secure Enclave, where it cannot be exported, so possessing the app is not the same as possessing a usable key.
How do you use mTLS on mobile?
Provision per-device certificates and protect the keys in hardware. Rather than embedding a shared client certificate, generate or provision a unique client certificate per device or user, with the private key created in and held by the Android Keystore or the iOS Secure Enclave so it cannot be extracted, and have the server verify the client certificate against the ones it trusts. Pair mTLS with your normal user authentication, since the client certificate proves which device or app is connecting, not which user, so you still need to authenticate the person. Accept the operational cost: provisioning, rotating, and revoking client certificates is real work, so reserve mTLS for APIs where the extra assurance is worth it rather than applying it everywhere. The principle is that mTLS is strong client authentication only when the client key is unique and non-extractable.
What to watch out for
The first trap is shipping a single static client certificate in the app, which is extractable and reduces mTLS to a shared secret; provision per-device keys in secure hardware. The second is treating mTLS as user authentication, when it authenticates the client or device, so keep your user auth. The third is underestimating the operational cost of managing client certificates. A pre-submission scan such as PTKD.com (https://ptkd.com) reads the compiled APK, AAB, or IPA against OWASP MASVS and surfaces embedded certificates and keys, so you can confirm a client certificate is not shipped statically in the binary. The provisioning and server-side verification you implement in your system.
What to take away
- Mutual TLS adds client authentication to TLS: the server verifies the client's certificate, so only clients with a valid one can connect, complementing certificate pinning, which verifies the server.
- Its strength on mobile depends on the client key: a static certificate shipped in every install is extractable and weak, like a hardcoded secret.
- Provision per-device or per-user client certificates with private keys in the Keystore or Secure Enclave, and keep normal user authentication, since mTLS authenticates the client, not the user.
- Use a pre-submission scan such as PTKD.com to confirm no static client certificate or key is embedded in your build.
