What Is SSL Pinning? How It Works and Types (2026)

Every HTTPS connection relies on trust in certificate authorities (CAs). That trust can fail. An attacker with a fraudulent certificate can intercept traffic that looks fully encrypted.

The 2011 breach of DigiNotar, a Dutch certificate authority, showed how. Attackers issued over 500 fraudulent certificates, including one for google.com. They used it to intercept Gmail traffic from users in Iran. DigiNotar went bankrupt within weeks.

The pressure on certificates keeps growing. Since March 15, 2026, publicly trusted TLS certificates expire within 200 days. That limit drops to 100 days in 2027 and 47 days in 2029. Shorter lifetimes change how teams should approach SSL pinning.

SSL pinning adds a second check on top of standard certificate validation. This guide explains how it works, how to implement it, and when it makes sense in 2026.

What is an SSL/TLS Certificate?

SSL (Secure Sockets Layer) (SSL certificate) is the original protocol behind HTTPS. It was retired in 2015. Its successor, Transport Layer Security (TLS), protects HTTPS traffic today. The term “SSL pinning” stuck, so this guide uses it for TLS pinning too.

TLS relies on a chain of trust. When a client connects, the server presents its certificate. The client checks that a trusted CA issued it and that it matches the domain.

The TLS handshake then sets up encryption:

1. Both sides agree on a cipher suite. In TLS 1.3, it names an AEAD cipher and a hash function.
2. Client and server run a key exchange, usually (EC)DHE, to derive shared session keys.
3. The server proves its identity with its certificate and a signature over the handshake.
4. All further data is encrypted with the session keys.

Asymmetric cryptography authenticates the server and protects the key exchange. Symmetric cryptography encrypts the data.

Man-In-The-Middle Attack

In a man-in-the-middle (MITM) attack, an attacker places itself between a client and a server. Neither party knows. The attacker can read, change, or drop traffic in transit.

MITM attacks take a few forms:

• Network-based: The attacker intercepts traffic on an insecure network. A common trick is a fake Wi-Fi hotspot.
• Certificate-based: The attacker gets a fraudulent certificate from a trusted CA. This can happen through a CA breach or social engineering. Mis-issuance is a real risk. Chrome and Firefox distrusted Symantec certificates in 2018 after repeated mis-issuance problems.
• Root key theft: An attacker who steals a CA’s root key can sign fraudulent certificates at will.
• Compromised clients: Malware installs a rogue root CA on the device. The device then trusts the attacker’s certificates.

The impact is direct. If your app handles card payments, an attacker in the middle can capture card numbers.

What is SSL Pinning?

SSL pinning ties an app to a known certificate or public key for a server. The app stores this “pin” in its code or configuration. On each connection, the app first runs standard certificate validation. It then checks that the server’s certificate matches the pin. If either check fails, the app drops the connection.

Pinning narrows trust. A certificate from any trusted CA is no longer enough. The certificate must also match the pin.

Certificate Pinning vs. Public Key Pinning

Certificate Pinning

The app stores the server’s full certificate. The connection proceeds only if the server presents that exact certificate. It is simple to set up. It also breaks every time the certificate is renewed. With 200-day certificate lifetimes in 2026, and 47 days by 2029, that means frequent app updates.

Public Key Pinning

The app stores a hash of the server’s public key, known as the SPKI hash. The server can renew its certificate and keep the same key pair. The pin stays valid.

OWASP’s mobile security guidance favors platform pinning features. Public key pins are the more flexible option. Always ship at least one backup pin. A backup pin is the hash of a spare key you keep offline. If the main key is lost or compromised, you switch keys and the app keeps working.

Static vs. Dynamic SSL Pinning

Static Pinning

Pins are hardcoded in the app at build time. This gives strong protection against fraudulent certificates and compromised CAs. Changing a pin requires a new app release.

Dynamic Pinning

The app receives its pins from a remote configuration. The configuration must be signed and verified, so attackers can’t swap the pins. Pins can then change without an app release. The trade-off is one more component to secure: the pin delivery channel.

Avoid trust-on-first-use (TOFU) designs. In TOFU, the app pins whatever certificate it sees on the first connection. An attacker present at that moment gets pinned.

How Does SSL Pinning Work?

Here is a step-by-step process of how SSL pinning works:

• The client (such as a mobile app) establishes an SSL/TLS connection with the server.
• The server sends its public key, which is used to encrypt the data exchanged between the client and the server.
• The client verifies the server’s identity by checking the server’s digital certificate issued by a trusted Certificate Authority (CA).
• With SSL pinning, the client also checks that the server’s public key matches the hard-coded public key into the client’s code or configuration. If the public keys match, the connection is allowed to proceed.
• If the server’s public key does not match the pinned key, the client assumes that a MITM attack is underway and terminates the connection. This prevents any communication from being intercepted and tampered with.
• If the client needs to update the pinned public key, the app must be updated with a new pinned key.

For example:

A mobile banking app pins its server’s public key. A user connects on public Wi-Fi. An attacker presents a fraudulent certificate signed by a trusted CA. Standard validation passes. The pin check fails. The app blocks the connection before any credentials leave the device.

Image source

The error message indicates that the browser does not recognize the certificate authority (CA) that issued the certificate as a trusted provider or that the server self-signed the certificate.

Is SSL Pinning Still Recommended in 2026?

It depends on the app. Pinning fits high-risk mobile apps, such as banking, payments, and healthcare. It also suits IoT devices and internal clients where you control both ends.

Browsers no longer support pinning. HTTP Public Key Pinning (HPKP) once let websites pin keys in browsers. Misconfigurations locked users out of sites. Chrome removed HPKP in 2019, and Firefox followed in 2020. Certificate Transparency logs now help catch mis-issued certificates.

Three 2026 factors shape the decision:

• Shorter certificate lifetimes: Certificates now expire within 200 days. Leaf certificate pins need frequent updates. Pin public keys or an issuing CA.
• Platform guidance: Android’s developer documentation warns that pinning can break apps when server configurations change. Use pin expiration dates and backup pins.
• Bypass tools: On rooted or jailbroken devices, tools like Frida can disable pinning. Pair pinning with root detection and server-side controls.

SSL Pinning and Post-Quantum Cryptography

Quantum computing adds a long-term risk to TLS. Attackers can record encrypted traffic today and store it. A future quantum computer could break the key exchange and decrypt those recordings. This threat is called harvest now, decrypt later.

SSL pinning does not stop this attack. Pinning checks the server’s identity. Harvest now, decrypt later targets the key exchange that protects each session.

Post-quantum cryptography (PQC) closes that gap. NIST finalized its first PQC standards in August 2024. ML-KEM (FIPS 203) covers key exchange. ML-DSA (FIPS 204) covers digital signatures.

The migration happens in two stages. Each stage affects pinning differently:

• Hybrid key exchange: X25519MLKEM768 pairs classical X25519 with ML-KEM-768. Chrome has shipped it since 2024, and major CDNs enable it by default. It protects recorded traffic. Server certificates and keys stay the same, so existing pins keep working.
• Post-quantum certificates: Servers will later move to post-quantum certificates, such as ones using ML-DSA keys. Their public keys will change. Every pin tied to an old key will fail.

Prepare pinned apps now:

• Add a backup pin for your future post-quantum key as soon as you generate it.
• Use pin expiration dates or dynamic pinning, so pins can change without breaking older app versions.
• Track your CA’s post-quantum roadmap before you lock in new pins.

SSL Pinning and Reverse Proxy Compatibility

Pinning can clash with security tools placed in the traffic path. A reverse proxy, WAF, or CDN terminates TLS before traffic reaches your server. The app then sees the proxy’s certificate. If that certificate doesn’t match the pin, the app rejects the connection.

Three options keep pinned apps working:

• Use your own certificate on the proxy: Upload your existing certificate and private key. The proxy presents the same key the app already pins.
• Pin the issuing CA: Pin the intermediate CA that issues both your server and proxy certificates. This is weaker protection. Any certificate that CA issues for your domain will pass the check.
• Add the proxy’s key as a backup pin: Ship an app update with the new pin before you route traffic through the proxy.

Here is how AppTrana’s flexible SSL configuration options enable complete compatibility with SSL-pinned applications.

Advantages of SSL Pinning

1. Enhances Security: One of the most significant benefits of SSL pinning is that it enhances the security of network communications by adding an extra layer of protection against man-in-the-middle attacks. By requiring a pre-configured certificate or public key, SSL pinning ensures that the client device communicates only with the intended server and not with an imposter.
2. Mitigates Certificate-Based Attacks: Certificate-based attacks, where an attacker can compromise a certificate authority (CA) or issue fake certificates, can be prevented using SSL pinning. By hard-coding the certificate or public key of the intended server, SSL pinning prevents attackers from presenting their own fake certificates and decrypting encrypted traffic.
3. Improves Performance: Another advantage of SSL pinning is that it can improve the performance of applications. Since SSL pinning eliminates the need for the client device to validate the server’s SSL certificate with the trusted CAs, it can save processing time and reduce latency.
4. Ensures Trust: By requiring that the client device verify the server’s identity through a trusted certificate or public key, SSL pinning ensures trust between the client and server.

Limitations of SSL Pinning

1. Complicates Deployment: SSL pinning complicates deployment and maintenance, which is one of its main drawbacks. Since SSL pinning requires that the certificate or public key be hard-coded into the client application, any changes to the server’s SSL certificate or public key will require an update to the client application.
2. Adds Development Overhead: Implementing SSL pinning requires additional development overhead, as developers must ensure that the client application can securely store the pinned certificate or public key.
3. Limits Flexibility: By pinning an app, it becomes cumbersome to change the security certificate. You must update an Android app and send it again to Google Play for your users to reinstall it.

Conclusion

Though this process is tedious and complex, the pinning SSL certificate is worth the effort as it decreases the risk of data leaks and serves as countermeasures against MITM attacks.

Stay tuned for more relevant and interesting security articles. Follow Indusface on Facebook, Twitter, and LinkedIn.