The clearest sign is that a proxy tool can still intercept, decrypt, or modify the app’s HTTPS traffic after the tester installs its root certificate on the test device. If the app continues to connect normally through that proxy, the pinning control is missing, bypassed, or implemented against the wrong certificate material.
How to tell pinning is failing during mobile testing
When pinning is broken, the app behaves as if a trusted proxy is ordinary network infrastructure. You can install the proxy’s root certificate on a test device, route traffic through it, and still see full TLS interception, request replay, or response tampering succeed. That usually means the app is not enforcing pin validation on the actual connection path.
A second clue is that the app succeeds only against the environment you expected it to distrust. If one build bypasses the proxy while another fails, the difference often comes from a changed certificate, a debug-only trust rule, a library update, or a network stack that validates a different trust anchor than the one you pinned.
Pinning failures are often easiest to spot when the app still reaches backend endpoints after trust-store changes that should matter. If the app continues to log in, fetch tokens, or submit sensitive actions through an intercepting proxy, the control is either absent, scoped too narrowly, or pinned to a material that is no longer authoritative for the server endpoint.
Common implementation mistakes that make pinning look “on” when it is not
One common failure is pinning the wrong certificate object. Teams sometimes pin a leaf certificate that rotates frequently, a backup certificate that is never enforced, or a public key hash that does not match the server path used in production. Another common mistake is enabling pinning in one code path while a different HTTP client, SDK, or WebView makes the real network call.
Configuration drift also creates false confidence. Network security settings may block user-installed certificates in one environment but allow them in another, or a debug flag may disable enforcement for release-like testing. If the app only fails pinning on certain screens, flows, or devices, the issue is usually incomplete coverage rather than a single broken check.
Testing tooling matters too. Some apps only inspect the platform trust store and never confirm that the presented certificate chains to the expected material. In those cases, a proxy CA is enough to defeat the control even though the app appears to use TLS correctly. That is why testers should validate the exact TLS stack and hostname path the app uses, not just the presence of HTTPS.
What to verify before you conclude the control is missing
First, verify that you are testing the production network path, not a mock server, staging endpoint, or SDK-managed fallback. Then confirm whether the app uses its own TLS stack, the system trust store, or a library wrapper that may override the intended policy. Mobile apps often hide the real behavior behind multiple layers, so the visible setting is not always the effective one.
You should also confirm that the test device really trusts the proxy CA and that no device policy, certificate transparency check, or environment-specific guard is masking the result. If the app fails only when the proxy CA is absent, the pinning test is inconclusive. If it still works after the proxy CA is installed, the control has likely failed in the way you are trying to detect.
For a deeper baseline, compare the app against the expected certificate lifecycle and trust model described in the Mobile App Security Testing Guide and the OWASP Mobile Top 10 M5 Insecure Communication Guide. If your test case depends on TLS interception, TLS Inspection Guide explains the proxy and decryption mechanics that pinning is supposed to resist.
Risk and Threat Considerations
When certificate pinning fails, the app can be exposed to interception on hostile Wi-Fi, compromised test infrastructure, or any environment where a trusted proxy certificate can be inserted. That weakens the confidentiality and integrity of API traffic, and it can expose session material, tokens, or sensitive business actions to modification in transit.
Failure mechanism: The app accepts a certificate chain or public key that should have been rejected, so a man-in-the-middle proxy can terminate and reissue TLS without triggering a client-side failure.
Impact: Attackers or testers can observe, alter, and replay traffic that the app should have protected, which makes downstream credential theft, token abuse, and request tampering materially easier.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while OWASP ASVS, CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V12 — Secure Communication | Pinning failures are a secure communication defect in the mobile client. |
| Recommendation — Validate certificate checks and TLS handling on every production network path. | ||
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | Client-side trust failure can expose or weaken certificate-based authentication material. |
| Recommendation — Verify certificate validation rejects unexpected peers before traffic is trusted. | ||
| CIS Controls v8 | CIS-13 — Data Protection | TLS interception resistance protects sensitive data in transit from disclosure and tampering. |
| Recommendation — Protect sensitive mobile traffic with enforced transport-layer safeguards and testing. | ||
| NIST SP 800-53 Rev 5 | SC-23 — Session Authenticity | Pinning helps ensure the endpoint is genuine before a session is trusted. |
| SC-8 — Transmission Confidentiality and Integrity | Pinning failure undermines confidentiality and integrity of transmitted app data. | |
| Recommendation — Confirm the client authenticates the peer before establishing a protected session. Ensure transmitted mobile data remains confidential and tamper-resistant in transit. | ||
Practitioner Guidance
What to verify: Test both success and failure states. A good pinning implementation should break cleanly when the server presents an unexpected certificate, and it should do so on every network path the app can use, including SDK calls and embedded web content. If one path still talks through the proxy, treat that as a real gap, not a test artifact.
Common mistake: Teams often validate pinning in a single happy-path screen and assume the entire app is covered. In practice, a mobile app may have multiple HTTP clients, backup endpoints, or feature-specific libraries, and only one of them is enforcing the check. That creates partial protection that looks stronger than it is.
Practitioner takeaway: The important question is not whether the app uses HTTPS, but whether it refuses to trust the wrong certificate on every production-relevant connection path.
Related resources from NHI Mgmt Group
- What are the signs that mobile app security testing is not working at enterprise scale?
- What are the signs that a mobile banking app protection strategy is not working?
- What are the signs that mobile instrumentation detection is working without hurting app performance?
- What happens when biometric authentication or certificate pinning is implemented poorly in a mobile app?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 31, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org