Your Encrypted Messages may not be as Private as You Think — And the FBI Just Proved It

Signal’s encryption wasn’t broken. But the FBI read the messages anyway. Here’s what actually happened — and the two-minute fix that would have prevented it.

The case seemed routine at first. A group of people accused of vandalizing and attacking an ICE detention facility in Alvarado, Texas on July 4, 2025. A federal trial in Fort Worth. Standard digital evidence.

Then, on March 10, 2026, FBI Special Agent Clark Wiethorn took the stand and described something that stopped the security community cold.

Investigators had recovered Signal messages from a defendant’s iPhone. Not because they hacked Signal. Not because they exploited some zero-day vulnerability. Signal’s end-to-end encryption was never touched. The messages were sitting in a completely different place — in Apple’s own internal notification database — and they had been there the whole time, even after Signal had been deleted from the phone.

How end-to-end encryption actually works — and where it stops

End-to-end encryption (E2EE) means that a message is scrambled on your device before it leaves, travels across the internet in unreadable form, and is only decrypted on the recipient’s device. Signal’s servers never see the content. Neither does anyone intercepting the connection.

This is real, and it works exactly as advertised. The problem is what happens next.

When a message arrives on your phone, Signal has to display a notification. To do that, it decrypts the message locally and passes the readable text to iOS — to Apple’s notification system — so it can appear on your lock screen. At that moment, iOS takes that decrypted text and writes it into its own internal notification database. A database that Signal has no control over. A database that doesn’t get deleted when you delete Signal. A database that can retain content for weeks.

Forensic investigators, using tools like Cellebrite, know exactly where that database lives. And with physical access to a seized device, they can pull everything from it — including the full text of messages from apps long since uninstalled.

That is precisely what happened in the Prairieland case. Defense attorney Harmony Schuerman described the mechanism in plain terms in her trial notes:

They were able to capture these chats because of the way she had notifications set up on her phone — anytime a notification pops up on the lock screen, Apple stores it in the internal memory of the device.

Only incoming messages were recovered, not outgoing ones. The notification database captures what arrives on your lock screen, nothing else.

This isn’t a Signal problem. It’s a layer problem.

Signal did not fail here. The encryption between sender and recipient worked perfectly. What failed was an assumption most users make without realizing it: that an encrypted app controls everything that happens to its messages on your device.

It doesn’t.

The operating system is a separate layer, and it has its own logic. Once a message clears the encrypted channel and lands on your phone, the OS can — and does — make its own copies for its own purposes. Notifications, caches, system logs. None of these are within the app’s reach.

The same vulnerability applies to WhatsApp, Telegram, iMessage, and any other app that shows message content in lock screen previews. The Prairieland case surfaced it in a Signal context, but the underlying mechanism is universal.

It’s also worth nothing what this attack requires: physical access to your unlocked device. This is not a remote exploit. It’s not surveillance over the network. It’s a forensic extraction that happens after a device has been seized. For most people, that narrows the threat significantly. For journalists, lawyers, activists, or anyone whose device could end up in the wrong hands — it’s a direct and documented risk.

The fix is two settings, not one

Here is where many guides get it wrong: disabling notification previews at the iOS system level alone is not sufficient. You need to act at both layers.

On iOS:

Go to Settings → Notifications → Signal → Show Previews → Never.

This prevents iOS from writing decrypted content into its notification database.

Inside Signal:

Go to Signal → Settings → Notifications → Notification Content → No Name or Content.

This prevents Signal from passing the decrypted message text to the iOS notification API in the first place.

Both steps are necessary. One without the other leaves a gap.

On Android, the situation is structurally similar but the system’s built-in notification history only retains data for 24 hours by default, and users can disable it entirely via Settings → Notifications → Notification History. The primary mitigation remains the same: inside Signal, set notification content to show nothing. No text reaches the OS layer if it’s never passed there.

Three things that do not fix this problem:

Disappearing messages won’t help — the notification preview is written to the database before Signal’s deletion timer ever runs. Deleting the Signal app won’t help — the OS database persists independently. Enabling iCloud Advanced Data Protection won’t help — that protects cloud backups from server-side access, which is an entirely different threat model.

What have we learnt?

Encryption protects the channel. It does not protect the device. The device can be always seized legally or with violence. You cannot trust data you have on it.

These are two separate threat models, and conflating them leads to a false sense of security. Signal is not broken. Using Signal is still significantly more private than using unencrypted alternatives. But privacy is a stack of choices, not a single switch. The app is one layer. The operating system is another. Physical device security is a third.

The Prairieland case is useful precisely because it makes this concrete. A real investigation. A real forensic technique. A real courtroom exhibit. And a real setting that, had it been configured differently, would have prevented the recovery entirely.

Two settings. That’s all it would have taken.

Want to see exactly how this works — with a full walkthrough of the technical mechanism and the step-by-step configuration for both iOS and Android? I covered everything in a dedicated video on my YouTube channel (in italian): youtube video

If you use servers or communications infrastructure for a business and want to think seriously about your security posture — including private hosting outside major cloud providers — take a look at Denali PRO. Swiss-based infrastructure provider, Lightning Network payments accepted.