Resetting the Password Isn’t Enough Anymore—The Hacker Is Already Inside Drinking Your Coffee

It is too early for life.

The sun has barely made an appearance, my brain is still loading its operating system, and I have not yet consumed enough coffee to legally qualify as a functioning adult.

Then the security alert arrives:

“Suspicious activity detected on a user account.”

Excellent.

Exactly what everyone wants before their first cup of coffee: an identity-security incident involving an employee, six cloud applications, three countries, and a sign-in from somewhere nobody can locate on a map without opening Google.

The traditional response has always been straightforward:

1. Reset the user’s password.
2. Tell them not to click suspicious links.
3. Close the ticket.
4. Return to the coffee pot.

Unfortunately, attackers have evolved.

They are not always stealing passwords anymore. Increasingly, they are stealing session cookies, authentication tokens, OAuth permissions, API keys, and other digital hall passes that tell applications:

“Everything is fine. This person already logged in.”

And when an attacker has one of those, changing the password may not immediately remove them.

That is the cybersecurity equivalent of changing the lock on your front door while the burglar is already sitting in your kitchen, eating your leftovers and criticizing your choice of coffee beans.

The Password Was Only the Front Door

For years, cybersecurity teams focused heavily on protecting the login screen.

We encouraged stronger passwords, deployed password managers, enabled multifactor authentication, configured conditional-access policies, and repeatedly asked Kevin from accounting to stop using Summer2026!.

Kevin eventually upgraded it to Summer2026!!, so clearly the awareness training worked.

The problem is that attackers have started targeting what happens after authentication.

When you successfully sign in, the service normally gives your browser or application a token. That token proves that you already completed the login process, allowing you to continue working without entering your password every twelve seconds.

That is convenient for users.

It is also convenient for attackers.

A stolen token may allow an attacker to impersonate the user without repeatedly supplying the password or responding to another MFA prompt. To the application, the activity may initially look like it is coming from a properly authenticated user.

The attacker did not break through the front door.

They photocopied the employee badge, walked past reception, and confidently carried a coffee mug so nobody questioned them.

Honestly, holding a coffee mug will get you into approximately 40% of office meetings without anyone asking why you are there.

That statistic is completely made up, but emotionally accurate.

Device-Code Phishing: Because Regular Phishing Wasn’t Annoying Enough

One technique receiving increased attention is device-code phishing.

Device-code authentication is a legitimate process designed for devices where entering a password is inconvenient—smart televisions, command-line tools, printers, IoT equipment, and other devices apparently designed by people who hate keyboards.

Normally, the device displays a code. The user visits a legitimate authentication page, enters the code, and approves access.

Attackers abuse this by generating a device code for their own session and convincing the victim to enter it.

The victim may receive a message claiming that they need to authenticate for a meeting, review a document, access a shared resource, or perform some other perfectly normal task that somehow always arrives before coffee.

The dangerous part is that the victim may be entering the code on a real Microsoft authentication page. The website is legitimate, the connection is encrypted, and MFA may even be completed successfully.

The user is simply authorizing the attacker’s session instead of their own.

Microsoft has documented active campaigns using device-code phishing to capture authentication tokens and access targeted accounts.

It is like receiving a legitimate key from the building manager and then personally handing it to the burglar.

At least the burglar did not have to pick the lock.

Very considerate of us.

Why the Password Reset Doesn’t Always Save You

Imagine an attacker has already obtained a valid session or refresh token.

The security team detects suspicious activity and immediately changes the user’s password.

That is still an important step—but it may not terminate every session that was already established.

Depending on the platform, application and type of token involved, an existing session may remain usable until it expires or is explicitly revoked. Microsoft’s incident-response guidance therefore includes revoking refresh tokens and sign-in sessions as a separate action when responding to compromised accounts.

The proper response is not simply:

Reset the password.

It is:

Reset the password, revoke the sessions, invalidate the tokens, inspect the account, review the permissions, check the devices, examine the logs and make another pot of coffee because we are going to be here for a while.

This is no longer a single-button incident.

It is a checklist.

Preferably a checklist written after coffee, because a checklist written before coffee will contain items such as:

• Investigate account
• Revoke the coffee
• Reset user
• Drink password
• Cry professionally

Authentication Is the Beginning, Not the Finish Line

A successful login used to be treated as the moment where trust was established.

The user supplied the correct password, completed MFA and passed the conditional-access policy. Therefore, they must be legitimate.

Modern attacks demonstrate why that assumption is no longer enough.

Security systems also need to evaluate what the identity does after logging in.

For example:

• Is the user accessing applications they have never used?
• Did their operating system suddenly change?
• Are they downloading far more data than normal?
• Are they granting suspicious OAuth permissions?
• Did a Manitoba-based employee suddenly appear in another country?
• Are they creating inbox rules that quietly hide security notifications?
• Is the account accessing privileged resources at 3:17 a.m.?
• Is 3:17 a.m. too early for life?

Yes.

It is always too early for life at 3:17 a.m.

Continuous monitoring allows defenders to identify behavior that does not make sense for the person, device or workload behind the identity. Organizations need better visibility into authenticated activity instead of concentrating almost entirely on the login event.

The important question is no longer only:

“Did this identity authenticate successfully?”

It is also:

“Does what this identity is doing make any sense?”

Passkeys Help—but Attackers Will Keep Moving

Passkeys and FIDO-based security keys provide stronger protection against traditional phishing because they use public-key cryptography and are bound to the legitimate service rather than relying on a reusable password.

The FIDO Alliance describes passkeys as phishing-resistant by design, helping reduce phishing and credential-stuffing attacks.

That is excellent progress.

However, stronger login security does not magically make everything after the login invincible.

As passwords become harder to steal and MFA becomes more widely deployed, attackers naturally begin targeting whichever reusable piece of trust remains easiest to capture.

Today, that may be a browser cookie, OAuth token, refresh token, API key or active session.

Tomorrow, it will probably be something even more irritating with an acronym nobody understands before their third espresso.

Passkeys strengthen the front door.

We still need to protect the windows, basement, ventilation system and the suspicious person who has been sitting in the break room for six hours pretending to update Java.

What Organizations Should Actually Do

The answer is not to abandon password resets.

Password resets remain part of account-compromise response. They just cannot be the entire response.

A modern identity-security strategy should include several layers.

1. Revoke Active Sessions and Tokens

When an account is suspected of compromise, terminate active sessions and revoke refresh tokens wherever the identity platform supports it.

Do not assume the password reset handled this automatically.

In Microsoft Entra, administrators can block new sign-ins and revoke the affected user’s refresh tokens. Microsoft also provides administrative and Graph-based methods for invalidating sign-in sessions.

This is the digital equivalent of removing everyone from the building before issuing new keys.

2. Use Phishing-Resistant Authentication

Move toward FIDO2 security keys and passkeys where practical.

Traditional MFA is still dramatically better than relying on a password alone, but not every MFA method provides the same resistance to phishing, adversary-in-the-middle attacks or session theft.

Security maturity is not checking a box labelled “MFA enabled.”

It is understanding what kind of MFA is deployed, what attacks it resists and what weaker fallback methods remain available.

Otherwise, we are protecting the vault with an industrial steel door while leaving the emergency entrance propped open with a bag of medium-roast beans.

3. Protect and Bind Tokens to Devices

Where supported, use token-protection capabilities that bind tokens to trusted devices or cryptographic keys.

A stolen bearer token can potentially be replayed elsewhere because possession of the token may be enough to use it. Device-bound protections make that stolen token far less useful when moved to another system.

Microsoft recommends a defence-in-depth approach involving hardened devices, risk-based conditional access, device-bound tokens and controls intended to reduce token replay.

4. Monitor What Happens After Login

Collect and correlate identity, endpoint, cloud-application and network telemetry.

Look for unusual behaviour such as:

• New devices or operating systems
• Impossible or unexpected travel
• Suspicious application consent
• Abnormal downloads
• Privilege escalation
• New authentication methods
• Strange mailbox rules
• Access to unusual services
• Activity outside the user’s normal working pattern

A valid token tells you that the session possesses a valid token.

It does not tell you whether the person using it is Kevin, a threat actor or Kevin operating before coffee—which may be equally unpredictable.

5. Reduce Permissions and Long-Lived Access

Apply least privilege to user accounts, service accounts, third-party applications and non-human identities.

Review OAuth applications and remove permissions that are unnecessary, abandoned or far more powerful than the application requires.

Tokens should be protected, stored securely and revoked when they are no longer needed. Google’s OAuth guidance similarly recommends safeguarding tokens and revoking access that an application no longer requires.

The less access an identity has, the less damage an attacker can cause when that identity is compromised.

This is known as reducing the blast radius.

It is also known as not giving the office toaster Global Administrator because somebody wanted it to send notifications.

6. Update the Incident-Response Checklist

A compromised-account playbook should go beyond changing the password.

Depending on the environment, responders may need to:

• Disable or restrict the account
• Revoke active sessions and refresh tokens
• Reset the password
• Review and reset MFA methods
• Remove unfamiliar devices
• Inspect OAuth consent grants
• Check mailbox-forwarding settings and inbox rules
• Examine recent sign-ins and audit activity
• Identify downloaded or modified data
• Review privilege changes
• Search for lateral movement
• Investigate the user’s endpoint
• Determine how the token or session was obtained

Microsoft’s guidance for recent token-theft and adversary-in-the-middle campaigns recommends revoking compromised sessions and tokens alongside credential and MFA remediation.

In other words, do not simply change the lock.

Find out who entered, what they touched, whether they made copies of anything and why all the good coffee is missing.

The Final Sip

Passwords are not completely dead.

They are just no longer the only target.

As organizations improve password security and deploy stronger MFA, attackers are moving deeper into the authentication process. They are targeting sessions, tokens and trust relationships that allow them to appear legitimate after authentication has already occurred.

That means our security controls must move deeper too.

Protect the login, but also monitor the session.

Deploy stronger authentication, but also protect the tokens it creates.

Reset compromised passwords, but also revoke sessions, remove unauthorized access and investigate everything that happened afterward.

Because when the attacker already has a valid session, resetting the password alone is like changing the Wi-Fi password while they are connected through Ethernet.

Technically, you did something.

It just was not the thing that solved the problem.

Now please excuse me.

It is still too early for life, this incident has consumed the first half of my morning, and I need more coffee before someone asks whether turning MFA off will make the phishing alerts stop.

Brew a Byte and Code a Bean!