WhatsApp moves cloud chat backups to passkeys. Here’s what changes for DFIR.

WhatsApp is rolling out passkey-encrypted chat backups for iOS and Android, letting users protect backup restores with Face ID/Touch ID, Android biometrics, or the device screen lock instead of a password or 64-digit key (BleepingComputer; The Verge). End-to-end encrypted (E2EE) backups themselves aren’t new-WhatsApp shipped them in October 2021 with a password or 64-digit key option and an HSM-backed Backup Key Vault design (Meta Engineering)-but the gate to restore is now a platform passkey instead of something you type. Enable path remains: Settings → Chats → Chat backup → End-to-end encrypted backup (BleepingComputer).

Overview

This change primarily affects acquisition and restore workflows rather than active intrusions. The restore path has shifted:

• Before: Restore required the backup password or the 64-digit key; that key could be user-managed or password-wrapped in WhatsApp’s HSM-based Backup Key Vault (Meta Engineering).
• Now: Restore prompts a passkey ceremony controlled by the OS credential provider (Apple Passwords/iCloud Keychain or Google Password Manager). Users authenticate with biometrics or device PIN/passcode; the private key never leaves the device/keychain (Apple: About the security of passkeys; Google: Passkeys supported environments).
• Storage backends stay the same: iOS uses iCloud; Android uses Google Drive; both were supported for E2EE backups since 2021 (Meta Engineering; MacRumors 2021 rollout). Google may delete inactive WhatsApp backups that aren’t updated for ~5 months (Android Police).

Here’s why this matters for forensics: passkeys are backed by platform hardware (Secure Enclave on Apple; TEE/StrongBox-backed Keystore on Android), and the private credential is non-exportable. That changes restore-based acquisition from “know the password/key” to “control the user’s passkey factors and device” (Apple Platform Security; Android Keystore; AOSP KeyMint/Keystore behavior).

Acquisition and Extraction

• Validate whether the device has E2EE backup enabled and note the platform: iOS → iCloud; Android → Google Drive (BleepingComputer; Android Central).
• Confirm passkey availability on the platform account: Apple passkeys live in iCloud Keychain; Google passkeys live in Google Password Manager and can sync cross-device (Apple; Google).
• If a restore attempt is necessary, plan for live device presence and screen-unlock cooperation; passkeys require local user verification and do not expose the private key (Apple; Android Keystore).

Artifact Locations and Paths

Even with stronger cloud-backup gating, device-resident artifacts still matter.

• iOS (device acquisition)

  • Primary databases within the WhatsApp app group container (full file-system or compatible backup extraction):
    • ChatStorage.sqlite (messages), CallHistory.sqlite (calls), ContactsV2.sqlite (contacts) under the WhatsApp app group (e.g., App Group path with group.net.whatsapp.WhatsApp.shared) (Belkasoft; Cellebrite CTF write-up showing ChatStorage.sqlite path in AppGroup).
  • Note: Local iOS keychain/file protections apply; app data visibility depends on extraction method and whether the device is unlocked at collection time (Apple Platform Security).

• Android (device acquisition)

  • Local backup files on internal storage: Internal Storage/Android/media/com.whatsapp/WhatsApp/Databases/ containing msgstore.db.crypt14/crypt15 and dated snapshots (Android Police).
  • Decryption keys:
    • Legacy: /data/data/com.whatsapp/files/key (root/full-FS required) for crypt12/14 (wa-crypt-tools).
    • E2EE backup (crypt15): msgstore.db.crypt15 plus encrypted_backup.key or the 32-byte hex key generated when enabling E2EE backup (pre-passkey flow) (whatsapp-chat-exporter docs).

• Cloud surfaces

  • iCloud (iOS): WhatsApp backup is managed via WhatsApp settings and stored in iCloud; users can enable E2EE and previously chose a password or 64-digit key to restore (MacRumors how-to; Meta Engineering).
  • Google Drive (Android): WhatsApp backups are tied to the Google account and phone number; old or inactive backups may be removed after months of inactivity (Android Central; Android Police).

Analysis and Correlation

This change reduces opportunities for credential-based abuse of backups and shifts risk to device theft and localized coercion.

• Passkeys are phishing-resistant and authenticate without a shared secret; the private key remains on the device or within the password manager’s E2E-encrypted store (Apple; Google).
• Expect fewer successful remote-restore attempts using guessed/compelled backup passwords. Adversaries must control a trusted device (or synced passkey context) and satisfy local user verification (biometric/PIN) to restore (Apple; Android Keystore).
• If your enterprise allows WhatsApp on managed devices, watch for:
  • Device loss/theft events correlating with WhatsApp re-registration or restore.
  • Account-level changes: creation of new passkeys or new devices joining the Apple/Google passkey syncing circle (visible to the user in platform UIs; passkeys sync across devices for Apple/Google password managers) (Apple iCloud Keychain overview; Google passkeys).

Validation and Pitfalls

• Preserve the live state. If you anticipate needing a backup restore (e.g., to a clean device for analysis), prioritize maintaining an unlocked state under warrant/consent and document the user-verification factors available (biometric enrolled; device passcode/PIN). Passkey restores require those local factors (Apple; Google).
• Prefer on-device extractions first. Full file-system or app-sandbox acquisitions still yield ChatStorage.sqlite (iOS) and msgstore/wa.db plus media (Android), independent of cloud backup gating (Belkasoft; Android Police).
• If you must restore from cloud backup:
  • iOS: You’ll need the Apple account context with iCloud Keychain enabled and a passkey ceremony on a trusted device (or equivalent recovery) to unlock the backup’s encryption key under the new model (Apple).
  • Android: You’ll need access to the Google account’s passkey store and local device user-verification to complete the ceremony in WhatsApp during restore (Google).
• Adjust legal language. Where collection templates referenced “WhatsApp backup password/64-digit key,” update to “device-resident passkey factors for the Apple/Google account used by WhatsApp” and the specific device(s) on which the passkey is available. This reflects the 2025 change to passkey-gated backup restores (BleepingComputer; The Verge).

Reporting Notes (chain of custody, reproducibility)

• Passkeys for WhatsApp logins arrived earlier (Android in 2023; iOS in 2024); 2025 extends passkeys to backup restores. Expect fewer password-based restore artifacts in casework notes and more device-present ceremonies (TechCrunch 2023 Android; TechCrunch 2024 iOS).
• The 2021 E2EE backup design placed the backup key behind an HSM-based vault with password-controlled retrieval. Passkeys now replace that password step with a FIDO credential ceremony, keeping the “WhatsApp can’t read your backup” property while removing user-memorable secrets from the flow (Meta Engineering; BleepingComputer).

Takeaways

• Update acquisition SOPs: plan for live, unlocked device presence to satisfy passkey prompts during any WhatsApp backup restore.
• Default to on-device extractions where possible (iOS ChatStorage.sqlite in the WhatsApp app group; Android msgstore/wa.db and media paths) to avoid cloud-restore gates.
• Refresh templates and warrants to request device passkey factors for the Apple/Google account that owns the WhatsApp backup, not just a backup password.
• Expect fewer remote password-based restore abuses; focus monitoring on device loss/theft and new device enrollments in Apple/Google passkey ecosystems.