Start from the assumption that access is gone
A factory reset should be treated as destroying local-only vault access. That is the safe default, and planning from it produces the right behaviour even in the cases where recovery turns out to be possible.
The alternative assumption — that reinstalling the app will bring the data back — is the reason people lose libraries they believed were protected.
Reinstalling restores software, not data
Downloading the app again gives you the application. It does not restore the encrypted container that lived in the app's storage, and it cannot reconstruct key material that the reset destroyed.
Where a vault binds keys to hardware-backed platform storage, those keys do not survive a reset by design. The ciphertext may or may not still exist somewhere; without the key it is not usable either way.
Device backups are not a reliable substitute
Whether a system backup captures an app's private container depends on the platform, the app's own backup policy, the account state, and the user's settings. Some apps deliberately exclude their data from system backups precisely because it is sensitive.
That variability is why it cannot be the plan. A backup you have not verified is a hypothesis, and a factory reset is a poor time to test one.
The sequence before you reset
- Inventory the local vaults and decide which ones actually matter.
- Create a portable encrypted backup through the app's own supported workflow.
- Store that backup and its recovery phrase in separate places.
- Restore it somewhere else and open real content — before the reset, not after.
- Only then reset, trade in, or hand over the device.
Errors that make this permanent
- Treating an app re-download as data recovery.
- Keeping the only backup on the phone that is about to be wiped.
- Recording a recovery phrase without ever verifying it works.
- Resetting under time pressure at a trade-in counter.
A fictional example
Maya starts with a non-sensitive test: “Inventory local vaults and confirm which ones matter.” Next, Maya follows the second check: “Create a portable encrypted backup using the app's supported workflow.” This fictional scenario demonstrates the decision process; it is not a report of product testing.
Common mistakes
- Treating app re-download as data recovery
- Keeping the only backup on the phone being reset
- Recording an unverified recovery phrase
What this workflow does not change
- Treating app re-download as data recovery
- Keeping the only backup on the phone being reset
- Recording an unverified recovery phrase
Questions people ask
Can device recovery alone restore a lost phone?
No. NullVault's device recovery is described as same-device access recovery, separate from portable backup.
Will an ordinary phone backup always include vault data?
No. Platform backup behavior and app exclusions vary; use the vault's documented portable backup path.