The runtime values that need protection are the ones that would let someone act as your user or read their data: session and refresh tokens, decrypted keys, one-time codes, card and account numbers, and personal records the app has just decrypted. They need protecting for exactly as long as they are readable, which should be the moment of use and no longer. Otukan keeps these values sealed in memory between uses, wipes them after use and detects debuggers, instrumentation and memory scanners trying to read the process. No app can use a value without it existing in memory, so the aim is a short, watched window, measured on your own app.
How memory safeguards fit a wider data-protection programme is covered on memory data protection.
Memory exposure
Different values appear in memory for different reasons and linger for different lengths of time. The first task is to map them.
| Value | Where it appears | How long it typically lingers without protection | Target lifetime with Otukan |
|---|---|---|---|
| Session and refresh tokens | After sign-in, then with each request | For the whole session, often longer | Readable only while a request is built |
| Encryption and signing keys | After being loaded from secure storage | Until the app is closed | Readable only during the operation |
| One-time codes and PINs | While the user types and the app submits | Until memory is reused | Cleared once submitted |
| Card, account and identity data | After decryption for display or submission | Across screens and in the background | Cleared when the screen closes |
| API secrets shipped with the app | From launch | For the app’s lifetime | Unwrapped on demand; see secrets protection |
Platform differences
Android apps mix Java or Kotlin, which manage memory for you, with native libraries, which do not. iOS apps mix Swift and Objective-C with system frameworks that keep their own copies. iOS app memory protection covers that side in detail. Flutter and React Native add a further runtime on top. Otukan writes its controls for each platform and measures each framework separately.
Control boundary
Memory protection is often confused with code protection. They guard different things, and a buyer should know which is which.
| Question | Control | What it protects |
|---|---|---|
| Is the running code the code we shipped? | Anti-tampering and hooking detection | Integrity of instructions |
| Can someone change values the app relies on? | Memory editing detection | Integrity of data in use |
| How long is sensitive data readable? | Memory protection | Confidentiality of data in use |
| Is stored data readable from disk? | Data encryption | Confidentiality of data at rest |
An intact app can still leave a token in memory for hours. A tampered app can still hold its secrets for only a moment. Otukan treats the two as separate controls with shared signals, so a hooking detection can also end the life of every sealed value in the session.
Validation
Memory protection must be proven on the app and platforms you ship, because runtimes behave differently from one release to the next.
What we agree before testing
Your team and ours list each value, the flow that handles it, the lifetime you chose and the reader tools to use in the lab. That list becomes the test plan, and its results become the record your auditors and risk team can read. When a new release adds a sensitive value, it joins the list before the release ships.
Positive test
In an authorised lab, we attach a debugger and a memory scanner to the protected app during the flow that handles each value, and confirm two things: the signal fires, and a process dump taken between uses holds no readable copy of the value.
Negative control
The same journey runs on a clean device with no reader attached, to confirm nothing fires and the flow completes normally.
Regression
Install, update, sign-in and the sensitive flow are repeated after each protected release, with versions, devices, results and the reviewer recorded.
Residual exposure
Some copies are outside any app’s control: values passed to system components, framework caches, and strings in managed languages that cannot be overwritten. We measure and document what remains for your app, so your risk team works from evidence rather than assumptions. The wider picture is on mobile app security. For a structured way to evaluate options, see the memory protection solution guide.