Certificate Pinning Interview Questions: What They Test and How to Answer
What interviewers want when they ask about certificate pinning: what it stops, what to pin, how to rotate without outages, how testers bypass it on their own devices, and why the API must be secure anyway.
BY AISECURITYINTERVIEWS EDITORIAL · EDITORIAL TEAM · UPDATED NOVEMBER 4, 2026 · 4 MIN READ
PRACTICE THIS:Pinning bypass and resistance ·Practise mobile security
Certificate pinning comes up in almost every mobile security interview and in many web and API ones. Candidates usually know the definition. The follow-up questions are where interviews are decided: what exactly do you pin, what happens at renewal, what if the device is rooted, and does pinning protect the API? This post walks those questions in the order interviewers ask them.
What pinning actually does
Normal TLS validation accepts any certificate that chains to a root in the device's trust store and names the right host. Pinning adds a second rule: the server's public key, or a key in its chain, must match a value the app already knows. That narrows trust from "any of several hundred CAs, plus anything the user or employer installed" to "the keys we chose".
Interception by a third party
Rogue CA or installed proxy root
valid-looking certificate
Key not in pin set
connection refused
Interception fails
Outcome, safe: Users protected
Hotel Wi-Fi, malicious profiles, misissuance
Device owner or tester
Controls the device
hooks the pin check
Traffic visible
API calls replayed
Server must not trust the client
Outcome, unsafe: Pinning bypassed
Expected and acceptable
The questions interviewers ask next
"What would you pin?" The strongest answer is the SPKI hash of keys you control, with at least one backup key generated in advance and kept offline, configured through the platform's declarative mechanism (Android Network Security Config, iOS NSPinnedDomains) with an expiry date. Pinning the leaf certificate breaks the app at every renewal. Pinning a CA's intermediate survives renewals but ties your app's availability to that CA's decisions.
"What happens when you rotate keys?" If the new key is already in the shipped pin set, nothing breaks. If it is not, every installed copy of the app refuses to connect until users update. That is why the backup pin exists, and why an expiry on the pin set matters: a stale set should stop being enforced rather than brick the app.
"How would a tester bypass it?" On a device they control: hook the platform or library verification so it reports success, repackage the app with modified network configuration, or ask the client for a test build. Without root, repackaging and emulators still work, though they change the app's signing identity, which attestation and signature checks can detect. A good answer adds that bypassing pinning on your own device is not, by itself, a vulnerability.
"So does pinning protect the API?" No. The API must enforce authorisation, limits and business rules on the server, because modified clients exist. Pinning protects users on hostile networks; attestation and server-side checks protect the backend.
A compact model answer
"Pinning makes the app accept only keys we chose, which stops interception by rogue or user-installed CAs. I would pin SPKI hashes of our own primary and backup keys through the platform config with an expiry, and rotate within the pin set. It does not stop someone who controls the device from disabling it, so the API must be secure on its own, with attestation for sensitive actions."
Where to go deeper
The certificate pinning design question works through pin choices and rotation; how pinning is bypassed and resisted covers testers' techniques and app-side resistance; and Network Security Config and ATS explains the platform settings. For the TLS checks underneath, read how certificate validation works.
Interview questions and lessons that go deeper on this post:
FAQ
It is an app accepting only certificates whose public key matches values shipped in the app, instead of any certificate a trusted CA issued. It stops interception by CAs or proxies the app did not choose.