What is dynamic certificate pinning?
Dynamic certificate pinning is certificate pinning whose pin set can be replaced at runtime by a new set that the app verifies cryptographically before trusting it. The app still accepts a TLS connection only when the server presents a pinned certificate or public key. What changes is how the pins arrive: as a signed configuration delivered to installed apps, instead of a constant compiled into the binary. Rotating a certificate becomes a publish, not a release.
New to pinning itself? Start with What is certificate pinning?
Why static pins break
A static pin set is only as current as the last app release. Public TLS certificates are getting shorter: the maximum lifetime fell to 200 days in March 2026 and falls to 100 days in March 2027 and 47 days in March 2029, and most managed certificate services, AWS Certificate Manager among them, generate a new key pair at every renewal. Each renewal is therefore a new SPKI pin. Against that, a store review takes days and the long tail of users never updates. Sooner or later the server presents a key the app has never heard of, and every request fails.
Teams running static pinning on this schedule end up either shipping emergency releases or wiring a remote kill switch that turns pinning off, which removes the protection exactly when it is being tested. The rotation runbook covers the mechanics; the fix at the architecture level is to make the pin set updatable on the same timescale as the certificates.
How dynamic pinning works with TrustPin
Ship the verification key
Add the SDK and your project's configuration file. The public key that verifies every future pin set is now part of the binary.
Stage the pins
From the console or with trustpin-cli projects refresh-certs, collect the SPKI pins for each host: the certificate being served plus every unexpired issuance in Certificate Transparency.
Sign and publish
Signing produces a JWS with the project's private key, or with your own key under BYOK. The signed configuration is published to redundant CDNs; you can also serve it from your own CDN, with TrustPin's as the fallback.
Devices verify and switch
Installed apps fetch the configuration, verify the signature and version, cache it, and start enforcing the new pin set. No release, no review, no user update.
The developer documentation describes the configuration format, the signature verification and the SDK behavior on each platform.
What makes a remote pin update safe
Fetching pins over the network sounds like the thing pinning is supposed to prevent, and done carelessly it is. HTTP Public Key Pinning for browsers trusted the first pin set it saw and every major browser had dropped it by early 2020. A safe design needs all of the following, and TrustPin provides each one.
Trust anchor shipped in the app
The app carries your project's public key from its first launch. Trust is never bootstrapped over the network it is trying to protect.
Every pin set is signed
Configurations are signed with ECDSA P-256 and verified on the device before a single pin is trusted. With Bring Your Own Keys the private key never leaves your organization.
Anti-rollback
Devices reject configurations older than the one they hold, so an attacker who captured a previous pin set cannot replay it.
Works offline
The last verified configuration stays on the device. Apps protected by RASP can also embed a signed copy in the build for a first launch without connectivity.
Enforced in the handshake
Pins are checked after the operating system validates the chain and before any application data is sent. Strict mode fails closed, and an observe-only validation listener reports every definitive verdict to your telemetry.
Fed by your certificates
The CLI reads a domain's live certificate and the Certificate Transparency logs and stages every unexpired key, so the next certificate is pinned before the server starts using it.
Static versus dynamic pinning
| Property | Static pinning | Dynamic pinning (TrustPin) |
|---|---|---|
| Where the pins live | Compiled into the binary | Signed configuration fetched at runtime, cached on device |
| Changing a pin | New build, store review, wait for users to update | Publish a signed configuration; devices switch in minutes |
| Trust anchor | The binary | The verification key compiled into the binary |
| Protection against a bad update | Not applicable | Signature verification, anti-rollback, fail-closed on invalid configuration |
| Offline behavior | Pins always available | Last verified configuration; embedded configuration for RASP-protected apps |
| Rotation risk | Lock-out if the key changes before the update ships | Next key pinned ahead of the switch; old pin ages out |
Who needs dynamic pinning
Any app whose traffic is worth intercepting and whose users are on networks you do not control: banking and fintech, energy and utilities, health, and any product a regulator or a customer's security review expects to pin. These are also the teams that cannot afford a lock-out, which is why the update path matters as much as the pin itself. Pinning secures the connection; for the app runtime, TrustPin partners with Promon for runtime application self-protection.
One signed configuration, every platform
- iOS and macOS
Swift, URLSession, Alamofire
- Android and JVM
Kotlin, OkHttp, Retrofit, Ktor
- Flutter
Dio and the http package
- React Native
Expo and bare projects
- CLI
Automate pin rotation
Requirements and package coordinates are on the SDKs & CLI page; the DevSecOps page shows the pin refresh running in CI.
Frequently asked questions
What is dynamic certificate pinning?
Dynamic certificate pinning keeps the pin set outside the app binary and lets installed apps receive a new, cryptographically signed pin set at runtime. The app ships with a verification key, every configuration is signed with the matching private key and verified on the device before any pin is trusted, older configurations cannot replace newer ones, and the last verified configuration is kept so pinning keeps working offline. Changing a pin takes minutes instead of an app-store release.
Is dynamic pinning less secure than static pinning?
Not when the update is signed and the verification key ships inside the app. The trust anchor is then exactly as fixed as in the static case: it is compiled into the binary. What changes is the pin set the anchor vouches for. The failure mode to avoid is an unsigned download, or a trust-on-first-use scheme, where the app accepts whatever pins the network hands it. HTTP Public Key Pinning for browsers had that flaw among others, and every major browser had removed it by early 2020.
What happens if TrustPin is unreachable?
The app keeps validating against the last configuration it verified, and apps protected by RASP can embed a signed configuration for a first launch offline. Delivery runs across redundant CDNs with automatic failover, and you can serve the configuration from your own CDN with TrustPin as the fallback. For an installed app that has verified a configuration once, a delivery outage never becomes a pinning outage.
Which platforms does TrustPin support?
iOS and macOS (Swift, URLSession and Alamofire), Android and the JVM (Kotlin, OkHttp, Retrofit and Ktor), Flutter (Dio and the http package) and React Native (Expo and bare projects), plus a CLI for CI/CD pipelines. The same signed configuration serves every platform.