An underrated cybersecurity risk is not a new exploit. It is silent persistence: access that stays alive after you change a password. Sessions, forwarding rules, recovery channels, and connected apps can all keep working, and attackers bet that you will never look there.
Rule of thumb: if you only changed a password, assume access can persist until you audit sessions and recovery controls.
Fast triage: end silent persistence
- Secure the control plane (email) first. Turn on strong authentication, review recent sign-ins, and remove unknown forwarding and delegates.
- Invalidate access. Sign out of all devices on your major accounts and revoke connected apps you do not actively use.
- Lock recovery back to you. Replace recovery email and phone with channels you control, regenerate backup codes, and remove old ones.
- Check for persistence on your devices. If a device is untrusted, clean it before you log back in or you will re-seed sessions and tokens.
- Raise the cost of re-entry. Add device alerts, login alerts, and recovery-change alerts on accounts that support them.
If you are not sure whether you are dealing with active compromise or just suspicious noise, start with how to check if you have been hacked. If you suspect your device is part of the problem, use how to detect spyware before you trust it with account recovery.
Why password changes do not reliably end access
Most modern services separate “proving you know the password” from “proving you are still the same session.” That distinction is why persistence happens.
- Session tokens: after a successful login, the service issues a token (often stored in a browser cookie or app storage). The token can remain valid for days or weeks, even if the password changes.
- Refresh tokens and “remembered devices”: some apps can silently re-authenticate without prompting you again.
- Connected apps: third-party app authorizations can create long-lived access that bypasses the password you just changed.
- Recovery controls: if an attacker controls your recovery email, recovery phone, or backup codes, they can regain the account whenever they want, even after you reset it.
OWASP’s session management guidance is written for developers, but it explains the core risk clearly: sessions and cookies are their own access layer, and invalidation is not always intuitive. See OWASP Session Management Cheat Sheet for the defensive concepts.
Key idea: account control is decided by recovery channels and session visibility, not by password strength.
High-risk accounts to audit first
Not all accounts matter equally. Start with the ones that control other accounts or money.
| Account | Why it is high leverage | What to verify |
|---|---|---|
| Resets and alerts for everything else | Sessions, forwarding, delegates, recovery channels | |
| Password manager | Unlocks all other credentials | Master password change from clean device, 2FA, device list |
| Domain registrar / DNS | Controls websites and business email routing | Account recovery, admin roles, MFA, recent changes |
| Banking and payments | Direct financial loss and fraud | New payees, alerts, device list, linked email changes |
| Cloud storage | Data exposure and extortion | Shared links, connected apps, session list |
This ordering matters because it reduces cascade. If you start by changing a social media password while your email is still being forwarded to an attacker, you will spend hours “fixing” accounts that can be re-taken in minutes.
Persistence surfaces that matter most
| Surface | What it looks like | What to do | Common mistake |
|---|---|---|---|
| Active sessions | You are “logged in” on devices you do not recognize | Sign out everywhere, then re-login on trusted devices only | Signing out of one device and assuming the rest are fine |
| Mailbox forwarding and rules | Resets and alerts get copied or diverted | Remove unknown forwarding, filters, delegates, and “send as” settings | Only checking the inbox and ignoring settings |
| Recovery email and phone | Recovery prompts go to a channel you do not control | Replace recovery channels, regenerate backup codes, remove old devices | Leaving an old phone number attached “just in case” |
| Connected apps | Third-party access persists without re-login | Revoke apps you do not actively use, especially broad scopes | Keeping old apps because “I might need it later” |
| Browser extensions | Redirects, injected ads, or odd login prompts | Remove unknown extensions, reset browser settings, scan the device | Resetting passwords while the browser stays compromised |
How attackers use forwarding and rules in practice
Forwarding and mailbox rules are popular because they are quiet. A typical setup is simple: forward all mail (or only security-related mail) to an external address, mark it as read, and sometimes delete it. That gives an attacker a shadow copy of resets, one-time links, and account alerts while keeping your inbox looking normal.
Red flags worth treating as strong signals:
- Rules that match “security,” “password,” “verify,” “invoice,” “bank,” “wire,” or “payment.”
- Rules that auto-delete or auto-archive messages from a service you rely on.
- Delegated access you did not intentionally grant.
- Auto-replies that leak details about your organization, travel, or availability.
Even if you do not find a malicious rule, the audit is still valuable. It forces you to look at the settings that decide whether you see alerts at all.
Start with the control plane: email
Email is the most common recovery hub for everything else. If an attacker can read your email, they can see reset links, intercept security alerts, and impersonate you in vendor or personal conversations.
Work in this sequence:
- Authentication: enable strong multi-factor authentication on email. Prefer authenticator apps or security keys over SMS when you have a choice. CISA maintains practical guidance for multi-factor authentication at Multi-Factor Authentication (MFA).
- Sessions: sign out of all devices and review the device list for anything unfamiliar.
- Rules and forwarding: look for forwarding addresses, inbox rules, filters, auto-replies, delegates, and any setting that sends copies of mail elsewhere or marks security alerts as “read.”
- Recovery: verify the recovery email and phone are yours, and regenerate backup codes if the service supports them.
Enable alerts for new sign-ins and recovery changes. Alerts matter only when you are willing to treat them as signal: if the service can notify you, you can respond fast instead of weeks later.
Recovery channels are the quiet takeover path
Recovery settings are designed for your worst day, which makes them attractive to attackers. The common failure mode is leaving a recovery phone number from an old SIM, a shared family plan, or a number that can be ported without you noticing.
Practical guardrails:
- Keep recovery channels minimal. Two good channels you fully control is safer than five channels you barely remember.
- Regenerate and store backup codes. Treat backup codes like keys. If you suspect exposure, regenerate them and remove old copies from notes apps or email drafts.
- Watch for carrier risk. If you receive carrier alerts about a port-out, or your phone suddenly loses service, treat it as a security incident and contact your carrier immediately.
Common mistake: leaving recovery in a “future me will fix it” state. Recovery controls are a primary access path, not a nice-to-have.
Connected apps and long-lived authorization
“Connected apps” and “authorized applications” are often forgotten because they keep working quietly. Some have powerful scopes, like reading email, managing calendars, or accessing files. Removing a connected app does not just reduce risk. It reduces how many places you must investigate during an incident.
Audit connected apps with a bias toward removal:
- Revoke anything you do not recognize.
- Revoke anything you no longer use weekly.
- Revoke anything that has broad access (mail, storage, admin) unless it is essential.
Then sign out of all sessions again. Some ecosystems issue new tokens when an app is authorized, and you want to ensure you are not leaving fresh tokens behind.
Device trust and re-seeding access
Persistence is not only in accounts. A compromised device can continuously leak passwords, cookies, and one-time codes. If you clean accounts but keep using the compromised device, you can immediately re-create sessions and lose control again.
Signals that should make you treat the device as untrusted:
- New browser extensions appeared.
- Security prompts repeat even after you sign out everywhere.
- You see unexpected redirects or login pages that look slightly off.
- Unrecognized apps have deep accessibility or device management permissions.
If those signals exist, clean the device first, or use a different, known-clean device to do recovery. Treat cleanup as a decision: clean, reset, or isolate. Half-cleaning is how persistence becomes chronic.
Make the fix durable
Persistence is a symptom of sprawl: too many sessions, too many recovery paths, too many apps with privileges. The durable fix is narrowing the system until it becomes inspectable.
A stable state looks like this:
- You can list your recovery channels from memory, and each one is controlled by you.
- You can see and invalidate sessions quickly.
- Your connected apps list is short and unsurprising.
- You get alerts for the actions that matter: new sign-ins, new devices, recovery changes.
If you want a broader baseline that covers password reuse, phishing, and device hygiene, use protect yourself from hackers and cybercriminals. Silent persistence is less about clever attackers and more about forgotten defaults. When access is visible and recovery is tightly owned, most “mysterious” compromises turn into an ordinary maintenance problem.
That shift is the real goal: fewer unknowns, fewer places for access to hide, and a recovery path that does not depend on luck or speed.
When you can invalidate access on demand and prove that recovery routes are yours, you stop playing whack-a-mole and start operating from control.