A new wave of phishing is going after Signal users by impersonating Signal Support and asking for the one piece of data that makes the app’s encryption irrelevant: the backup recovery key. Hand that over, and an attacker doesn’t need to break the protocol. They just restore your message archive on a device they control and read everything you’ve ever sent. This is what modern cybersecurity actually looks like in 2026. Attackers have stopped trying to beat the cryptography. They beat the recovery flow instead.

It’s the same lesson the California Attorney General is currently teaching 23andMe in court. The state filed suit this week over the 2023 breach that exposed sensitive genetic and health data the company kept on long after its customers stopped actively using it. Different victims, different verticals, identical pattern. The persistent copy of your data is worth more than the live one, and almost nobody guards it that way.

The recovery key is the actual credential

Signal’s threat model puts an enormous amount of weight on the user holding a 64-character recovery key. The app is end-to-end encrypted, so the key is what binds your archive to you, and only you. Lose it and you lose your history. Share it and somebody else owns your history.

That’s exactly what the new phishing pages are designed to extract. Victims are contacted via fake “Signal Support” channels, walked through a story about account verification, and asked to paste the recovery key into a web form. The form does exactly what you’d expect. The attacker spins up a new install, restores the encrypted backup, and from that moment forward your years of messages are theirs to scroll.

The Signal-specific part is a footnote. The structural part is what should worry anyone running a security program. Almost every consumer and enterprise app that handles sensitive data now has a “recovery” path that bypasses the primary credential. Backup codes, key escrow phrases, account recovery emails, support-driven password resets. Each one is a side door, and each one is easier to phish than the front door it protects.

Why backup archives have become a cybersecurity blind spot

Look at the 23andMe lawsuit and you see the same problem expressed in legal language. California’s complaint focuses on the company’s failure to protect a category of data that, by its nature, never stops being sensitive. Your genome doesn’t expire. Neither does your messaging history, your tax records, or the backup of your password manager from three jobs ago.

The most dangerous data your company holds is the data nobody is actively using.

Active systems have monitoring, rate limits, MFA, brute-force lockouts, anomaly alerts. Backup archives have a recovery flow and a hope. That asymmetry shows up in incident after incident. Trump Mobile’s customer data exposure this week, the long tail of credential-stuffing attacks against dormant accounts, the Signal phish, the 23andMe records sitting in a database long after the kit shipped. The threat detection conversation has shifted toward identity and east-west traffic, and meanwhile the recovery surface keeps quietly growing.

The other reason archives are an easier target: they often live with the user. Signal backups, password manager exports, cloud drive copies. There’s no firewall in front of them, no SOC watching, no incident response team to call when the recovery key gets pasted into the wrong form. Defense in depth ends at the device, and from there it’s just the user and their willingness to trust a support page.

What to fix before your users get the call

The fix is a small set of decisions about how your organization treats recovery materials and how you tell people to handle them. Most of this is free. None of it requires a vendor.

• Inventory your recovery surface. For every system that holds sensitive data, write down the recovery path. Backup phrases, escrow keys, support-driven resets, fallback emails. If you can’t name them, you can’t defend them.
• Treat recovery keys like Tier 0 secrets. They belong in hardware tokens, sealed envelopes in a safe, or a privileged vault with break-glass logging. They do not belong in a Notes app, a screenshot, or an email draft.
• Make out-of-band verification the default for “support” contact. Train people to assume any inbound message claiming to be support is hostile until they call back through a number they already had. Signal will never DM you for your key. Neither will your bank, your IdP, or your IT team.
• Shorten the lifetime of every archive you can. If you don’t need three years of message history, don’t keep three years of message history. Data minimization is the cheapest form of security hardening you will ever buy.
• Add detection for first-use recovery events. Any system where a backup is restored to a new device should generate a high-priority alert with a verification step before the restore completes. This is your last chance to catch an attacker who already has the key.
• Rehearse a “recovery key compromised” playbook. What does your incident response team do when a senior employee admits they pasted a recovery phrase into a phishing page? If the answer is “nobody has thought about that,” fix it before the call comes in.

None of this requires a new product category. It requires accepting that the recovery flow is now the primary attack surface for a growing class of services, and that brute-force protections on the live system don’t help if the backup is sitting unguarded behind a 64-character string somebody can be tricked into typing.

The Signal phish is going to work. Some percentage of users will paste the key. The question your team should be answering this week is whether the same thing could work against your own users, your own customers, or your own archives. Don’t wait for a regulator to ask first.

Sources

• Signal users targeted in backup-stealing phishing attacks (Malwarebytes)
• California AG sues 23andMe over 2023 breach exposing health data (BleepingComputer)
• In Other News: Trump Mobile Data Breach, FIFA World Cup Phishing, CISA Responds to Supply Chain Attacks (SecurityWeek)