Evaluate man-in-the-middle prevention by separating three questions: is each connection validated correctly, can the app tell when a hostile intermediary sits on the path, and does your backend know it is talking to your genuine app. Then test how the protection survives certificate rotation, network changes and approved corporate proxies, and what users experience when validation fails. This guide covers Android and iOS apps, each scoped separately; server-side TLS configuration is outside its scope. Otukan pins your certificates, detects interception at runtime and alerts your backend, with a rotation plan that keeps the app reachable.
The control itself is covered on man-in-the-middle attack prevention.
Trust boundary
Transport security is often treated as one switch. In practice it is four layers, and an attacker only needs the weakest.
| Layer | Question it answers | Where it lives |
|---|---|---|
| Chain validation | Is this certificate valid for this host? | The platform TLS stack and the app’s network settings |
| Certificate pinning | Is this the key we expect for our host? | The app; Android Network Security Configuration and iOS App Transport Security pinned domains are platform options |
| Interception detection | Is a proxy, rogue certificate authority or tampered TLS code present? | Runtime checks inside the app |
| App and backend identity | Is the caller our genuine, unmodified app? | App attestation and API protection |
Questions for each option
- Does the app trust user-installed certificate authorities? On Android, apps targeting current API levels do not by default; confirm your own configuration. On iOS, a user must install a profile and then switch on full trust for its root.
- Is pinning enforced for each host that carries sensitive traffic, including third-party services your app calls?
- If an attacker hooks or patches the TLS code to switch pinning off, what notices?
- Does your backend receive evidence that a request came from an unmodified app?
How Otukan answers. Otukan applies certificate pinning, reads proxy, VPN and user-installed certificate settings as context while the app runs, and reacts when TLS validation code is hooked or patched. App attestation and mobile API protection let your backend confirm the genuine app sits at the other end of the connection.
Lifecycle
Most pinning incidents are self-inflicted: a certificate is renewed and older app versions can no longer connect. Plan the lifecycle before you enforce anything.
Certificate changes
- Do you pin a leaf certificate, an intermediate or a public key, and is the reason written down?
- Does a backup pin ship in a release well before the current key retires?
- How long do old app versions stay installed, and will they survive the next renewal?
- Who in the mobile team hears about a certificate change before it happens?
Network transitions
- Switch between Wi-Fi and mobile data during a sensitive request, and record what the app does.
- Join a captive portal network: does the app explain the problem, or fail without a message?
Approved enterprise proxies
- Do company-managed devices route traffic through a TLS-inspecting proxy? Decide whether your app excludes, tolerates or refuses that path for each flow, and document why.
Rotation plan
| Stage | Action |
|---|---|
| Prepare | Generate the next key and add its pin as a backup in an app release |
| Adopt | Wait until the release with the backup pin is widely installed |
| Rotate | Switch the server to the new certificate |
| Retire | Remove the old pin in a later release and add the following backup |
How Otukan answers. Otukan pinning ships with backup keys and a rotation and emergency replacement plan agreed with your infrastructure team, so a planned certificate change does not strand users on older versions. Approved corporate inspection proxies become a per-flow policy decision rather than a blanket block.
Step-by-step rotation is covered on certificate pinning rotation.
Availability
Enforcement without a failure plan turns a certificate mistake into an outage. Decide the behaviour first, then switch it on.
Failure handling
- When validation fails, does the app block the request, block the flow or close?
- Is there any fallback to an unpinned connection? For sensitive flows there should be none.
- What does the user see, and what can they do next?
Recovery and visibility
- Does your backend receive a signal on each validation failure, so a spike is visible within your monitoring?
- Rehearse a certificate rotation in staging and confirm that old and new builds both connect.
- Who decides to pause enforcement during an incident, and how is that decision recorded?
How Otukan answers. A connection that fails pinning is refused before any request or credential is sent. Otukan then applies the response you picked for that flow: sign-in can be refused with a clear message while public content still loads. Each failure reaches your backend as a runtime threat signal, so a rising pattern shows up in your monitoring before it shows up in support calls. Each refusal records which layer stopped it, pinning, validation or proxy policy, so support can tell a certificate mistake from an attack.
Telling hostile interception from approved networks is covered on the proxy and VPN risk solution guide.