If you extract data from iPhones for a living, Stolen Device Protection is the change you can no longer afford to ignore. It does something deceptively simple: it puts Face ID or Touch ID in front of the “Trust This Computer” prompt. The practical result is that an examiner who knows the device passcode still cannot pair an unfamiliar iPhone to a forensic workstation. That is the most disruptive change Apple has made to iPhone pairing behavior in roughly a decade, and as of spring 2026 it is switched on out of the box.

This article walks through what the feature is, how it has changed over time, what it is designed to stop, and – the part that matters most for a lab – exactly which steps of a data extraction it gets in the way of. We are also in the process of finalizing our own solution for circumventing Stolen Device Protection that will allow sideloading and using the extraction agent with protection still engaged.

What Stolen Device Protection actually is

Stolen Device Protection (SDP) is a per-device security feature for iPhone. When it is on, iOS imposes extra authentication on a defined set of sensitive actions, but only when the phone is away from a familiar location. “Familiar” here means a Significant Location the phone has learned on its own, typically home and work. Sit the phone on the suspect’s kitchen table and most of SDP relaxes; bring it into your lab and it does not.

Two separate mechanisms do the work, and it is worth keeping them apart:

• Biometric-only authentication, with no passcode fallback. For one group of actions, iOS will accept Face ID or Touch ID and nothing else. The passcode is not an option. Apple’s own wording is that these actions need biometrics “with no passcode alternative or fallback.”
• The Security Delay. For a second group – mostly account and security settings – iOS asks for a biometric, then makes you wait one hour, then asks for a second biometric. At a familiar location during that hour the wait can end early; the optional Require Security Delay > Always setting won’t shorten the delay even at home and work.

To enable SDP (or to have it enabled by iOS in recent builds; see below for details), the user needs two-factor authentication on their Apple Account, a passcode, Face ID or Touch ID enrolled, Significant Locations switched on, and Find My enabled. Once SDP is on, Find My can’t be turned off.

Importantly, SDP is iPhone-only. As of iPadOS 26.4 Apple has not extended it to iPad, even though an iPad is just as exposed to the same passcode-theft scenario. If the device on your bench is an iPad, you can set SDP aside entirely.

As for whether the feature is opt-in or opt-out – that has changed, and the change is recent. Today, on current iOS, treat SDP as on by default. More on that in the next section.

A short history and why it matters for your backlog

SDP is a moving target, and an examiner has to be precise about which version is on the bench. Here is the timeline:

The headline is the bottom of the table. From iOS 17.3 through 26.3, SDP was opt-in: the user had to find it in Settings and switch it on, and most people never did. With iOS 26.4, Apple flipped that. Per Apple’s enterprise documentation, SDP is now automatically enabled on devices set up new with iOS 26.4 or later, on devices restored on 26.4 or later, and on devices that update from 26.4 to a later build. One honest caveat worth carrying: on a brand-new setup the user does see an SDP screen, and Apple’s consumer-facing article hedges with “might be turned on by default.” The cleaner read is that updates and restores enable it without asking, while a fresh out-of-box setup presents it prominently. Either way, the examiner can no longer assume it is off.

Why does a version history belong in a forensic article? Because a lab backlog is never one version of iOS. It is a drawer of devices spanning years of releases, and the same physical iPhone behaves differently depending on the build it is running. That gives you a triage rule you can apply the moment a device is logged in:

• Pre-iOS 17.3 – SDP does not exist. Standard pairing applies: passcode plus the Trust prompt is enough to create a new pairing record.
• iOS 17.3 through 18.x – SDP exists but is opt-in. Most devices won’t have it on, but some will, especially those belonging to security-conscious owners. Check Settings → Face ID & Passcode before you plan anything.
• iOS 26.4 and later – assume SDP is on until you have proof otherwise.

Document the exact build (Settings → General → About) and the SDP state in your case notes before the first extraction step.

What SDP is meant to stop

SDP was built for one very specific threat model, and knowing that helps you reason about where it does and doesn’t get in your way.

The feature is Apple’s answer to a theft pattern that The Wall Street Journal documented in early 2023: thieves were watching iPhone owners type their passcodes in bars and other public places, then stealing the phone. The passcode alone was the whole heist. With it, a thief could change the Apple Account password from Settings, lock the real owner out of iCloud, disable Find My, harvest every credential in iCloud Keychain, move money through Apple Cash, and walk into banking apps whose logins were saved in Keychain. We had a whole article on the issue back when SDP was still in beta; check out the “What could happen if someone stole an iPhone and knows its passcode?” section in iOS 17.3 Developer Preview: Stolen Device Protection. A later WSJ follow-up profiled one Minneapolis thief who described taking roughly $300,000 from victims this way. Apple announced SDP the same week.

So the threat model is explicit and narrow: an attacker who has both the physical device and the passcode. Everything SDP does is aimed at making that combination far less useful than it used to be.

The flip side is just as important for an examiner. SDP changes nothing for an attacker who has only one of the two factors, and it changes nothing for extraction methods that never touch on-device flows in the first place – for instance, bootrom-level acquisition on legacy hardware, which is a function of the chip, not of iOS policy. SDP is an iOS-level lock on iOS-level actions. Where your method sits below that layer, SDP is simply not part of the conversation.

What SDP blocks during extraction

Apple’s documentation is written for end users, and it does not enumerate every system-level interaction an examiner cares about – so some of what follows rests on independent testing rather than Apple’s published list. Where that is the case, we flag it plainly.

Pairing the device to a new computer

This is the major roadblock. With SDP on and the device away from a familiar location, the “Trust This Computer” handshake requires Face ID or Touch ID. The passcode is no longer a sufficient credential to confirm trust. Independent forensic testing has confirmed this behavior, and it is the single most consequential effect of SDP, because creating a fresh pairing (lockdown) record is the first step of advanced logical acquisition. Notably, Apple does not list pairing among the SDP-protected actions in its support documentation, yet the behavior is real and reproducible. In a consent-absent case – suspect in custody and not cooperating, or owner unavailable – an examiner who knows the passcode still cannot establish a new pairing on a workstation. The owner’s biometrics are required, full stop.

Using a pairing record you already have

This is the realistic way around the gate, with one caveat: pairing records have a limited lifetime, and they still require unlocking the iPhone (because of USB Restricted Mode blocking USB data communications). Now, if you have a valid, non-expired lockdown/pairing record and you can unlock the phone with a passcode, you can connect it to your workstation without requiring biometric authentication (per SDP).

In other words, SDP raises the bar for creating a new pairing; there is no public testing showing it invalidates a valid, pre-existing one. The device itself must be in AFU (After-First-Unlock) state, that is, it has been unlocked at least once since its last reboot. The device must not be allowed to reboot into BFU (Before-First-Unlock) state.

Sideloading and signing an extraction agent

The code-signing itself happens on the host, and SDP does not touch host-side operations. But the agent still has to be installed onto the iPhone over USB, and that requires a working pairing and trust relationship. So SDP sits upstream of agent-based extraction: block the pairing, and the agent never reaches the device.

Account-side actions: Apple Account password and sign-out

Both are behind the Security Delay. If your plan involves iCloud-side acquisition and you need to reset the account password, you cannot do it from the seized device without the owner’s biometrics – twice, an hour apart. And while SDP is on, the same changes are blocked on the web at account.apple.com too, so there is no browser shortcut. Where cloud acquisition is the goal, plan to obtain credentials and any second factor through lawful process, not through an on-device password reset.

Turning off SDP itself (and turning off Find My)

This sits behind the Security Delay. An examiner cannot simply switch SDP off, even with the passcode, when the device is away from a familiar location. The owner has to start the change, authenticate biometrically, wait the hour, and authenticate again – and if they have chosen the “Always” setting, going to their home or workplace won’t shorten that wait.

Reset All Settings (removes unknown local backup password, of one is enabled)

This also sits behind the Security Delay. As stated, the forensic value of this function is that, among other things (such as removing the device’s passcode) it also clears the password for encrypting local iTunes/Finder style backups.

The rest of the list

Several other actions are biometric-only with no passcode fallback when SDP is on and the device is away from home: turning off “Lost Mode”, viewing or using passwords and passkeys in the Keychain, payment methods saved in Safari AutoFill, “Erase All Content and Settings,” opening Locked or Hidden apps (iOS 18 and later), Quick Start to set up another device, and setting up or transferring an eSIM. Some of these show up in real cases: Keychain access matters because the non-consensual on-device path to bulk password harvesting is now closed; Quick Start matters because it blocks a clone-device technique; eSIM transfer matters for SIM-related seizures. Worth knowing they exist so nothing surprises you mid-extraction.

The bottom line is this: without the owner’s biometrics, advanced logical extraction is effectively blocked on an SDP-enabled iPhone that is not at a familiar location – even when you know the passcode and even when the device is sitting in AFU state. A known passcode used to be the key. Under SDP, away from frequent locations, it no longer works the way it used to.

What this means in practice

A short, practical checklist for the lab:

• Triage every iPhone by iOS version on receipt. Pre-17.3 has no SDP exposure; 17.3 through 18.x needs a settings check; 26.4 and later should be assumed SDP-on. Record the exact build and the SDP state before touching the device.
• Seize host computers in parallel. Image the suspect’s Mac or PC at the same time as the iPhone and preserve the lockdown directory. A valid pre-existing pairing record is the most reliable way past the SDP pairing gate – and with a short record lifetime, you’ll have to act fast.
• Protect AFU state. Don’t let a seized phone reboot or power down. Faraday containment with pass-through power, and a documented chain of custody for the power state.
• For consensual cases, arrange the SDP toggle in advance. Ask a cooperating owner to either switch SDP off or to bring the device to its “known” location so the Security Delay is suppressed. Document the change and the location context as it happens. Note that if the protection is set to “Always”, you will still have to budget for a one-hour delay.
• Plan around the one-hour delay when there is no other path. If the only route is turning SDP off at the lab with a cooperating user, budget for it: biometric, one-hour wait, second biometric, then the extraction itself.

A note on the documentation gap

The most consequential thing SDP does to a forensic workflow (gating computer pairing behind biometrics) is the one thing Apple has not written down. That gap is not a reason to doubt the behavior; it is reproducible and well attested. It is a reason to be careful about how you describe it. Cite the empirical record, keep your own test notes current on a device matching the build under examination, and don’t lean on Apple’s support article to carry a point it doesn’t actually make. Treat all of this as accurate for a moment in time. Apple revises SDP quietly, and the relevant support pages have already been edited more than once. Validate the behavior on a representative test device before you rely on any of it in a specific case.