Why do some stored credentials survive a stolen-device attack while others do not?

The risk depends on how the secrets were protected on the device. Credentials stored in the most restrictive keychain class are unavailable until the device is unlocked, while always-accessible items can be read earlier. Encryption tied to the device hardware also limits what can be recovered from backups, which is why protection class choices materially change exposure.

Why storage class determines whether a stolen device can still yield credentials

Stored credentials do not all fail the same way after device theft because the protection boundary is different. Some secrets are only released after the device is unlocked, so a thief who has the hardware but not the unlock state cannot read them immediately. Others remain available to software earlier, which makes them recoverable if the device or its backup is accessed.

The practical distinction is whether the protection is tied to user presence, device state, or only to the stored file itself. If the credential store is designed to require an unlocked device state, theft alone is not enough. If it is merely encrypted at rest without a strong runtime unlock gate, the attacker’s window opens much earlier.

Why hardware binding changes backup and recovery exposure

Some credentials survive theft because they are not just encrypted, they are also bound to device hardware or secure hardware-backed keys. That matters when backups, sync copies, or offline exports exist, because a copied secret is only as safe as the weakest place it was duplicated. Hardware binding narrows what can be recovered outside the original device boundary.

This is why a stolen-device event is often really two problems at once, live device access and data replication risk. A credential that is safe on the handset may still be unsafe if it was previously copied into a backup set, migration bundle, or exported store with weaker protection. The exposure changes with the protection class, not just with whether encryption exists.

What practitioners should compare when judging survivor versus recoverable secrets

The question is less “was it encrypted?” and more “what unlock condition, key source, and copy path protected it?” Credentials that depend on an unlock state, hardware-backed key material, or a protected enclave are harder to extract from a stolen device than always-accessible items or secrets that live in portable backups. That is the real reason some credentials survive the theft event.

Different credential types also behave differently in practice. A token cached for convenience, an API key stored for unattended use, and a user secret placed in a restrictive keychain class do not carry the same post-theft risk. The store design decides whether theft becomes immediate disclosure, delayed disclosure, or no practical disclosure at all.

Risk and Threat Considerations

Stolen-device attacks often succeed not by defeating encryption directly, but by exploiting the weakest access state attached to the secret. If a credential is available before unlock, mirrored into backups, or exported into less protected storage, the attacker may recover it even when the device itself stays locked.

Failure mechanism: The protection class permits access too early, or the credential is duplicated into a recovery path that is easier to exfiltrate than the original store.

Impact: The attacker can reuse the credential to access downstream services, impersonate the user or workload, and extend the incident beyond the stolen device itself.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Non-Human Identity Top 10 addresses the attack surface, NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
NIST SP 800-53 Rev 5	IA-5 — Authenticator Management	Covers credential lifecycle and storage protection after device compromise.
	IA-9 — Service Identification and Authentication	Applies when stored credentials authenticate services or workloads on the device.
	SC-28 — Protection of Information at Rest	Directly addresses encryption and protection of stored secrets on lost devices.
Recommendation — Rotate and revoke exposed authenticators quickly, and reduce long-lived stored secrets. Bind non-user credentials to stronger service authentication and minimize replayable storage. Use hardware-backed protection for sensitive stored credentials and backups.
ISO/IEC 27001:2022	A.8.24 — Use of cryptography	Relevant because cryptography and key protection determine whether stored secrets survive theft.
Recommendation — Apply device-bound cryptographic protection to secrets that must remain confidential offline.
CIS Controls v8	CIS-3 — Data Protection	Covers protecting stored sensitive data and reducing exposure from lost devices and backups.
Recommendation — Classify and protect stored credentials according to their theft exposure and recovery paths.
OWASP Non-Human Identity Top 10	NHI-02 — Secret Leakage	Stored credentials that survive theft are a secret leakage problem when exposure paths are weak.
	NHI-07 — Long-Lived Secrets	Long-lived stored credentials are more likely to remain usable after device theft.
Recommendation — Keep secrets out of accessible storage and backups that a thief can later extract. Shorten secret lifetime so stolen devices yield less reusable credential material.

Practitioner Guidance

What to verify: Check which secrets are locked to device unlock, which are hardware-bound, and which are present in backups or sync paths. If the same credential exists in more than one place, treat the weakest copy as the effective protection level.

Decision rule: If a credential can still authenticate after device theft, prioritize its rotation or revocation before you rely on any forensic assumption about whether the device was unlocked.

Practitioner takeaway: The decisive question is not whether credentials are encrypted, but whether an attacker can reach a usable copy without the original unlock state or device-bound key.