Phone SeizedWhat is on your phoneDeleted is not gone — but it is not all recoverable either
Deleted is not gone — but it is not all recoverable either
What you must do, what you can refuse, and what they can do
Every claim below links to the source it comes from, with the wording quoted so you can check it yourself.
What the sources say
What a document, a report, an agency publication or a provision says, quoted as it is worded.
SQLite's own documentation on Write-Ahead Logging states that the original content is preserved in the database file and the changes are appended into a separate WAL file.
SQLite, "Write-Ahead Logging" (sqlite.org/wal.html), as fetched 2026-09-08
“The original content is preserved in the database file and the changes are appended into a separate WAL file.”
Read it at sqlite.orgquote checked 2026-09-08
SQLite's own documentation states that when secure_delete is on, SQLite overwrites deleted content with zeros.
SQLite, "PRAGMA secure_delete" (sqlite.org/pragma.html), as fetched 2026-09-08
“When secure_delete is on, SQLite overwrites deleted content with zeros.”
Read it at sqlite.orgquote checked 2026-09-08
A 2020 Upturn report on mobile device forensic tools says: “Mobile device forensic tools can sometimes access ‘deleted’ data from phones.” It also says: “Often, deleting a file on a phone isn’t permanent, and the file can be recovered — similar to how most computers have a ‘recycling bin’ for getting rid of files.” It adds: “Even ‘permanently deleted’ files can sometimes be recovered with the right tools, because data isn’t always physically wiped from storage when it’s deleted”, adding: “it’s just marked as ‘free space’ until it’s overwritten by other data.” The same passage says: “However, access to deleted data depends on a range of factors, including phone hardware, encryption design, and extraction method.”
Upturn, "Mass Extraction: The Widespread Power of U.S. Law Enforcement to Search Mobile Phones", 20 Oct 2020, sub-section "Deleted" Data
“Mobile device forensic tools can sometimes access “deleted” data from phones. Often, deleting a file on a phone isn’t permanent, and the file can be recovered — similar to how most computers have a “recycling bin” for getting rid of files. Deleting a file from the phone itself often doesn’t delete it from a user’s cloud backup, or the variety of other places it may have been redundantly stored at some point. Even “permanently deleted” files can sometimes be recovered with the right tools, because data isn’t always physically wiped from storage when it’s deleted — it’s just marked as “free space” until it’s overwritten by other data. However, access to deleted data depends on a range of factors, including phone hardware, encryption design, and extraction method.”
Read it at upturn.orgquote checked 2026-11-02
SQLite's documentation for VACUUM states: “When content is deleted from an SQLite database, the content is not usually erased but rather the space used to hold the content is marked as being available for reuse.” It continues: “This can allow deleted content to be recovered by a hacker or by forensic analysis.”
SQLite, "VACUUM" (sqlite.org/lang_vacuum.html), section 2 "Description", as fetched 2026-11-02
“When content is deleted from an SQLite database, the content is not usually erased but rather the space used to hold the content is marked as being available for reuse. This can allow deleted content to be recovered by a hacker or by forensic analysis. Running VACUUM will clean the database of all traces of deleted content, thus preventing an adversary from recovering deleted content.”
Read it at sqlite.orgquote checked 2026-11-02
SQLite's documentation for VACUUM states: “Running VACUUM will clean the database of all traces of deleted content, thus preventing an adversary from recovering deleted content.”
SQLite, "VACUUM" (sqlite.org/lang_vacuum.html), section 2 "Description", as fetched 2026-11-02
“When content is deleted from an SQLite database, the content is not usually erased but rather the space used to hold the content is marked as being available for reuse. This can allow deleted content to be recovered by a hacker or by forensic analysis. Running VACUUM will clean the database of all traces of deleted content, thus preventing an adversary from recovering deleted content.”
Read it at sqlite.orgquote checked 2026-11-02
SQLite's database file format documentation states: “Unused pages can come about, for example, when information is deleted from the database. Unused pages are stored on the freelist and are reused when additional pages are required.”
SQLite, "Database File Format" (sqlite.org/fileformat2.html), section 1.5 "The Freelist", as fetched 2026-11-02
“A database file might contain one or more pages that are not in active use. Unused pages can come about, for example, when information is deleted from the database. Unused pages are stored on the freelist and are reused when additional pages are required.”
Read it at sqlite.orgquote checked 2026-11-02
SQLite's secure_delete documentation states: “The default setting for secure_delete is determined by the SQLITE_SECURE_DELETE compile-time option and is normally off.” It describes a ‘fast’ setting: “When secure_delete is set to "fast", SQLite will overwrite deleted content with zeros only if doing so does not increase the amount of I/O.” Of that setting it says: “This has the effect of purging all old content from b-tree pages” and “but leaving forensic traces on freelist pages”.
SQLite, "PRAGMA secure_delete" (sqlite.org/pragma.html#pragma_secure_delete), as fetched 2026-11-02
“The default setting for secure_delete is determined by the SQLITE_SECURE_DELETE compile-time option and is normally off. The off setting for secure_delete improves performance by reducing the number of CPU cycles and the amount of disk I/O. Applications that wish to avoid leaving forensic traces after content is deleted or updated should enable the secure_delete pragma prior to performing the delete or update, or else run VACUUM after the delete or update.—The "fast" setting for secure_delete (added circa 2017-08-01) is an intermediate setting in between "on" and "off". When secure_delete is set to "fast", SQLite will overwrite deleted content with zeros only if doing so does not increase the amount of I/O. In other words, the "fast" setting uses more CPU cycles but does not use more I/O. This has the effect of purging all old content from b-tree pages—but leaving forensic traces on freelist pages”
Read it at sqlite.orgquote checked 2026-11-02
NIST's Special Publication 800-101 Revision 1 (NIST, May 2014, in a section that says “Supported devices include iPhone 3GS and iPhone 4…”) says: “When data protection is active, the file key is obliterated when the file is deleted, leaving encrypted and generally unrecoverable file contents in unallocated space, which render traditional carving techniques for deleted files useless.” The next sentence says: “Data however can often be found residing inside allocated data containers (i.e., SQLite Tables) and should not be discounted or ignored as part of any examination.”
NIST, Special Publication 800-101 Revision 1, "Guidelines on Mobile Device Forensics", May 2014, section 5.3.2, "iOS Device Considerations"
“Supported devices include iPhone 3GS and iPhone 4—When data protection is active, the file key is obliterated when the file is deleted, leaving encrypted and generally unrecoverable file contents in unallocated space, which render traditional carving techniques for deleted files useless. Data however can often be found residing inside allocated data containers (i.e., SQLite Tables) and should not be discounted or ignored as part of any examination.”
Read it at nvlpubs.nist.govquote checked 2026-11-02
NIST's Special Publication 800-101 Revision 1 (May 2014), in its classification system for mobile device tools, describes a manual extraction method as “viewing the data content stored on a mobile device” and says: “At this level, it is impossible to recover deleted information.”
NIST, Special Publication 800-101 Revision 1, "Guidelines on Mobile Device Forensics", May 2014, section 3.1, "Mobile Device Tool Classification System" ("Manual Extraction")
“Manual Extraction—A manual extraction method involves viewing the data content stored on a mobile device. The content displayed on the LCD screen requires the manual manipulation of the buttons, keyboard or touchscreen to view the contents of the mobile device. Information discovered may be recorded using an external digital camera. At this level, it is impossible to recover deleted information.”
Read it at nvlpubs.nist.govquote checked 2026-11-02
NIST's Special Publication 800-101 Revision 1 (May 2014) says: “hex dumping allows deleted objects and any data remnants present to be examined (e.g., in unallocated memory or file system space), which otherwise would be inaccessible through the use of logical acquisition methods. However, the extracted device images require parsing, decryption and decoding.”
NIST, Special Publication 800-101 Revision 1, "Guidelines on Mobile Device Forensics", May 2014, section 3.1, "Mobile Device Tool Classification System" (comparison of extraction levels)
“There are pros and cons to performing extraction types at each layer. For example, hex dumping allows deleted objects and any data remnants present to be examined (e.g., in unallocated memory or file system space), which otherwise would be inaccessible through the use of logical acquisition methods. However, the extracted device images require parsing, decryption and decoding.”
Read it at nvlpubs.nist.govquote checked 2026-11-02
A 2018 Privacy International report says that MSAB's XRY Physical allows access to “system and deleted data and can use extra functionality to help overcome security and encryption challenges”.
Privacy International, "Digital stop and search: how the UK police can secretly download everything from your mobile phone", 27 Mar 2018 (archived copy of the report PDF)
“MSAB's XRY Physical allows access to "system and deleted data and can use extra functionality to help overcome security and encryption challenges”
Read it at web.archive.orgquote checked 2026-09-08
With Apple's Advanced Data Protection enabled, the number of iCloud data categories using end-to-end encryption rises to 25, including iCloud Backup, Photos and Notes.
Apple, "iCloud data security overview" (support.apple.com/en-gb/102651), as fetched 2026-09-08
“With Advanced Data Protection, the number of data categories that use end-to-end encryption rises to 25 and includes your iCloud Backup, Photos, Notes and more.”
Read it at support.apple.comquote checked 2026-09-08
Apple states that you can choose to enable Advanced Data Protection to protect the vast majority of your iCloud data, and that if you enable it and then lose access to your account, Apple will not have the encryption keys to help you recover it.
Apple, "iCloud data security overview" (support.apple.com/en-gb/102651), as fetched 2026-10-01
“you can choose to enable Advanced Data Protection to protect the vast majority of your iCloud data—If you enable Advanced Data Protection and then lose access to your account, Apple will not have the encryption keys to help you recover it”
Read it at support.apple.comquote checked 2026-10-01
Cellebrite's Inseyets product page, in an FAQ answer on what Inseyets includes, describes Cellebrite Inseyets.UFED with the words “Access devices and data previously unreachable and extract the Full File System data including containerized applications and encrypted data.”
Cellebrite, "Cellebrite Inseyets" product page, FAQ "What does Cellebrite Inseyets include?" (cellebrite.com), as fetched 2026-10-04
“Cellebrite Inseyets.UFED – Access devices and data previously unreachable and extract the Full File System data including containerized applications and encrypted data.”
Read it at cellebrite.comquote checked 2026-10-04
What SQLite’s documentation says about Write-Ahead Logging and secure_delete
SQLite’s own documentation on Write-Ahead Logging states that “The original content is preserved in the database file and the changes are appended into a separate WAL file.”
SQLite’s own documentation for the secure_delete pragma states: “When secure_delete is on, SQLite overwrites deleted content with zeros.” This page does not say which apps have that setting on, and it is not a claim that every deleted message survives.
What the sources say can remain after a deletion
Upturn’s 2020 “Mass Extraction” report, in its section on deleted data, says:
- “Mobile device forensic tools can sometimes access ‘deleted’ data from phones.”
- “Often, deleting a file on a phone isn’t permanent, and the file can be recovered — similar to how most computers have a ‘recycling bin’ for getting rid of files.”
- “Even ‘permanently deleted’ files can sometimes be recovered with the right tools, because data isn’t always physically wiped from storage when it’s deleted”, and the report adds: “it’s just marked as ‘free space’ until it’s overwritten by other data.”
- “However, access to deleted data depends on a range of factors, including phone hardware, encryption design, and extraction method.”
See Cloud and carrier for data held off the phone.
SQLite’s documentation for VACUUM says: “When content is deleted from an SQLite database, the content is not usually erased but rather the space used to hold the content is marked as being available for reuse.” It continues: “This can allow deleted content to be recovered by a hacker or by forensic analysis.”
SQLite’s database file format documentation says: “Unused pages can come about, for example, when information is deleted from the database. Unused pages are stored on the freelist and are reused when additional pages are required.” That passage says where unused pages go; it does not itself say that deleted content remains in them.
SQLite’s secure_delete documentation also says: “The default setting for secure_delete is determined by the SQLITE_SECURE_DELETE compile-time option and is normally off.” It describes a ‘fast’ setting: “When secure_delete is set to "fast", SQLite will overwrite deleted content with zeros only if doing so does not increase the amount of I/O.” Of that setting it says: “This has the effect of purging all old content from b-tree pages” and “but leaving forensic traces on freelist pages”.
Conditions under which the sources say deleted content is cleaned or generally unrecoverable
SQLite’s VACUUM documentation says: “Running VACUUM will clean the database of all traces of deleted content, thus preventing an adversary from recovering deleted content.” That sentence is about the SQLite database; this page does not say whether copies remain elsewhere on a phone’s storage. This page does not say which apps run VACUUM. SQLite’s statement about secure_delete being on is quoted at the top of this page.
NIST’s Special Publication 800-101 Revision 1 (NIST, May 2014, in a section that says “Supported devices include iPhone 3GS and iPhone 4…”) says: “When data protection is active, the file key is obliterated when the file is deleted, leaving encrypted and generally unrecoverable file contents in unallocated space, which render traditional carving techniques for deleted files useless.” The next sentence limits that: “Data however can often be found residing inside allocated data containers (i.e., SQLite Tables) and should not be discounted or ignored as part of any examination.” This page does not say that the passage describes any current iPhone.
Why the extraction method matters to deleted content
NIST’s Special Publication 800-101 Revision 1, published in May 2014, includes a classification system for mobile device tools. It describes a manual extraction method as “viewing the data content stored on a mobile device” and says: “At this level, it is impossible to recover deleted information.”
Of what it calls hex dumping, the same publication says: “hex dumping allows deleted objects and any data remnants present to be examined (e.g., in unallocated memory or file system space), which otherwise would be inaccessible through the use of logical acquisition methods.” The next sentence is the condition on that: “However, the extracted device images require parsing, decryption and decoding.” These are NIST’s 2014 descriptions, and this page does not say which current tools or devices they apply to.
For how the sources describe logical, file-system and physical extraction, see What an extraction can see.
What one report says a tool allows access to
Privacy International’s 2018 report on UK police extraction says that MSAB’s XRY Physical allows access to “system and deleted data and can use extra functionality to help overcome security and encryption challenges.” That is one report’s statement about a specific product — not a statement that any tool recovers everything a phone has ever held.
The device states used on this site are described in What a full extraction contains — off/BFU, AFU, or unlocked. None of the sources quoted on this page says whether a given tool can reach a given piece of already-deleted content on a given phone.
What Apple says about iCloud and Advanced Data Protection
Separately from anything on the phone itself, Apple’s “iCloud data security overview” states that “With Advanced Data Protection, the number of data categories that use end-to-end encryption rises to 25 and includes your iCloud Backup, Photos, Notes and more.” The same page states that you “can choose to enable Advanced Data Protection to protect the vast majority of your iCloud data” and that “If you enable Advanced Data Protection and then lose access to your account, Apple will not have the encryption keys to help you recover it.” See Cloud and carrier for what Apple separately says about iCloud content and legal process.
What this page does not claim
None of the above adds up to “everything is recoverable.” It adds up to narrower, sourced statements: SQLite’s Write-Ahead Logging documentation says the original content is preserved in the database file and the changes are appended into a separate WAL file; SQLite’s documentation says that when secure_delete is on, SQLite overwrites deleted content with zeros; and Apple’s page lists iCloud Backup among the data categories that use end-to-end encryption with Advanced Data Protection. The Upturn, SQLite and NIST passages quoted further up this page are worded as those sources word them. Whether any specific message on any specific phone is actually still retrievable is not something this page, or any general-purpose page, can answer.
Last reviewed . Next review due . No lawyer has reviewed this page — see [email protected] if you think something here is wrong.