Privacy risks can remain after unlocking

The phone screen lock controls entry to the device. Once the phone is unlocked, individual apps may still need their own access controls.

Yet the situations people actually worry about mostly occur on the far side of that boundary — showing someone a photo, handing the phone over for a repair, letting a family member use it, or being asked to unlock it. In those situations, a separate app credential can limit access while the phone is already unlocked.

What a second credential changes

A separate vault credential changes what a single disclosed code reveals. Someone who knows or observes the phone passcode gains the device; they do not automatically gain the vault.

That is the entire mechanism. It is not stronger cryptography — it is a second, unrelated boundary placed where the first one has already been crossed.

Why reusing the phone PIN defeats the point

Using the device passcode as the vault credential collapses two boundaries into one. Anyone who watches you unlock the phone has, in the same glance, learned how to open the vault.

The same applies to a pattern derived from an obvious personal fact, or one drawn regularly where a camera or another person can observe it. The credential's value comes from being unrelated to anything else.

Biometrics do not create a separate secret

Face and fingerprint recognition are convenient ways to authorise access to material the device already holds. They are not an additional secret, and in most designs they ultimately fall back to the device passcode.

A separate biometric check can still block someone who merely holds an unlocked phone. Its protection depends on the app and platform policy, including whether a passcode fallback is allowed. NullVault maps each pattern to a different vault on iOS and Android, without a visible master list, which is a different arrangement from a second biometric prompt.

Decide what you actually need

  • Define who legitimately knows or can observe the phone passcode.
  • List the situations in which the phone is unlocked around other people.
  • Decide whether you need one private space or several that should not reveal each other.
  • Choose credentials that are unrelated to the device passcode and to each other.
  • Plan recovery separately for each space, before you rely on any of them.

Try separate spaces with harmless files

In NullVault, create two test vaults with unrelated patterns and put a different harmless file in each. Lock the app, open one pattern and verify that it opens only the intended space. See pattern-addressed vaults and separate spaces for different patterns.

Before a handoff, close any private content and lock the vault. Check source copies in Photos, Downloads and shared apps separately. Opening a separate vault does not hide copies stored elsewhere, and a decoy does not guarantee safety under pressure.

A fictional example

Sofia wants to show a holiday photo while keeping work documents private. With harmless test files, she creates two vaults using unrelated patterns, opens only the holiday vault, then locks it before handing over the phone. She checks that the work document was not also left in Photos or Downloads. This is a fictional workflow, not a claim of product testing.

Common mistakes

  • Reusing the device PIN as a vault pattern
  • Assuming biometrics create a different secret
  • Forgetting notification and screen exposure

What this workflow does not change

  • A separate credential does not protect content already visible in an unlocked vault.
  • A compromised device, an observed pattern or an unprotected export can defeat the intended separation.
  • A vault lock does not replace a tested backup and the appropriate recovery credential.

Questions people ask

Is a vault lock always stronger?

Only if the implementation, credential, recovery, and device state support the intended boundary.

Why multiple patterns?

NullVault maps each pattern to a different vault on iOS and Android, without a visible master list.

Sources and further reading