The iPhone Inactivity Restart in a Research Corpus: Rare, Near 72 Hours, and Readable Only Briefly

1 Introduction

Since iOS 18.1, an iPhone that stays locked for about three days restarts itself and returns to the state in which most user data are encrypted again (before first unlock, BFU). Apple documents the behaviour as Automatic Restart [1]; it was reverse engineered and measured on one device by Classen [2]; the press reported that law enforcement had seen iPhones restart on their own [5], and a forensic vendor described the effect on examinations [4]. For an examiner the consequence is practical. A phone that arrives in BFU may have been restarted by this feature, by its user, by an update, by a crash, or by handling, and the report has to say which, or say that it cannot.

A motivating example. A phone is unlocked on a Friday at 09:10 and locked at 09:12. On Monday at 09:27 the extraction shows a shutdown at 09:27:20 and a boot at 09:28:05 (Figure 1). The time from the last lock-state record to the shutdown is 72 h 15 min, which is what the documented behaviour predicts. If the shutdown line is the only record that survives, the same restart could be a user’s. The lock-state records that settle the question exist on the phone, but they lose their content after about four weeks and their timestamps after about ten.

The problem. Three things are not known. How often do restarts of this kind occur in phones that were not selected for the question? Does the idle time before restarts agree with the documented period in both directions: restarts at about 72 hours, and no long idle stretch without one? And how long after a restart can the records still show which kind it was? We ask four questions.

• RQ1 (Records). Which records show a restart and the idle time before it, and how far back does each reach?
• RQ2 (Occurrence). How many restarts follow an idle time consistent with the documented period, on how many phones, and what idle times do the other restarts follow?
• RQ3 (Fit). Does the corpus agree with the documented behaviour in both directions, and what does a phone running an earlier release show?
• RQ4 (Rule and age). Can a rule label a restart as consistent with the documented behaviour, with what error on synthetic phones where the cause is known, and for how long after the restart can the idle time be read?

Table 1 gives the answers.

Contributions. This report makes four contributions.

• A way to bound the idle time before a restart from the timestamps of lock-state records whether or not their content survives, with the assumptions stated and a three-way label (in the band, shorter, longer) (Section 3.4).
• The first measurement we found of restarts consistent with the documented behaviour: 33 iOS extractions and two sysdiagnose archives, 13,487 restart events, and the idle time before 1,748 of them (Sections 4.2 and 4.3).
• A test of the documented behaviour in both directions on the same data, with an earlier-release group as control, and the cases that do not fit (Section 4.4).
• The reach of every record involved, the share of restarts whose idle time can still be read, by age, and a reading guide for examiners (Sections 4.1, 4.5 and 5).

Scope. The corpus phones are research phones, not a sample of phones in use. The report counts restarts consistent with a documented behaviour; it does not show that any single restart was caused by it, because the log line that names the cause could not be read.

2 Background and Related Work

2.1 What is documented

Apple’s Platform Security guide describes Automatic Restart as a mechanism in iOS 18.1 and later that relies on the Secure Enclave to watch unlock events: a device that stays locked for “a prolonged period” restarts, moves from the after-first-unlock (AFU) to the BFU state, and purges keys and transient data from memory; from iOS 18.4 a management setting can switch it on or off, and the page says it is off by default on supervised devices [1]. The page gives no duration. Classen’s reverse engineering gives the mechanism: the Secure Enclave tracks the time of the last unlock and, after three days, tells a kernel extension, which asks user space for a graceful restart; if the restart is blocked, the kernel panics; at the next start the keybag daemon sends an analytics event with the idle time. She observed the restart at exactly 72 hours [2], [3]. A vendor blog, a news report and a trade-press report confirm the period and describe the effect on examinations [4]–[6]; two sources report an earlier period of seven days in the first release of iOS 18 [2], [4], which we do not use. A press item reports a video in which a vendor is said to keep the AFU state across a restart; the mechanism is not described [7]. The Android equivalent is a Google Play services feature that restarts a device locked for three consecutive days [8], and a hardened Android distribution restarts a locked device after a configurable timeout, 18 hours by default [9]. We did not measure Android and found no documented on-device record of an Android restart for this cause.

2.2 Records of restarts and of lock state

The shutdown log lists reboots with a timestamp and the processes still running; Yamout used it to look for spyware and observed entries reaching back years [10], and Afonin found entries back to the activation of a test phone [11]. Boot sessions and their start times are in the time-sync files of the unified log, whose format Metz describes [13]. The Biome streams use a segment format whose second version has a 32-byte header, entries, and a trailer of 16-byte records that give an end offset, a state (1 written, 3 deleted) and a timestamp [12]. Our observation is that a deleted entry loses its content but keeps its trailer record, and with it its timestamp. The Lab has measured how far back several of these stores reach [18] and how often phone clocks disagree with them [19]; the Android reset indicators of the earlier work [17] are the nearest relative, and which questions a phone can answer at a given date is the subject of another report [20]. This report adds the lock-state streams and a rule on restart events.

2.3 Prior measurement

We searched arXiv, Zenodo, OpenAlex, Crossref, Semantic Scholar, dblp, and the web for papers on restarts of locked phones, the BFU and AFU states and the shutdown log (the log of queries is in the Lab’s notes; the ACM Digital Library, the DFRWS pages and the journal’s search were not reachable and were searched through a web search engine only). We found no measurement of how often the restart occurs. A 2026 study of parental controls states in one sentence that automatic restarts can force devices into BFU and cites the reverse engineering [14]. A 2024 study measures the data available in a BFU extraction [15] (known to us from its record only), and Zinkus, Jois and Green analyse the encryption protection classes of iOS, including the after-first-unlock class [16].

Position. The mechanism is known. What is new here is a population count, a test of the 72-hour period against records instead of a demonstration on one device, a rule that works on erased records, and the reach of the records. What is replication is the period itself, which we confirm only in the sense that four restarts agree with it.

3 Method

3.1 Corpus and frame

The frame is the iOS full file system extractions in the Lab’s census of its research corpus, less one byte-identical copy and one second extraction of the same handset. Comparisons of device identifiers recorded in private notes show that the remaining 33 extractions come from 33 phones; a further comparison of hashed boot identifiers found no boot session shared by two of the 26 that hold boot records. We split the phones by the iOS version recorded on the phone: group A runs iOS 18.1 or later (23 phones), group B runs an earlier release (9 phones, the control), and one phone has no readable version. The phone’s version at acquisition is not its version throughout the history; Section 6 discusses the effect. Two sysdiagnose archives of different phones were also read (Section 4.7). Table 2 gives the frame.

3.2 Records read

A runner read each archive in place and kept only what Table 3 lists. It read the time-sync files, the shutdown log, four Biome streams (boot session, screen lock, keybag lock, display backlight) and the isLocked rows of knowledgeC, and the header time of each unified-log file to measure its reach. It did not resolve the unified log’s format strings, so the kernel line that Classen names [2] is not available to us; we searched the decompressed log of one phone for the literal strings and found none. Of the 28 phones with a screen-lock stream, 25 use the second segment version, which the parser follows [12], and 3 older phones use a layout that we parsed from the files (Section 6). As a check of the parser, 56,830 of 57,434 live screen-lock entries inside the span of the knowledgeC rows (98.9 percent) have a knowledgeC row that starts within two seconds, among them 128 of 132 entries of the older layout. The runner also read whether the phone was supervised and whether its settings carried a restriction whose name contains “idle”, “reboot” or “restart”.

3.3 Restart events

A restart event is a shutdown-log line, or a boot (a time-sync boot record or a Biome session start) that has no shutdown line in the 600 seconds before it. The second kind is a boot-only event: the shutdown was not recorded, and the boot time stands for it. Times before 2014 (clock not yet set) and after the acquisition time are dropped. Acquisition time is the end time in the extraction’s metadata where it exists and the container file’s time otherwise.

3.4 Idle time and the rule

For a restart event at time s, let Q be the time from the last lock-state record before s to s. A lock-state record is an entry of the screen-lock stream or a row of the knowledgeC stream, live or erased: a live entry has a value (locked or unlocked), an erased entry has only its timestamp. We count only records after the start of the boot that contains s and after the previous restart event, so that the lock screen shown at boot does not count, and we require the stream to reach back at least one hour before s. Three assumptions are needed.

• A1. Every lock or unlock writes an entry, and an erased entry keeps its timestamp.
• A2. The documented restart follows the last unlock by 72 hours plus a delay of less than one hour.
• A3. The last unlock precedes the last lock-state record by less than one hour (a screen-on session shorter than an hour).

Under A1, Q is a lower bound of the time U since the last unlock, because a later unlock would have written an entry. Under A3, U is at most Q plus one hour. The rule labels a restart in the band if 71 h ≤ Q ≤ 73 h (with 60 seconds of slack), short if Q is smaller and long if larger (Listing 1). The upper edge is the documented period plus one hour of delay (A2); the lower edge is the documented period less the one hour of A3. “In the band” means consistent with the documented behaviour. It does not mean caused by it. Section 3.6 says which parts of the band were set before the data were seen.

for each restart event s in E:
    t0  := latest boot start before s-5 s, or previous event
    R_s := records of R in (t0, s+1 s]      # live or erased
    if R_s empty and R reaches t0:  "no record since start"
    elif R starts after s-1 h:      "beyond reach"
    else:
        Q := s - latest time in R_s
        "in band" if 71-1/60 <= Q <= 73+1/60
        "short"   if Q < 71-1/60;  else "long"

3.5 Synthetic phones

To measure the rule’s error where the cause is known we built 3,000 synthetic phones of 120 days each for every scenario. A phone has a usage class (mean idle time 2, 8, 30 or 90 hours); a screen-on session lasts a log-normal time with a median of 90 seconds (capped at one hour); 3 percent of idle gaps are lengthened by 3 to 9 days of absence; restarts come from four causes: inactivity (72 hours after the last unlock plus a delay with a median of 5 minutes, capped at 50 minutes), user, update (while locked) and crash (no shutdown line). The lock-state stream keeps content for 28 days (standard deviation 1.5) and timestamps for 40 to 130 days. One scenario keeps the assumptions; the others break them one at a time or together: 10 percent of inactivity restarts delayed by 1 to 6 hours (A2), 2 percent of records lost (A1), and 5 percent of sessions of 1 to 4 hours (A3). The fixtures follow the documented behaviour and a simple usage model; they are not calibrated to the corpus.

3.6 Order of work and the choice of band

The frame, the records, the restart events and the idea of bounding the idle time were fixed before the first full run. The period is not ours: the sources in Section 2.1 give 72 hours [2], [4]–[6], and Apple’s page gives none [1]. The first run used the band 72 to 73 hours, the period plus one hour of delay. After a first look at the distribution of Q we made four changes, all post hoc and before the final run: the lock state comes from the screen-lock and knowledgeC streams, not the keybag stream; boot-only events were added after we found a phone with no shutdown log; each session is cut at the previous start, after we found sessions that were off for days; and the lower edge of the band was widened from 72 to 71 hours after the fixtures showed that session length shifts Q (A3). The widening added no restart: the four restarts lie between 72 and 73 hours and none between 71 and 72 (Table 4). We cannot show that the one-hour width of the first band was written down before the first idle times were computed, so the headline count of four rests on 72 to 73 hours, and the rule’s band of 71 to 73 hours is reported beside it. The chance calculation in Section 4.3 depends on the band and on the range of Q it is compared with, and we give its sensitivity there. The control group is not independent of the band.

4 Results

4.1 What the records hold and how far back (RQ1)

The list of restarts goes much further back than the evidence for their cause (Table 3, Figure 2). Time-sync boot records reach back a median 255 days (quartiles 84 to 753; up to 2457), the shutdown log 183 days. The Biome session stream keeps the timestamps of its entries for 172 days and their content for 24. The lock-state stream keeps content for 28 days (quartiles 27 to 29) and timestamps for 72 (53 to 109). The unified log reaches back 24 days. Two sources of restart events disagree rarely: in group A 6,344 of 6,433 shutdown lines (98.6 percent) have a boot record before the next shutdown, and 6,357 of 6,412 boots (99.1 percent) have a shutdown line since the previous boot (inside the common reach of the two lists, 20 phones).

4.2 Restarts in the corpus (RQ2)

Group A holds 13,487 restart events: 9,343 shutdown lines and 4,144 boot-only events. A phone restarts a median 9.6 times per 30 days (quartiles 5.3 to 20.6, 22 phones, range 0.9 to 208), computed from the boot records; the three group B phones with boot records restart 0.9 times (range 0.7 to 2.0). 533 of 6,908 boot sessions of group A (7.7 percent) end without a shutdown line. A restart count is dominated by a few phones: of the 1,748 restarts of group A with a readable lock history, one phone holds 35 percent and three phones hold 68 percent (median 23 per phone, maximum 613). We therefore report counts of phones next to counts of restarts.

4.3 Idle time before a restart (RQ2)

For 1,748 restarts of group A the lock-state records reach back to the restart and the session holds a record (10,636 restarts are older than the records and 1,103 follow no lock-state record since the previous start). Table 4 gives Q in classes. 89.8 percent of the restarts followed a lock-state record within an hour, which is what restarts by a user in a session look like. 164 restarts followed 1 to 24 hours of idle time and 9 followed 24 to 71 hours. Four restarts fall in the documented band of 72 to 73 hours, on 3 phones, with Q of 72.03, 72.09, 72.26 and 72.37 hours (Figure 3): 1.7, 5.4, 15.6 and 22.0 minutes above 72 hours. None lies between 71 and 72 hours. One restart followed 75.0 hours. The documentation anchors the timer at the last unlock, so Q, which starts at a later record, is not expected to exceed 72 hours by much. We cannot tell whether the timer runs from the unlock or from the lock, or how often it is checked.

How unusual is the cluster? 4 of 1,748 restarts is 0.23 percent (95 percent Wilson interval 0.09 to 0.59); 3 of 23 phones is 13 percent (5 to 32). Among the 14 restarts of group A with Q from 24 to 100 hours, 0.37 would fall in a two-hour window if they were spread evenly; 4 did (probability of this many or more 3.9e-04), and no other two-hour window held more than 3. This is descriptive. The range and the window were chosen after the data were seen. The window’s position was not free, because 72 hours comes from the sources, so we apply no correction for position; a Bonferroni correction over the 38 disjoint two-hour windows of the range would give 0.015. With lower limits of 12 and 24 hours, upper limits of 96 to 170 hours and windows of one and two hours the probability runs from 2e-06 to 3e-03. An even spread is not a model of Q, whose density falls with Q, and two of the four restarts are on one phone; the figures show how unlike an even spread the cluster is, not how likely it is by chance. The keybag-lock stream, which we did not use for the rule, also finds 4 restarts in the band out of 1,989. Widening the band to 76 hours adds one restart and one phone.

4.4 Control and completeness (RQ3)

The 30 readable restarts of the 3 earlier phones have none in the band. 8 of them followed more than 24 hours of idle time, and 10 followed 12 hours or more, from 12.6 to 170.6 hours; five followed more than 96 hours (Figure 3). That is what a phone without the feature does: it restarts when someone restarts it. The control is three phones, and for six of the nine earlier phones the restart records are absent, so it shows only that the band is not filled by earlier phones.

The other direction asks whether a phone that stayed locked for 71 hours always restarted. Of the 38 intervals of at least 71 hours between lock-state records of group A, 6 start with a live locked record after an unlock in the same boot. Five end in a restart (first restart 29.6, 50.3, 67.3, 72.4, 75.0 hours after the interval began); three of them restarted before 71 hours, so the timer was not reached. Of the three that reached 71 hours, one restarted at 72.4 hours, one at 75.0 hours, and one (257 hours) has no restart record at all. Intervals that start with an erased record add two restarts in the band and four intervals without a restart record, none of which can be shown to be locked. A missing restart record is weak evidence: boot records and shutdown lines agree for about 99 percent of restarts, but they are not complete, and the 257-hour interval may hide a restart whose records are missing. We report it as unexplained. No supervised phone and no restriction named for idle, reboot or restart was found on the 32 phones with a readable configuration.

4.5 How long the idle time can be read (RQ4)

The restart is visible for far longer than its cause (Figure 4). Of the 2,477 restarts of group A that are up to 56 days old, the rule gives an idle time for 1,480 (59.8 percent). For another 982 (39.6 percent) it finds no lock-state record since the previous start, which leaves the idle time unread, and for 15 (0.6 percent) the records do not reach back. From 56 to 112 days the share with an idle time falls to 15.4 percent (196 of 1,276), and beyond 112 days it is 0.7 percent (72 of 9,734 restarts). The content of the lock state is known for 60.0 percent of the restarts with an idle time; for the others the idle time rests on the timestamps of erased entries. The four restarts in the band were 4, 67, 76, 91 days old at acquisition; one of them has a live record.

4.6 The rule on synthetic phones (RQ4)

Table 5 gives the rule’s labels on the synthetic phones. When the assumptions hold, every readable inactivity restart is in the band and 0.12 percent of other readable restarts are too (47 of 8,337 update restarts and 25 of 5,193 crashes; no user restart). Delayed restarts (A2) are labelled long, long sessions (A3) short, and lost records cause a few wrong labels; with all three broken 86.5 percent of readable inactivity restarts are in the band. At the corpus’s rate of 0.23 percent in the band, the fixtures put the probability that an in-band restart is an inactivity restart at 65 to 68 percent across the scenarios. The corpus’s own other long-idle restarts suggest fewer false members (0.37 expected in the band against 4 found). We treat these as consistent with the documented behaviour, not as proof for any one restart.

The corpus measure of A3 is 24,842 sessions of group A with a median of 101 seconds, of which 2.3 percent (572) last an hour or more; the fixtures’ 5 percent is above that rate.

4.7 Sysdiagnose archives

The readable sysdiagnose material comes from two phones: one by several captures on different days that share all their boots, one by a single capture (boot identifiers hashed and compared in private notes). The archives hold time-sync files and the shutdown log but no Biome or knowledgeC stream. The first phone lists 69 boots and 13 shutdown lines, the second 149 boots and 110 shutdown lines. A sysdiagnose therefore counts restarts but cannot label them. Four further archives were truncated before the time-sync files and gave nothing. None of the archives share a boot with an extraction.

State at acquisition. Of the 22 phones of group A with a readable lock history, none lacks an unlock record in its last session: all of them were in the AFU state when their extraction ended.

5 Discussion

What a restart supports. Table 6 gives what an examiner can say for each reading. A restart in the band, with the idle time read from lock-state records, is consistent with the documented behaviour; by itself it does not exclude a user or an update that came at the same moment. A restart after a short idle time is not the documented one. A restart without lock-state records is not classified.

For custody. The restart is a property of the phone, not of handling, but the time a phone sits locked is a property of handling. 4 of the 1,748 restarts we could read came 72 hours after the last lock-state record; any phone that waits three days is exposed. Because the records that identify the restart lose their content after about four weeks and their timestamps after about ten, the useful action is to read them early. The restart list (hundreds of days) and the shutdown log are the long-lived part.

Why the count is small. The corpus phones are research phones, and most of their restarts follow a lock-state record within an hour, which suggests use or testing; we do not know why they were restarted. The count says that the behaviour is rare in this corpus, not that it is rare in custody or in use.

6 Threats to Validity

Internal validity. The rule, the fixtures and the runner were written by the same authors and not checked against an independent implementation. A1 is the weakest assumption: a stream that missed an unlock would raise Q, and a phone that stays unlocked writes no lock entries while it does. The band was widened after the fixtures were run (Section 3.6). The group split uses the version at acquisition; a phone that was updated inside the window may have restarted under an earlier release, and a restart older than the update would be in the wrong group. All five restarts near the band are dated 2025 or later. The older segment layout was parsed from the files, not from a description. The log line that names the cause was not read, so no restart is shown to be caused by the feature.

Clocks and time zones. Every source stores absolute (epoch) time, so a time-zone offset does not enter Q, but a step of the phone’s clock between the last lock-state record and the restart would shift it. For the four restarts in the band and for those at 75.0 and 67.3 hours we read the time-sync records of the boot session that holds the restart. Each session has sync points from before the last lock-state record to the restart; the largest jump of the wall clock against the continuous clock between two points is 0.84 seconds. In one band session the recorded time-zone offset changes, which does not affect Q. A clock error therefore cannot explain the four values: it would take four unrelated steps that each leave Q within 22 minutes of 72 hours. The check was made once, after the main analysis, with a separate script (clock_check.py in the artifact) and covers these six restarts only.

Construct validity. Q measures time since a lock-state record, which stands for the time since the last unlock only under A3. A boot-only event uses the boot time, a few tens of seconds after the shutdown. For 15 of the 33 phones the acquisition time is the container file’s time, which may be later than the extraction, so their reach in days may be too large. The ratio of restarts is a count of records and depends on how often a phone was restarted by hand.

External validity. 33 research phones, 23 of them in group A, with a few phones holding most restarts, are not a sample of phones in use. The control group is three phones. The results describe this corpus and these releases.

Limitations. We did not run a controlled experiment; a test phone left locked for three days with a known unlock time would give a positive control and the restart delay. Nothing here measures how often phone clocks change beyond the six restarts checked above, and we did not examine Android.

7 Conclusion

Four of 1,748 restarts with a readable lock history, on 3 of 23 phones running the feature, followed 72 hours of idle time; no earlier phone had one, and the other restarts followed use or short idle times. The documented behaviour is therefore visible in this corpus, but rare, and not every long locked interval ends as documented. The records that show it are short-lived: an idle time can be read for 59.8 percent of restarts up to eight weeks old and for 0.7 percent of those beyond 112 days. An examiner should read the lock-state streams as early as the extraction allows, state the idle time as a bound, and call a restart consistent with the documented behaviour, never caused by it. A controlled run on a test phone, and an Android measurement, are the next steps.