The incident call started with a sentence I’ve heard too many times: “They watched him type the passcode in the pub, then took the phone off the table.” Contractor’s personal iPhone, iOS 18.6, work accounts synced into Apple’s Passwords app. The thief had the passcode. On paper that’s game over — passcode unlocks the device, passcode reveals saved credentials, passcode changes the Apple Account password and locks out the real owner.
Except it wasn’t game over. Stolen Device Protection was on. That’s the whole story of why I moved a chunk of our personal-device population off a third-party manager, and it’s worth being precise about what actually saved us.
What the setting actually gates
SDP shipped in iOS 17.3. The mechanism is two things working together, and the second one is the part people miss.
When your iPhone is away from a familiar location — somewhere other than home or work, which the OS learns over time — sensitive actions require Face ID or Touch ID with no passcode fallback. Not “biometric preferred.” No fallback. That covers viewing and exporting saved passwords. A thief with your passcode standing in a pub cannot get into the vault, full stop.
On top of that, the most destructive actions get a one-hour security delay: biometric, wait an hour, biometric again. Changing the Apple Account password. Signing out. Turning off Find My. And — the bit that closes the loop — turning off Stolen Device Protection itself. The thief can’t just disable the thing that’s stopping him. He’d need your face, twice, an hour apart, which is a long time to keep a stolen phone with Find My screaming at it.
The thing I got wrong the first week
I assumed SDP wrapped everything. It doesn’t, and telling people otherwise would’ve burned trust the first time someone tested it. Day-to-day autofill still works. Unlocking the device still works on passcode. Face ID alone, at a familiar location, is enough for most of it. That’s deliberate — the whole point is to not make your own phone unusable — but it means the protection is location-shaped.
Which is also the limitation you have to say out loud: if the phone is stolen at home or at the office, a familiar location, SDP mostly stands down. The pub saved us. A burglary would not have. And the familiar locations have to be learned first, so a brand-new device is soft for a while.
Why 1Password can’t do this, and it’s not their fault
A third-party manager runs on LocalAuthentication. It can ask for biometrics with LAPolicy.deviceOwnerAuthenticationWithBiometrics, and it can refuse to fall back to the passcode. What it cannot do is ask the OS “am I standing somewhere familiar right now?” — that signal is private to the platform. It also can’t stop the device passcode from resetting Apple Account credentials at the system level. SDP isn’t a better app. It’s an authentication boundary sitting below the app, wired into the Secure Enclave and location. No entitlement exists to rent that.
I’m not going to pretend third-party managers lose on every front. Cross-platform is still theirs — Windows, Android, a browser on a locked-down work laptop. Shared vaults with real role separation are more mature. If half your fleet isn’t Apple, that decides it before security does.
What I’d tell the next admin
You need iOS 17.3+ for SDP and iOS 18.0 / macOS 15 for the Passwords app itself. Turn it on at Settings > Face ID & Passcode > Stolen Device Protection, set the delay to “Away from Familiar Locations,” and confirm it after every major migration because I’ve seen it silently off on restored devices.
And here’s the sharp edge: there is no MDM payload or declarative configuration that forces SDP on. On personal and BYOD devices it’s a checkbox the user owns, which means your rollout is a communications problem, not a config profile. Write the one-paragraph instruction, make people actually do it, and verify. The Secure Enclave will handle the rest better than any master password ever could.