13 November 2026

How Hackers Keep Access to Your Email After a Password Change

Photo by Vitaly Gariev on Pexels

Someone on your team clicks a convincing link, types their Microsoft 365 password into a fake login page, and an hour later a client rings to ask about the odd email they just received. The obvious fix is to change the password, and it should be changed straight away.

The trouble is that a password is only the front door. While the attacker was inside, they had time to prop open a few windows, and a new password does nothing to close them. For a business mailbox, that matters more than for almost any other account: password resets for your accounting software, banking portals, cloud storage and supplier accounts all land in the inbox, so whoever can still read it can often get into everything else.

This post walks through the five ways an attacker can stay connected after a password change, then the order to deal with them in. Most of these settings only show up in the admin tools for Microsoft 365 or Google Workspace, which is why this is a job for your IT provider or administrator rather than the person whose account it is.

Five ways back in that survive a new password

1. A session that's still signed in

When you sign in to Outlook, Gmail or the mobile mail app, the service hands your device a token or cookie so you don't have to log in every time you open a message. That token stays valid until it expires or someone revokes it, and the attacker's browser has one too.

How much a password change clears up depends on the provider. Google says a password change signs you out almost everywhere, but lists exceptions: devices you use to confirm it's you, some devices with third-party apps you've given access to, and smart home devices. Microsoft's guidance for business accounts treats revoking sessions as its own step, separate from the password reset.

Session cookies can also be stolen outright by malware on a work computer and replayed from somewhere else, which skips the login (and the password) entirely. If there's any chance a machine is infected, start the recovery from a different, known-clean device and have the suspect one checked before anyone signs in on it again.

The same principle applies to a lost or stolen phone that's still signed in to company email. This is where having phones set up as managed business devices earns its keep: a missing handset can be wiped remotely rather than left holding a live session nobody can reach.

2. Forwarding and inbox rules

This is the classic one. An attacker sets up forwarding so a copy of every incoming email goes to an address they control, or, more quietly, a rule that only forwards messages mentioning words like "invoice", "payment", "remittance" or "password reset". Everything else arrives as normal, so nobody notices.

Rules can hide things as well as leak them. A rule that moves replies from a particular client, or security alerts from Microsoft, into an obscure folder (or straight to Deleted Items) gives the attacker room to run a fake invoice conversation without the real mailbox owner ever seeing the replies.

Microsoft specifically tells administrators to review all inbox rules, including hidden ones, which won't show up if you only look in the user's Outlook settings. External forwarding is also something worth locking down in advance, and it's one of the settings we cover in 5 Microsoft 365 settings worth a second look.

3. A connected app with permission to read the mailbox

Plenty of legitimate tools connect to a mailbox: scheduling apps, CRMs, e-signature services, browser add-ons. They usually do it through OAuth, where you click "Accept" on a permissions screen and the app gets its own access, without ever knowing your password.

That's exactly why attackers like it. A malicious app with a believable name and logo asks for permission to read mail, and once approved, it keeps working after the password changes, because it never relied on the password in the first place. Microsoft warns that a harmful consent grant can give access to email, files, contacts and forwarding rules.

Since mid-2025 Microsoft has tightened its defaults so that staff can no longer approve apps asking for high-risk permissions on their own, but apps approved before that change kept their access. Check every connected app, confirm who actually publishes it and what it can do, and remove anything the business doesn't recognise or use.

4. Someone else's access to the mailbox

Business email lets one person work in another's mailbox: an assistant managing a director's inbox, or a team sharing an accounts mailbox. In Microsoft 365 this comes as three separate permissions. Full Access lets someone open and read the mailbox, Send As lets them send email that appears to come straight from it, and Send on Behalf shows both names. Gmail has its own delegation feature that works in a similar way.

A delegate signs in with their own account, so the mailbox owner's new password doesn't touch them. An attacker who has control of one account can grant it access to another, then keep reading or sending from the second mailbox long after the first is cleaned up. Every delegate should have a reason the business can explain. If nobody can, remove it.

5. A recovery method or sign-in method they added

While in control of the account, an attacker can add their own phone number, recovery email address, authenticator app, passkey or security key. Any of these can be used later to reset the password again or approve a fresh sign-in.

Microsoft's guidance is to review the MFA methods registered on the account and remove anything suspicious. Google gives the same advice for recovery details and devices. Go through each entry with the account owner and delete whatever neither they nor the administrator recognises.

The order to deal with it in

Working through these in a sensible order stops the attacker undoing your work while you're halfway through.

Lock the account first

Microsoft recommends disabling the affected account while it's investigated, and Google Workspace administrators can suspend the user, which also resets their sign-in cookies and OAuth tokens. Then revoke active sessions so anyone already signed in is pushed out. The person whose account it is will be without email for a short while, which is far better than leaving it open to someone reading, sending and deleting in the meantime.

Set a new password, properly

Pick a password that hasn't been used anywhere else, and change it on any other account that shared the old one. Don't email the new password to the affected mailbox, since the attacker may still be reading it. Phone it through or share it through your password manager instead.

One easy miss: older apps sometimes use separate "app passwords". Microsoft notes these aren't revoked automatically when the main password is reset, so they need deleting and recreating if any exist.

Go through every setting, not just the obvious ones

Check forwarding addresses, inbox rules (hidden ones included), filters, blocked senders, delegates and sending permissions, connected apps, signatures and automatic replies. Then the sign-in side: registered devices, phone numbers, recovery addresses, authenticator apps, passkeys and security keys. Look at whether POP or IMAP access is switched on, too, but confirm with the user how they actually work before turning it off, as some older setups still rely on it.

Only then hand the account back

When everything unexpected has been removed, re-enable the account and make sure MFA is required before the user signs in. Where your platform supports passkeys or physical security keys, use them: they can't be typed into a fake login page the way a six-digit code can, which is why the NCSC now recommends passkeys wherever a service supports them. We've covered how they work in more detail in our post on whether your business should use passkeys.

Work out what the attacker actually did

Closing the doors is half the job. The other half is finding out what happened while they were inside.

Look through Sent Items, Deleted Items, Drafts, Junk and Archive for messages the user didn't write, replies they never saw, password reset emails for other services, and anything that changes bank details or payment instructions. Your administrator should also review the sign-in logs, audit logs, message traces and any security alerts, starting the search from before the first sign of trouble, since the original break-in may well have happened days or weeks earlier.

Treat location data with some caution. A sign-in from an unfamiliar town or country isn't proof on its own, as mobile networks and VPNs regularly put people in the wrong place. The device, time, IP address and what happened straight after the sign-in, taken together, tell you far more.

Tell the people who need to know

If the account sent fraudulent emails, contact the recipients by phone or another channel you already trust, not by replying to the thread. Tell them which messages weren't genuine and what to do about them, whether that's ignoring a payment request, deleting an attachment or changing a password of their own. Pay particular attention to anything mentioning bank details, invoices, payroll or gift cards.

If money has gone to the wrong account, ring your bank straight away using the number from its website or the back of your card, never one from the email chain. Report it to Report Fraud, the UK's national fraud and cybercrime reporting service. It's also worth checking your policy: some cyber insurance includes cyber crime cover for fraudulent transfers and scams that trick staff into moving money.

If personal data may have been exposed, such as client details sitting in the mailbox, UK GDPR may require you to report it to the ICO within 72 hours of becoming aware of it. Our guide on what to do in a cyberattack, step by step covers reporting and the wider response in more detail.

Making it harder next time

A few settings make every one of the tricks above harder to pull off:

• Block automatic forwarding to outside addresses unless there's a specific business reason to allow it.
• Limit which third-party apps staff can connect to their accounts. Both Microsoft 365 and Google Workspace have controls for this.
• Require MFA on every account, starting with administrators and anyone who handles payments or sensitive client information, and move to passkeys or security keys where you can.
• Make it easy to report something odd. An unexpected MFA prompt, a login alert from somewhere unfamiliar, a rule nobody remembers creating, or a client asking about an email you didn't send are all worth a call to your IT provider the same day, not next week.