TL;DR#

Fragility and Risk of Outages#

Pinning makes your app’s connectivity tightly bound to a specific certificate or key, which will inevitably change over time. Certificates expire (often yearly, as industry rules now cap their validity), CAs may rotate or be replaced, or you might switch to a different certificate provider. When that happens, a pinned app will break, it will refuse to connect to the server because the “expected” certificate changed.

The only fix is to release an app update with the new pin, and all users must upgrade before connectivity is restored. This creates a serious risk of downtime.

“If the pinned certificate changes due to renewal, revocation, or CA migration, the application will stop working until a new version of the app with an updated certificate is released,“
as one 2025 analysis noted, meaning apps can suddenly break and critical services become unavailable until a fix is deployed and adopted.

Google’s official Android guidance explicitly cautions that certificate pinning is not recommended because “future server configuration changes, such as changing to another CA, will render apps with pinned certificates unable to connect to the server without a client software update.”

In other words, pinning couples your app to your current certificate infrastructure so tightly that any routine change becomes a potentially breaking change.

High Maintenance Overhead#

Because of the fragility above, using pinning responsibly requires meticulous planning and maintenance. Developers need to anticipate certificate rotations and have processes in place to update pins proactively.

Best practices for pinning call for including multiple backup pins (e.g. pinning to a set of public keys) and short pin lifetimes, in an attempt to mitigate the risk of lockout.

Apple’s documentation warns that if you do pin, you must “think long term” and plan for both planned and unplanned certificate changes, including shipping app updates on short notice if something changes. Many teams simply do not have the operational rigor to manage this without error.

Real-world incidents show that organizations often forget about pins they set. For example, Cloudflare observed a surge in customer outages in 2024 after routine certificate authority changes,

“almost all customers that were impacted by the change were unaware that they had a certificate pin in place.”

These teams had adopted a “set and forget” mentality, only to have their apps suddenly unable to connect when the backend’s certificate chain changed.

In today’s agile DevOps environment of frequent certificate renewals, pinning turns certificate management into a landmine; if you’re not extremely careful, a normal cert update could brick your app’s network functionality.

Limited Security Benefits (and False Sense of Security)#

Ironically, the security gains from pinning are not as strong as they once appeared. Pinning is a client-side control that can be bypassed by determined attackers who have control over the runtime environment.

Security testers and malicious actors routinely use tools like Frida (a dynamic instrumentation toolkit) or custom frameworks to hook or modify app behavior and disable SSL pinning checks at runtime.

In other words, an attacker who is sophisticated enough to perform an active MITM on your app is likely capable of also defeating pinning (by rooting/jailbreaking the device or using instrumentation). This means pinning often only stops casual or passive attackers, but not a dedicated adversary, giving developers an illusion of security.

As one industry blog put it:

“SSL pinning is often recommended as a best practice, but in reality, it is an illusion of security … it can easily be bypassed by attackers, making it more of an inconvenience for developers than a robust security measure.”

Also, consider the scenario of a compromised server key: if the very certificate or key you pinned is stolen by an attacker, pinning won’t help, the attacker can then impersonate the server with the valid certificate, and the app will happily trust it.

Pinning doesn’t account for key compromise (whereas the broader PKI ecosystem at least attempts revocation, etc.). In summary, pinning is not a silver bullet, it stops some attacks, but is far from foolproof.

No Protection Against CA Ecosystem Improvements#

The original motivation of pinning, fear of rogue CAs, has been largely mitigated by improvements in the industry (more on this later). Browsers and operating systems have become much more aggressive at policing CAs and reacting to mis-issuance. Major tech companies maintain tight control of root trust stores and have shown willingness to rapidly distrust CAs that go astray.

Initiatives like Certificate Transparency (CT) now provide visibility into every certificate issued, making it hard for a bad cert to go unnoticed. In essence, the public PKI infrastructure is more secure and agile than it was a decade ago, with shortened certificate lifetimes and automated issuance.

The cost-benefit equation has changed: the risk of a rogue certificate (which pinning would protect against) is now quite low, whereas the risk of your own app breaking due to pinning is comparatively higher.

The OWASP Foundation’s guidance as of 2025 concludes that:

“Considering the current risks in the CA and browser space and comparing them to the risk of down time, pinning is not recommended.”

In short, the security community believes the web PKI + modern enhancements can be trusted enough in most cases, such that pinning’s marginal benefit isn’t worth its very real costs.

Misuse and Implementation Pitfalls#

Pinning is tricky to implement correctly. Many developers in the past have made mistakes like:

• pinning the leaf certificate only (which changes at every renewal),
• pinning only one of several backend hosts,
• not providing a graceful fallback.

A notorious example in web security was HTTP Public Key Pinning (HPKP), a now-deprecated mechanism where servers told browsers to pin keys, many sites ended up bricking themselves by pinning incorrectly (so much so that browsers removed HPKP support entirely by 2019).

In mobile apps, a common mistake is failing to include a backup key. Both Android and iOS docs urge that if you must pin, include multiple pins (e.g., the current key and a future key under your control, or pin a CA’s key).

Another pitfall is developers sometimes confuse certificate validation with pinning and accidentally disable validation, thinking they’ll “do pinning manually.” Google explicitly warns against solutions that install a do-nothing TrustManager (which accepts all certs), that’s worse than no pinning, as it disables security entirely.

Overall, there’s a lot of room for error, and an improperly implemented pin can downgrade security or cause needless failures. It’s a fragile mechanism requiring careful engineering discipline that many teams lack.

Interference with Debugging, Testing, and User Environments#

SSL pinning doesn’t just hinder attackers, it can hinder legitimate scenarios too. Developers and QA/Security testers often need to intercept HTTPS traffic for debugging (using tools like Charles Proxy or Burp Suite), but a pinned app will simply refuse to connect through these tools because the proxy’s certificate isn’t the pinned one.

This means teams have to build backdoors or special debug builds without pinning to allow testing, adding complexity. From a penetration testing perspective, pinning can slow down the assessment (testers must use jailbreak/root techniques to bypass it), but as noted, it’s not a serious roadblock, just an inconvenience.

More importantly, pinning can disrupt real-world network environments. Many enterprise networks and antivirus products legitimately intercept TLS traffic (with the device’s consent) to scan for threats, using a private CA installed on the device.

A corporate employee running your app behind such a proxy or a user with a network security tool might find your app doesn’t work at all due to pinning. As OWASP notes:

“Many corporate environments use MITM based TLS inspection, which issues cloned certificates from a corporate trusted CA. While the naming information would match, the certificate’s public key would not. This could create an unintended denial of service on the application.”

In other words, your app could be completely unable to function on certain networks because it rejects the proxy’s certificate, even if that proxy is trusted by the operating system. This makes pinning a liability in terms of compatibility and user experience.

It can also complicate operational troubleshooting: if an outage occurs (say your server switches to a new cert chain), it might not be immediately obvious to developers that the pinning is the culprit, leading to longer downtime.

Given these issues, it’s no surprise that platform providers have changed their stance. Google’s Android team and Apple both discourage SSL pinning for most apps.

The Android Developers Guide bluntly states that pinning:

“is not recommended for Android apps”

due to exactly the kinds of fragility and maintenance problems described.

Apple’s guidance is similar: an official Apple Developer Technical Note from 2021 emphasizes that:

“Pinning certificates is not required” for security and “in most cases, pinning is not necessary and should be avoided”

with default TLS trust sufficing for the vast majority of apps.

Both Google and Apple essentially ask developers: are you sure you need to do this? Only in very special circumstances (like complying with a specific regulatory requirement to trust a private CA, or an extremely high-risk threat model) might pinning be justified, and even then, it must be managed carefully with fallback plans.

The overarching message is clear: SSL pinning has become a legacy approach and is no longer a best practice for mobile app security.

1. Rely on the Built-in PKI and Trust Stores#

Both Android and iOS maintain a system CA trust store that is continuously updated with trusted root certificates. These platforms (Google, Apple, Mozilla, Microsoft) collaboratively manage trust and will revoke or distrust bad CAs to protect users.

Unless you have a specific need, trust the system to do its job. The major OS vendors have made security of the certificate ecosystem a priority and have far more resources to evaluate CAs than any individual app developer.

In modern Android and iOS, apps by default trust only well-vetted public CAs (and on Android, user-added CAs are not trusted by apps targeting recent API levels, unless you opt-in). This significantly limits the risk of a rogue certificate being accepted.

In essence, leveraging the default PKI means you inherit improvements like CA/Browser Forum governance, browser/OS root programs, and timely security updates. Pinning is usually unnecessary because the default trust model is robust for most use cases.

2. Enable Certificate Transparency (CT) and Monitoring#

Certificate Transparency is a system of public logs that record all certificates issued by publicly trusted CAs. CT has become mandatory for CAs (browsers will distrust certificates not present in CT logs).

Mobile apps can take advantage of this by requiring CT compliance and monitoring logs for their domains.

• Android: Network Security Configuration allows an opt-in for certificate transparency, meaning your app will only accept certificates that have valid SCTs (Signed Certificate Timestamps) proving they were logged in CT.
• iOS: Provides the NSRequiresCertificateTransparency flag in App Transport Security to require CT for certain domains, as noted by Apple’s engineers.

Enforcing CT means that if someone (even a trusted CA) tries to issue a certificate for your domain behind your back, it would not be accepted by the app unless it’s publicly logged (and you could detect it).

Apple’s security team has highlighted CT as a “great tool” to verify server certificates and recommended checking for CT compliance when evaluating a server’s trustworthiness.

In practice, you should also set up CT monitoring: there are services (and free tools) that alert you if a new certificate for your app’s domains appears in the logs. This way, you can quickly respond to any misissued or malicious certificates (e.g., by revoking them or alerting the CA) without needing to pin.

CT provides transparency and accountability in the certificate ecosystem, covering the threat that pinning was meant to catch, but in a far more flexible way.

3. Use HSTS and Secure Server Configurations#

On the server side, enable HTTP Strict Transport Security (HSTS) for your domains. HSTS instructs browsers (and by extension in-app web views) to never downgrade to HTTP and to automatically redirect to HTTPS.

While a mobile app’s own network calls will typically be coded to use HTTPS already, HSTS is still valuable if any part of your app uses web content or if users might interact with links to your domain. It eliminates certain MITM tricks (like stripping HTTPS to HTTP).

Moreover, even though mobile apps don’t inherently parse HSTS headers, having HSTS on your API domain means if someone tries to access it via a browser (for example, an OAuth login flow or a user following a link), they’ll be protected.

Consider getting your domain on the HSTS preload list if appropriate, which ensures all clients know to use HTTPS from the first visit.

Alongside HSTS, make sure your TLS configuration on the server is solid:

• Support the latest protocols (TLS 1.3 and 1.2, drop older versions).
• Use strong cipher suites.
• Keep your server’s TLS library up to date.

The good news is that mobile platforms enforce this to some extent:

• iOS’s App Transport Security by default requires TLS 1.2+ and reasonable ciphers.
• Android will by default use TLS 1.3 when available.

So adhere to those defaults, don’t weaken security by allowing old protocols. Enabling features like OCSP Stapling and checking certificate revocation status can also help (though revocation checking in mobile apps can be tricky and is often bypassed if not stapled).

In summary: treat your server’s TLS config with the same care as you would for a banking website: score an “A” on SSL Labs, use modern TLS and strong algorithms. A robust TLS setup reduces the risk of any successful MITM.

4. Leverage Public Key Infrastructure Extensions (CAA, etc.)#

The broader PKI ecosystem offers additional tools to harden certificate issuance. One such measure is CAA (Certificate Authority Authorization) DNS records.

By publishing CAA records, you specify which CAs are allowed to issue certificates for your domain. This won’t directly be known to the app, but it prevents unauthorized CAs from issuing certs in the first place (or at least, compliant CAs will refuse if they’re not on your list).

For example, you might set a CAA record to only allow pki.goog (Google Trust Services) or Let’s Encrypt for your domain. This way, even if someone tricked a lesser-known CA, that CA should deny the request.

Using CAA in combination with CT monitoring significantly lowers the likelihood of misissued certs going unnoticed.

Another emerging concept is DANE (DNS-based Authentication of Named Entities), where the TLS public key or certificate is pinned in DNS (secured by DNSSEC). DANE isn’t widely adopted in mobile apps yet, but it’s an interesting future path.

The key point is that there are standards-based ways to lock down certificate issuance and validity that operate at the infrastructure level, rather than baked into app code.

5. Follow Platform Security Best Practices#

Use the security features provided by Android and iOS rather than reinventing the wheel.

• On Android:
  Use Network Security Configuration files to declaratively enforce policies:

  • disallow cleartext (HTTP) entirely,
  • add any custom CA if you genuinely need it (for instance, in a debug build or for an internal server),
  • enable the certificate transparency requirement as mentioned earlier.

  The Network Security Config also allows a debug-overrides section, so you can allow certain debugging CAs during development without affecting production builds, a much safer approach than writing custom trust logic.

• On iOS:
  App Transport Security (ATS) is enabled by default, which already requires HTTPS connections, strong ciphers, and certificate trust built-in. Avoid turning off ATS exceptions unless absolutely necessary.

  If you have to allow an HTTP endpoint or a weaker cipher for some reason, scope it narrowly in your Info.plist.

Essentially, align with the platform’s default security posture: both iOS and Android by 2025 have very sane defaults that eliminate most trivial MITM opportunities (e.g. no user-added CA trust on Android by default for new apps, mandatory TLS, etc.).

Where you have special needs, prefer configuration to code. And if you ever consider doing pinning-like restrictions, use the provided configuration mechanisms rather than custom code, they are less error-prone and easier to update.