When an iPhone is seized and later re-examined, forensic teams sometimes find that data present in an earlier extraction are missing from a subsequent backup or filesystem image. Why exactly does that happen, what kinds of data are affected, how long do they usually live, and what can you do to preserve volatile and semi-volatile artifacts? Let’s try to find out.

The device was powered off. Why is some data gone?

It is important to understand that no data is erased while the device is powered down; information is only removed after the device is booted and unlocked. Booting iOS starts numerous background services and maintenance tasks, and many cleanup activities only run after the the device is unlocked with a passcode. Because iOS encrypts much of the filesystem, the system cannot operate on those encrypted bits until the first unlock; it is that unlock that gives the OS the ability to read, modify and garbage-collect protected data.

Once you unlock the phone to begin an extraction, background processes may begin purging old records: system logs are pruned according to their TTL policy for each event type; items in the Recently Deleted photo album will be permanently removed when their retention expires; older entries in KnowledgeC and Biome (including some location records) can be cleared; deleted iMessage messages may be purged; and Safari history entries may be removed.

These cleanup tasks do not necessarily run instantly; sometimes they finish within minutes, sometimes hours, and sometimes older records persist longer depending on system load and scheduling. In practice you may observe partial persistence for some artefacts depending on the iOS version, device state, and whether maintenance tasks run immediately after boot. Still, unlocking the device is the primary trigger that allows the system to access and modify encrypted stores.

Can this be prevented?

Data is removed by OS processes, so the simplest way to prevent OS-initiated deletion is to avoid booting the device. Unfortunately, modern Apple devices (beginning with iPhone 8/8 Plus and iPhone X families) generally require a “live” extraction that loads the OS, so simply leaving the device powered off for extended periods is not a viable option.

The only reliable way to obtain repeatable extractions is to use a process that bypasses the main OS – for example, a bootloader-level extraction. Such exploit-based methods are available for older models (up to iPhone 7/7 Plus) and, with caveats, for some iPhone 8/8 Plus and iPhone X devices running older iOS versions. Generally, checkm8-class bootrom exploits affect devices through iPhone X (A5-A11); practical extraction success depends on model and iOS version and is more restricted for iPhone 8/X on newer iOS builds (see Understanding AFU and BFU in iPhone Forensics for details).

That said, some LE-exclusive tools available in select regions may utilize lower-level exploit-based extraction techniques, targeting a limited range of chips (A11..A13, covering iPhone 8/X, XR/XS and iPhone 11 generations). These low-level methods can, in theory, allow offline or semi-offline access without a full normal OS boot, but their applicability and reliability are highly dependent on the exact device model, iOS build, and other undisclosed parameters.

When exploitation is possible, a best practice is to disable normal auto-boot behavior before the OS can start. If you use iOS Forensic Toolkit, the tool will automatically clear an auto-boot flag at session start so the device cannot accidentally boot into the standard OS (it will always reboot into Recovery mode instead). From the moment auto-boot is disabled, the on-device data remain stable until that flag is restored.

It can make sense to set a non-persistent boot flag before any OS activity begins; if your lab is equipped with tools that support offline extraction (e.g. bootloader-level), do so immediately on receipt. Record the action, the tool used, and the timestamps to preserve chain of custody and support repeatability.

Which data are we talking about?

Here are the categories of data that are known to expire or be pruned by iOS background processes, together with typical retention windows observed in the field:

• Deleted photos (from the Recently Deleted folder): documentation states 30 days from the time the user deleted them (Apple). Practical observations show that deleted photos can sometimes be obtained even after 30-40 days.
• Deleted iMessage messages: typically recoverable for 30 days on recent iOS releases, per Apple’s recovery workflow; behavior may vary by iOS version, so always note the exact OS version (Apple).
• Safari browsing history: 30 days (measured from the last visit; applies per record).
• sysdiagnose logs: snapshots, once created, are not automatically removed. However, a newly generated sysdiagnose snapshot mainly contains records for the 24 hours preceding the snapshot. Some types of records may be older, but the practical maximum timeframe of detailed sysdiagnose information is about one day. Note: creating a sysdiagnose snapshot is quick (hold both volume buttons and the power button for ~1–1.5 seconds); a snapshot created at seizure time will remain available afterwards.
• Apple Unified Logs: retention varies by the entry’s TTL class. Lifetimes range from minutes to effectively indefinite; most relevant entries are commonly retained for around 10 or 30 days.

All of the above categories can generally be recovered by a standard logical extraction. In addition, low-level or agent-based extractions can surface further artifacts that have limited retention windows:

• KnowledgeC and Biome records: typically, ~28–30 days (undocumented; observed behavior).
• Location cache (short-term cache of recent position data): 7 days.

These retention windows are approximate and reflect observed behavior under typical conditions. They should be used as operational guidelines rather than absolute guarantees – iOS internals, background task scheduling, device model and iOS version can all affect exact timing.

Practical conclusions

The practical takeaway is straightforward: extract data as soon as feasible. The sooner you perform a collection, the more potential digital evidence you will preserve. Booting (more precisely: loading and unlocking) a device a month after seizure will alter the device’s state and can irreversibly remove a range of valuable artifacts. Note that sysdiagnose snapshots are most informative when created within the first 24 hours after seizure.

The recommended workflow, therefore, looks as follows:

• On receipt, document the device state thoroughly: photograph the device, note power/battery level, and record all visible indicators.
• Where appropriate, isolate the device from networks (Faraday bag, radio isolation) to reduce the risk of remote wipe or remote changes. Be aware that network isolation does not stop local OS garbage collection once the device is booted and unlocked.
• If your toolchain supports it, prevent auto-boot into the standard OS (clear auto-boot flags or use a controlled bootloader/agent method) before performing any actions that would launch the regular operating system.
• Create a sysdiagnose snapshot immediately if you can (hold both volume buttons + power for ~1–1.5 seconds) to capture recent diagnostic data.
• Proceed with the fastest viable extraction method that preserves relevant volatile and semi-volatile artifacts: logical extraction, agent extraction, or exploit/bootloader techniques, chosen according to the device model and iOS version.
• Log exact timestamps for every action to preserve a reliable timeline and to explain any differences between sequential extractions.

iCloud copies and remote-erase caveats

Broadly speaking, Apple’s iCloud ecosystem follows similar retention policies to on-device data: deleted photos and iMessage conversations are supposed to remain recoverable for about 30 days. In practice, however, the situation is more complex. While iCloud Photos retain deleted items for 30 days in the ‘Recently Deleted’ album (per Apple documentation, may be longer in practice), for Messages in iCloud, deletions propagate across devices immediately, but local backups or unsynced copies may preserve older content.

• Once an iCloud backup is created, it remains on Apple’s servers until it is explicitly deleted by the user or automatically removed after a long period of inactivity. The data inside an existing backup are static – they do not change even if the user later deletes or edits items on the device. As a result, an older backup may still contain evidence that is no longer present on the phone itself.
• Field observations show that some iCloud-stored data may persist far longer than the nominal 30-day retention period described in Apple’s documentation. Forensic examiners have occasionally recovered cloud-based artifacts months after local copies were gone.
• Apple provides a mechanism for law enforcement to preserve user data during an investigation. When served with a lawful preservation request, Apple can freeze a user’s iCloud account data, preventing modifications or deletions until the request expires or further legal process is completed. This ensures that potential evidence is retained intact for official review.

To sum it up, data accessible in iCloud backups and synced containers may survive device changes, especially considering that the last iCloud backup could be made well before the device was seized. We strongly recommend performing iCloud extraction with Elcomsoft Phone Breaker in addition to device-based extractions.