Application security for your industry

Government mobile app security

Otukan protects citizen-facing government apps on phones the state does not control, guarding identity and records while keeping services accessible.

  • Android
  • iOS
  • Flutter
  • React Native
  • Every citizen's phone

    Citizens bring old and new devices the state never sees. Otukan protects the app itself, so identity and records are guarded on whatever phone opens them.

  • Accessible by design

    Screen readers and other assistive tools are part of every policy test, so protection keeps the service open to the citizens it exists for.

  • Service stays open

    Responses are proportionate per journey. Low-risk information stays available while high-risk actions ask for more assurance.

How Otukan handles threats to public services

Select a threat to see what Otukan detects, how the app responds and what the service receives.

Lookalike service apps

  1. Detect

    Requests from repackaged or re-signed copies fail the integrity and attestation checks the genuine app passes.

  2. Respond

    The service refuses the copy's requests and the genuine app keeps working normally.

  3. Report

    The service's security team receives the build identity of the copy.

Citizen identity takeover

  1. Detect

    Otukan recognises sign-in or recovery from a new app instance not bound to the citizen's enrolled phone.

  2. Respond

    The service asks for stronger verification before identity or records open.

  3. Report

    Binding state travels with the sign-in request to the identity service.

Scripted benefit claims

  1. Detect

    Attestation separates the genuine app from scripts and emulators calling claim or appointment endpoints.

  2. Respond

    Unattested requests are slowed, challenged or refused, per endpoint.

  3. Report

    Your API layer receives attestation results alongside each request.

Records captured on screen

  1. Detect

    Otukan recognises recording and mirroring on Android and iOS while a marked record screen is open, and screenshots taken on iOS.

  2. Respond

    The record view is hidden during capture, and on Android screenshots of it are blocked.

  3. Report

    Capture events reach the service with the screen, app version and platform.

Hooked signing step

  1. Detect

    Runtime checks catch instrumentation attached to the app while a citizen confirms or signs a request.

  2. Respond

    The signing step stops and the citizen is offered a safe way to continue.

  3. Report

    The service logs the runtime signal with the transaction reference.

Public service risks and the Otukan controls that meet them

Each card pairs a risk citizen-facing apps face with the Otukan control that addresses it.

  • App shielding

    Hardens the official app against analysis and modification, so studying or altering how it handles identity and records becomes slower, costlier and visible.

  • Record screen protection

    Hides tax, benefit and identity details during recording and mirroring on the screens you mark as sensitive, and blocks screenshots of them on Android.

  • Impersonation defence

    Signals when a lookalike or repackaged copy of the official app calls your services, so the service can refuse it and warn citizens.

  • Device binding

    Ties a citizen's enrolled identity to the app instance on their own phone, so stolen credentials alone are not enough to open the account elsewhere.

  • Authentication flow protection

    Guards PIN, biometric and one-time code steps against hooking and replay while the citizen signs in or signs a request.

  • OS integrity signals

    Reports rooted Android devices and jailbroken iPhones as separate platform signals your service weighs per journey.

How Otukan works with a public service

  1. Map citizen journeys

    We list the journeys that touch identity, records and payments, and the service that decides each one.

  2. Agree proportionate responses

    Each journey gets a response that matches its risk and keeps assisted access open.

  3. Protect the official build

    Otukan fits the service's existing build and release pipeline. Signing keys stay with the public body.

  4. Test with assistive tools

    Screen readers, magnifiers and switch access are part of the protected-build test plan.

  5. Hand over the record

    Control scope, test records and response owners are documented for procurement and audit.

Free for app publishers

Check your app's exposure

A passive review of your published app by an Otukan engineer. No files, no access to your systems. Findings go by email to the verified publisher.

You finish the request on the next page.

Public services protect citizen-facing apps by building the protection into the app, because the state does not control the phones its citizens use. Otukan hardens the official app, binds each citizen’s identity to the app on their own phone, protects sign-in and signing steps, keeps records off captured screens, and tells your services when a request comes from a copy or a script. Responses are proportionate per journey, so information stays available while high-risk actions ask for more assurance. Every control has its own Android and iOS scope. Government-issued devices are a separate programme with its own controls.

Service access on citizen-owned devices

Protecting identity

Citizen identity is the most valuable thing a government app holds. Otukan ties the enrolled identity to the app instance on the citizen’s phone, so a stolen password or intercepted code is not enough to open the account on another device. Sign-in, recovery and the moment a citizen signs or confirms a request are protected against hooking and replay. When enrolment or recovery happens on a new phone, the service sees that and can ask for stronger verification.

Protecting sensitive records

Tax statements, benefit decisions, health letters and identity documents appear on screen and are often cached for offline use. Otukan hides marked screens during recording and mirroring on both platforms, blocks screenshots of them on Android and reports screenshots on iOS, and encrypts what the app keeps on the device with each platform’s own key storage. Platform detail is on Android app data encryption and iOS app data encryption, and capture controls are covered on screen capture protection.

JourneyWhat attackers tryWhat Otukan providesService that decides
Enrolment and recoveryRegistering a stolen identity on another phoneDevice binding state, attestation, runtime integrityIdentity service
Viewing recordsCapturing or scraping personal dataScreen protection, encrypted storage, hooking detectionRecords service
Claims and appointmentsScripts and emulators filing or reserving at scaleAttestation results per requestService API layer
Signing and consentAltering what the citizen confirmsAuthentication flow protection, runtime checksSigning service

Operational boundaries

Citizen apps and government-managed devices are different programmes. Otukan’s application protection covers the citizen app on any phone and gives your services evidence about each request. It does not administer those phones and never needs to.

Staff and field devices issued by a public body are a separate case. They can be enrolled, configured and locked down, and some programmes need protection that starts below the app, at firmware level. That work belongs to device security and device management, each with its own owner. For issued devices, see government mobile device security and government mobile device management.

Keeping the boundary clear helps procurement too: the citizen app, the staff device fleet and the identity platform are assessed on their own terms.

Evaluation

Accessibility

A protected government app must remain usable by everyone. On Android, screen readers use accessibility services, the same route some malware abuses, so Otukan distinguishes assistive tools from abusive behaviour. On iOS, VoiceOver and other assistive features are system-level, and capture protection is designed not to interfere with them. Every policy is tested with screen readers, magnifiers and switch access before it is enforced, and warnings use plain language with a clear next step.

Procurement evidence

For each control, Otukan supplies its platform scope, the test records behind it, the response policy, the owning team and a description of the signals the app sends. That record supports the public body’s own security assessment. For mapping controls to a common standard, see OWASP MASVS mobile app security.

Continuity

Public services run for years and cannot pause for a security change. Policy can change without a new app release, new signals start in observe mode, and each journey has a defined response when a check cannot complete, so a problem on one device stays with that device instead of taking the service down for everyone. Shielding is covered on mobile app shielding.

For every Otukan app control in one place, return to mobile app security. Public bodies with an app in the stores can ask for a free App Exposure Check of the published build.

Common questions

  • Can a public service require citizens to use a secure phone?

    Rarely. Public services exist for everyone, including people with older, second-hand or modified devices. That is why protection belongs in the app. Otukan lets the service weigh device signals per journey: reading published information stays open to all, while viewing personal records or signing a request can ask for stronger verification, or send the citizen to another channel.

  • Does app protection conflict with accessibility requirements?

    It must not, and Otukan is designed around that. On Android, screen readers work through accessibility services, the same route some malware abuses, so Otukan separates legitimate assistive tools from abusive behaviour rather than blocking the channel. Protected builds are tested with screen readers, magnifiers and switch access on both platforms before any response is enforced.

  • What evidence does procurement receive?

    For each control, a stated platform scope, the test records behind it, the response policy and the team that owns it, plus a description of the signals the app sends and what they contain. That record supports the public body's own security assessment. It is not a certification, and the assessment remains the body's own decision.

On the mobile engineering team?

How protection fits your build, signing and release, platform by platform.

Protect the services citizens rely on

Tell us the public service, the platforms and framework of its app, the citizen journeys that handle identity or records, and your accessibility obligations. We never ask for binaries, signing keys, citizen data or production credentials.

Or request a technical demo