Secure messaging can protect communications in transit while an attacker still gains access through a stolen recovery key or an unauthorised linked device. Encryption and account control are different parts of the system. If someone persuades you to reveal the credential that restores your history, the protection around that history may no longer help.
The FBI and CISA’s 26 June 2026 advisory describes that kind of attack against commercial messaging accounts. The useful response is practical: recognise requests for recovery material, inspect linked devices and prepare a recovery process that does not depend on instructions from an incoming chat.
Understand what the advisory says was compromised
The June advisory attributes a continuing campaign to Russian intelligence-linked actors targeting people of high intelligence value, including officials, military personnel and journalists.
It says the actors compromised individual messaging accounts rather than breaking the applications’ encryption or the applications themselves. That distinction matters. An account-access attack can expose messages without demonstrating a failure of the underlying encryption design.
The advisory updates an earlier March warning and describes attempts to obtain backup recovery keys, verification codes and account PINs. It includes examples of messages posing as support or security notices.
Do not assume that every ordinary user is part of that specific campaign. The defensive lesson is broader: the same kinds of account secrets should not be handed to someone merely because a message claims to protect the account.
Keep the different secrets separate
A verification code may help register or access an account. An account PIN can serve another protection function. A backup recovery key can unlock stored message history. The exact roles depend on the application.
Treat each according to the provider’s official documentation. Do not assume that changing one necessarily invalidates the others. A password reset may not revoke every linked device or replace a backup key.
Write down the categories of access your chosen application supports: primary device, linked devices, account registration, backup and recovery. This map helps you identify what to review after a suspicious event.
Avoid storing the actual secrets in that map. It is a description of the system and the location of protected recovery material, not a new unprotected credential file.
Recognise the support-message pattern
The June advisory describes messages that claim urgent action is needed to avoid losing data or to complete a security update. The user is then directed to reveal recovery material or perform steps that benefit the attacker.
The pressure is part of the mechanism. A deadline, an official-looking name or a reference to a real security concern can make the request seem plausible.
Open the application’s settings or official support information through a route you choose independently. Do not let the incoming message supply both the problem and the only supposed solution.
If the request asks you to paste a recovery key, verification code or PIN into a chat, stop. A person claiming to be support should not gain access to your account secrets simply because they know the application’s name.
Inspect linked devices as a separate task
Many messaging applications allow additional devices to access the account. An unauthorised link can therefore matter even if the primary phone remains in your possession.
Review the application’s linked-device list through its normal settings. Identify the devices you recognise and investigate unfamiliar entries. Use the provider’s supported process to remove access where appropriate.
Do not rely only on the device label. Names can be generic or confusing. Consider when the device was linked and whether the activity fits your own use, using the information the application provides.
For a business account, keep a record of legitimate shared or desktop access. Staff changes and replaced computers can leave old links in place even without a malicious actor.
A leaked backup key needs its own response
The FBI advisory highlights a particularly important recovery issue: in the described scenario, a compromised backup recovery key can remain valid even after a new account is created using the same phone number.
It says generating a new backup recovery key invalidates the old key for future backup downloads. It also cautions that this cannot undo a backup the attacker has already downloaded.
That is a concrete reason to avoid treating account recreation as a complete cleanup. The response must address the specific credential that was exposed.
Follow the official instructions for the affected application, because backup designs differ. The article’s point is the distinction between future access and information already obtained, not a universal menu sequence for every messenger.
Work through a suspected disclosure
Imagine a consultant receives a message claiming that a backup needs to be reconnected. The consultant follows part of the instruction and then realises that a recovery key may have been pasted into the chat.
The first step is to stop interacting with the supposed support account and use a trusted route to the application’s security settings and guidance. The consultant should identify exactly what was disclosed: a verification code, PIN, recovery key or another credential.
Next, secure the affected access routes through the provider’s supported process. That may involve replacing the exposed recovery material, reviewing linked devices and checking account registration or sessions.
The consultant should also assess what information the exposed credential could unlock. If business or client messages may have been accessed, the response needs to consider those affected parties and any applicable obligations, rather than assuming the problem ends when login works again.
This is an illustrative incident scenario, not a report about a particular consultant.
Keep a trusted way to warn contacts
An attacker with account access may impersonate the owner. Colleagues and clients need a way to verify unusual requests without relying solely on the possibly compromised account.
For important relationships, establish a second trusted contact route in advance. If a messaging account sends a request for money, credentials or a sudden change of instructions, use that route to confirm it.
A warning should be factual: which account may be affected, the relevant period if known and which kinds of request should be treated cautiously. Avoid speculating about the attacker’s identity without evidence.
Do not send sensitive incident details into a channel that may still be accessible to the attacker. The communication plan should follow the same account-control analysis as the technical response.
Preserve useful evidence without spreading secrets
Keep the suspicious message, sender details, relevant timestamps and a record of actions taken. Where possible, preserve evidence in a controlled incident folder or through the organisation’s established process.
Do not include the actual recovery key in a broadly shared incident report. Describe the type of secret exposed and keep any necessary sensitive evidence restricted.
The evidence should help determine what happened and support reporting through appropriate channels. It should not become another copy of the information the attacker sought.
Distinguish confirmed access from possible access. A disclosed key can create a serious risk, but the available evidence may not show exactly which messages were obtained. State that uncertainty accurately.
Prepare a small account-recovery plan
For each important messaging account, identify the owner, legitimate linked devices, backup arrangement, official support route and location of protected recovery material. For a business, identify who can coordinate a response if the owner is unavailable.
Test that the official guidance can be reached without relying on the affected chat. Keep the plan outside the account whose loss it addresses.
Review the arrangement after replacing a phone, changing numbers, moving to a different backup provider or changing staff responsibilities. Recovery plans become stale through ordinary changes.
Our passkey recovery guide uses the same principle for other accounts: the recovery route must survive the failure of the primary device or login method.
Keep encryption, device security and payment approval separate
A secure messenger can be an appropriate communication tool while still being an unsuitable place to approve a payment without other checks. A message from a familiar account is not proof that the owner currently controls it.
For financial instructions, use the agreed business approval process and independently verify changes. The invoice-fraud guide explains why authentication and payment judgement are separate.
Keep devices updated and use the application’s security features, but avoid treating any single feature as complete protection. Account recovery, endpoint security, linked devices and human verification work together.
The useful result is a messaging setup whose access paths you understand. Encryption protects a defined part of the system; careful control of the keys, devices and recovery process protects the routes around it.
Review what belongs in a long-lived chat history
Recovery planning is easier when the account does not contain unnecessary copies of sensitive material. Review whether identity documents, payment credentials or confidential files are being left in chat simply because it was convenient to send them there.
Use the organisation’s appropriate records system for material that needs controlled access and retention. A message can point to that record without becoming another permanent copy of it. The correct approach depends on the business and its obligations; deleting messages indiscriminately can also destroy records that should be retained.
Where a messaging application offers disappearing messages or backup controls, understand what those settings actually cover. They may not remove copies already saved by a recipient, screenshots or material exported elsewhere. Do not promise confidentiality based solely on a timer.
For a small team, agree which information may be shared in chat and how consequential instructions are confirmed. That reduces the impact of an account compromise and makes suspicious requests easier to recognise, because they depart from an established working practice.
After recovery, check whether messages or instructions were sent while the account was outside your control. A restored login does not explain what contacts may already have received. Use a trusted channel to correct any consequential false instruction you can identify.
Questions
Does an account takeover mean the messenger’s encryption was broken?
Not necessarily. The June 2026 advisory explicitly distinguishes compromised accounts from a compromise of the applications’ encryption.
Should I send a recovery key to an account claiming to be support?
No. Use the application’s official support and settings through an independently chosen route, and keep recovery secrets private.
Is creating a new account enough after a backup-key leak?
Not necessarily. The advisory describes a key that can remain valid when the same phone number is reused, so the exposed recovery credential must be addressed.
Can replacing a key erase messages an attacker already downloaded?
No. Revoking future access cannot retrieve information already copied. Assess the potential exposure separately.
