FBI warns of phishing for Signal backup recovery keys

Signal's device-transfer and backup system relies on a recovery key that, if handed over, gives an attacker full access to a user's message history without ever touching Signal's own servers. The FBI is warning that phishing campaigns are now specifically targeting that key rather than trying to breach Signal directly.

Younes Bekrar7 min read
ShareXLinkedInFacebook
FBI warns of phishing campaigns targeting Signal backup recovery keys

The FBI is warning about phishing campaigns aimed at Signal's backup and device-transfer recovery key, a 64-digit code the app generates so you can restore an encrypted backup onto a new phone. Signal's encryption is strong enough that the company can't read your messages even under legal compulsion. That same design makes the recovery key the credential everything else hangs on. Someone who has it can decrypt and restore the backup on hardware they control. Signal's servers never see the key or the plaintext, so a phishing restore and a real device transfer look identical from the backend. I've covered plenty of "encrypted messenger" advisories that boiled down to a server bug. This one is almost the opposite story.

A backup Signal can't open

Message history is encrypted on the device before it leaves. The recovery code derives the key that unlocks that blob. Signal stores ciphertext and nothing that would let it reset or recreate the secret. Compared with a normal cloud backup a provider could technically inspect, that's the privacy win. The bill comes due when something goes wrong: no password-reset email, no support ticket that magically reopens the archive, no remote revoke the way you'd rotate a leaked password.

Attackers have noticed. Breaking into Signal's infrastructure to read messages is a dead end even in a hypothetical full server compromise. Stealing one long number from a hurried user is not. The FBI advisory is about that pivot, not about a crack in the cryptography.

If you've ever restored Signal onto a new handset, you already know the ritual feels solemn on purpose, long code, careful typing, no casual "email me a link" path. That solemnity is also what attackers borrow. A flow that only happens at stressful moments (broken phone, sudden upgrade) is a flow people complete while distracted.

I keep a paper copy of mine in a drawer I almost never open, which is annoying right up until the week I need it. Annoying storage is the point. Convenience is how long secrets migrate into the same cloud account that already has your photos and passwords. The FBI advisory is essentially yelling that exact sentence through a megaphone at anyone still treating the code like a temporary note.

What the campaigns look like

The shape is ordinary credential theft wearing Signal's clothes. A message pretending to be Signal support, a fake device-linking prompt, or a security-alert push sends people toward a page or chat flow that asks for the recovery code to "verify" the account or "restore" a session. Users already type that long numeric string during real transfers, which is why a polished fake lands. Urgency helps. People paste first and doubt later.

With the code, the attacker restores the backup onto their own device and gets message history up to that backup point. No SIM swap. No access to the victim's phone. No need to touch the Signal account the way account-recovery abuse works on platforms that still do SMS resets. Detection sits with the user, because the backend has no separate signal that the restore was hostile.

Store the code in a password manager or on paper somewhere boring and offline. A screenshot on the same phone, or a note synced into a weaker cloud account, turns one compromised device into two problems. I've seen people keep the code in the same Photos album as everything else. That habit is quiet until the phone backup account gets hit too.

Signal's own UI already says the recovery code is only entered during a transfer you start inside the app. Treat unsolicited links and "support" chats that want the code as hostile by default. Start transfers yourself, from the app, when you meant to, not when a notification told you to hurry.

The 64-digit length is supposed to make casual guessing impossible. It does nothing against a paste into the wrong field. Length isn't the defense once the user has been talked into cooperating.

This is the design working, which is the uncomfortable part

The advisory is not evidence Signal was breached, and it is not a claim the encryption failed. The attack angle exists because the zero-knowledge backup does what it says on the tin. After a successful theft of the code, Signal cannot reconstruct what happened from server logs in a way that separates good restores from bad ones, and it cannot remotely burn a stolen key. That is the price of a vendor that also cannot read your backups under a court order.

Security teams sometimes flatten every advisory into "vendor got owned." Misreading this one that way sends people hunting for a patch that does not exist. The weak step is human handling of a credential with no safety net.

There's a communications problem here too. "Signal warns users" headlines can sound like a product failure to people who skim. The FBI note is closer to a reminder about how the product's threat model always worked. The cryptography held. The social layer is where the campaign lives.

If you run security awareness training, this is a better tabletop than another generic "check the URL" slide. Walk people through the real restore screens once so a fake feels wrong in their hands, not only wrong in a screenshot.

Same bargain other zero-knowledge apps make

Password managers and some encrypted cloud tools make the same trade: real privacy, thin recovery if the user's secret walks out. As more consumer apps default to end-to-end backups, expect more advisories that sound like this one. Breaking the math stays unrealistic. Asking a distracted person for a 64-digit string in the wrong window stays cheap.

Enterprise security programs that bless Signal for staff chat sometimes still treat backup keys like optional homework. They aren't. If your threat model includes targeted attacks against journalists, activists, or executives, the recovery code belongs in the same training bucket as seed phrases and hardware-key PINs, not in a footnote under "also encrypt your phone."

Cryptography strength and system strength are different measurements, and the second one still runs through whoever is holding the code. The FBI can warn. Signal can label the field carefully. Neither can sit between a hurried user and a convincing fake on a bad afternoon.

I don't read this as a reason to abandon Signal or to demand a magic remote kill switch that would also give Signal a path into backups. I read it as a reminder that the recovery code is the backup. Treat it like one.

If someone in your life uses Signal because they care about private history, forward them the FBI note and then help them move the code out of Photos. That is less exciting than arguing about cryptography on the internet. It is also closer to the actual failure mode the advisory describes.

  • Zero Trust
  • Privacy

Keep reading

Security

A week of AI agent eval breaches, two failure modes

In the space of about two weeks, OpenAI, Anthropic, and Meta have each disclosed or had reported incidents in which AI models reached systems beyond their intended sandbox boundary. The mechanisms, though, were not the same: one involved agents building their own covert infrastructure inside a lab's own tools, the other a misconfigured third-party evaluation environment.

Younes Bekrar8 min read