Evaluate enterprise access and per-app VPN by asking three things: does the tunnel carry only the work app’s traffic, does it open only for a genuine app on a healthy device, and does it hold up when certificates change or the network drops? Otukan answers all three from inside the protected work app. It checks the app and the device before a connection is requested, validates the server identity on each session and lets you set what happens when a check fails or cannot run. Each control is scoped separately for Android and iOS. Otukan governs the work app’s path to your network; the rest of the phone is left alone.
Other controls for staff apps are on enterprise application protection.
Trust boundary
Three questions often get merged into one “is the connection secure” check. Keeping them apart makes each one testable.
Transport validation
The first question is whether the app is talking to your gateway. Transport security only helps if the app refuses certificates it was not told to trust. Otukan checks the identity presented on every session against the gateway identity you expect, and pins it where you choose to.
Hostile intermediaries
The second is whether something sits in the middle. Interception tools, rogue access points and proxy settings pushed by a malicious profile all try to read or alter traffic. Otukan treats any intermediary outside your trust list as hostile and keeps corporate requests inside the app.
App and backend identity
The third is whether the client is your work app at all. A valid user on a cloned or hooked copy of the app is still a threat. Otukan confirms the release before a tunnel is requested and passes that result to your access gateway, so the decision is made on your side.
| Question | What fails without it | Otukan control |
|---|---|---|
| Is this our gateway? | Traffic goes to an impostor server | Server identity checks and pinning |
| Is anyone in the middle? | Credentials and data are read in transit | Interception and proxy detection |
| Is this our app on a healthy device? | A tampered client reaches internal systems | Integrity and device checks before the tunnel |
Lifecycle
Access decisions have to survive the ordinary life of a phone, not just the first connection.
Certificate changes
Gateways renew certificates on a schedule. The work app should accept the next certificate without a new release, and reject everything else. Otukan works from a trust list agreed with your network team, with backup keys and a rotation plan written down before the first release. For rotation practice, see the certificate pinning rotation guide.
Network transitions
Staff walk out of the office and move from Wi-Fi to mobile data, or join a hotel network with a captive portal. Each change is a new path. Otukan re-checks the path and the device state after the switch, then re-establishes the tunnel, so an unsafe network met halfway through the day is caught at that moment.
Approved enterprise proxies
Many organisations inspect their own traffic. That inspection is legitimate and goes on the trust list. Otukan separates it from unknown intermediaries, so security teams keep their visibility and attackers do not inherit it.
Availability
Strict access rules that lock staff out on a busy morning do not last. Plan failure handling before you enforce anything.
Failure handling
Decide, per internal service, what a failed check means. A jailbroken device might be refused everything. An unavailable check, such as a gateway timeout, might allow a limited mode. Otukan applies observe, warn, restrict or terminate per service, so one rule does not have to fit email and payroll alike.
Fallback
A degraded mode keeps low-risk services reachable while sensitive systems stay closed. Staff can still read the rota or reply to a message; they cannot approve payments until the device passes again. The user sees a plain message explaining what is limited and why.
Recovery
Recovery should be as automatic as the block. When the device returns to a trusted network or the user removes the risky profile, the next check passes and the tunnel reopens. Rehearse this with your service desk: an outage, a certificate change, a network switch and a device that fixes itself. Record the devices, OS versions, expected results and reviewer, then enforce.
Identity checks before the tunnel opens are covered on mobile SSO integration.