What to Do When a Companion App Account Is Taken Over or Impersonated

Describe the incident without spreading it

Write observable facts first: which profile field changed, which message was not yours, which device or time you cannot explain, and whether you still have access. Do not forward suspicious material to a large group or ask the person using the account to prove anything. Multiple sessions on one physical device can be normal, so combine device name, browser, time, broad location, and your own recent use. A changed password, recovery address, phone number, or verification method is a stronger reason to start the loss-of-control workflow.

Create a minimal evidence card with the first discovery time, last known normal access, visible unfamiliar session labels, altered fields, actions you took through official pages, and support case numbers. Crop screenshots so they exclude unrelated contacts, private message text, backup codes, and payment details. The card helps official support understand the state and helps you avoid repeating steps. It is not a public accusation and does not establish who operated the account.

While signed in, secure the recovery chain first

Identify what can reset the companion account: an email mailbox, phone number, or federated identity provider. If that upstream account also shows unfamiliar activity, secure it before relying on an app-password change. Set a distinct password, review its recovery email and phone, sign out unknown sessions, remove forwarding rules or connections you did not create, and configure an available additional verification method. Google’s compromised-account guidance separates security events, devices, recovery details, and connected access; checking these prevents an attacker from simply resetting the app again through the upstream route.

Return to the companion app and replace a password only when it was exposed, reused, or changed without permission. Review every session and device. Sign out entries you cannot explain or no longer need; if identical names cannot be distinguished, sign out all of them and rebuild access on trusted devices. Look for newly added sign-in methods, linked identities, tokens, public share links, or notification changes. Reject any verification prompt that you did not initiate, even if it arrives during cleanup.

When locked out, stay inside the official recovery path

Do not use a “support” account sent by a stranger, an unverified number in a search advertisement, or a shortcut link in the suspicious message. Find recovery through the official app-store listing, website navigation, or a help center you already know. Where the provider recommends it, use a familiar device, browser, and network, and answer recovery questions accurately. Do not invent details you cannot remember. Never send a one-time code, recovery link, or backup code to another person.

Keep the official case number, submission time, and requested next action. Avoid repeated applications containing conflicting information. Do not post your email, telephone number, device identifiers, or identity documents in a public forum. If ownership evidence is required, submit the smallest required set through the provider’s explicit upload path. After access returns, pause ordinary use until you have evicted sessions, corrected recovery details, and established a distinct credential.

Repair impersonation separately from recovering access

Regaining login does not remove every change made through the account. Review avatar, display name, biography, public posts, contacts, sharing links, notification settings, connected email, and other visible fields. For content you did not create, use the app’s deletion, hiding, or reporting controls after recording the necessary time and case reference. Do not publish private conversations to demonstrate that an incident occurred. Access recovery and public-identity repair are two different completion states.

If the account contacted people while impersonated, notify only recipients who actually received those messages. A useful note is factual: “Between these times, this account sent content that was not from me. Do not use its links or provide a verification code. I am handling the account through the official service; use our previously known contact route if confirmation is needed.” Do not speculate about who operated it, ask recipients to republish screenshots, or broadcast the incident to an unaffected contact list.

Rebuild a bounded trusted state

Confirm that the new credential is distinct, the upstream mailbox is controlled, recovery contacts are current, the second factor and backup route work, unknown sessions are closed, and unfamiliar connections are removed. Review system updates, screen lock, browser extensions, and recent downloads on devices used during the incident. If suspicious software or remote control was installed, stop performing sensitive account actions there and use the device maker’s current support path or another trusted device.

Set a limited follow-up window. After completing the response, review security events and public fields once more the next day or at another defined time. If nothing new appears, end the incident workflow instead of checking continuously. Keep a non-secret summary with completion times for discovery, recovery, eviction, repair, notification, and follow-up. This containment ladder shows which step needs provider assistance and which action you can verify yourself.

Keep exploring this topic