You Changed the Password. You Reset MFA. The Attacker May Still Be Logged In. NIST Just Explained Why
Fresh Guidance Identity & Access
You discover an employee's account has been compromised. You do exactly what you've been told to do — change the password, reset MFA, have them sign back in. Problem solved. Except the attacker may never have needed the password again. Somewhere in the background, your cloud service may already have handed them something more useful: a token that says, in effect, this person has already proven who they are. Let them in. Six days ago, the US government's standards agency finalized an entire technical guide around exactly that problem.
Every response plan in this series eventually says some version of the same thing: if an account is compromised, change the password and reset multi-factor authentication. That advice is correct, and it remains the right first move. It's also, on its own, sometimes incomplete — and the reason why has just been laid out in unusual detail by the two US agencies best positioned to explain it.
Your password isn't what keeps you logged in
Think about how often you actually type your password in a given day. Probably far less often than you're using email, cloud storage, or a work app that's already signed in. That's not an accident — it's a deliberate convenience built into how modern systems work.
When you log into a cloud service, it typically doesn't ask you to prove who you are on every single click. Instead, after that first successful login, it hands your browser or app something called a token — a small piece of data that says, in effect, "this person already proved who they are, let them use the connected systems." Every action after that point checks the token, not your password. It's the reason you can go a full workday without re-entering your credentials once.
MFA protects the moment you prove who you are. A stolen token can attack what happens after that moment.
Why attackers want the token instead
Once your identity has been verified and a token issued, that token is often, from the system's point of view, functionally interchangeable with you. Someone holding a valid token doesn't need your password, and — this is the part worth sitting with — they typically don't need to pass MFA again either, because as far as the system can tell, that already happened.
This is precisely why stealing the result of a successful login can be more valuable to an attacker than stealing the credential that produced it. A password gets you to the front door. A token can already be standing in the hallway.
This is why MFA can appear to have been "bypassed"
Several posts in this series have described attacks that seemed to sail straight past multi-factor authentication — a real page, a valid certificate, MFA approved, and the attacker in anyway. It's tempting to read those as MFA failing. That's usually not quite right. MFA typically isn't defeated cryptographically in these cases. What gets stolen or abused is what comes after MFA succeeds — the token issued once the system is satisfied you are who you say you are.
NIST and CISA just made this a priority
On September 15, 2026, the National Institute of Standards and Technology and the Cybersecurity and Infrastructure Security Agency jointly finalized NIST Interagency Report 8587, "Protecting Tokens and Assertions from Forgery, Theft, and Misuse" — built with input from roughly 250 public comments and CISA's ongoing collaboration with cloud providers and industry partners.
the new NIST interagency report dedicated entirely to protecting the tokens that keep you signed in
The guidance covers how tokens should be verified, how long they should remain valid, how they should be revoked, how sessions should be monitored, and how the cryptographic keys that sign those tokens need to be protected — across single sign-on, identity federation, and API access, for both human logins and automated system-to-system access. One of the report's own authors, a NIST digital identity specialist, was explicit that the guidance isn't only for government: any organization using tokens as part of how it manages access can use it for insight, inside government or out.
The report isn't a theoretical exercise. It's grounded in a real, previously documented case: attackers who compromised a single stolen cryptographic signing key were able to forge valid tokens and access federal agency email systems, exfiltrating more than sixty thousand emails from one agency in the process — without cracking a single password or defeating anyone's MFA. That's the scenario this entire guidance exists to prevent from happening again.
What to ask your IT provider
None of this requires you to understand cryptography. It requires knowing the answers to six specific questions — worth asking whoever manages your systems, whether that's internal staff or an outside provider.
When we compromise-respond to an account, do you revoke active sessions as well as change the password?
Can you see where our current cloud sessions originated?
How long do our sessions and access tokens remain valid before they expire on their own?
Can you terminate every active session for one specific employee immediately, on request?
Is unusual token use or sign-in activity actively monitored, or only reviewed after something looks wrong?
What happens to a departing employee's active sessions and tokens, not just their account?
The short version
Changing a compromised employee's password and resetting their MFA is still the right first step — do it, every time. What NIST and CISA just spent months formalizing is the part that often gets skipped afterward: confirming that every session and token created before you noticed the problem has actually been closed, not just that the front door has a new lock. MFA protects the moment you prove who you are. A stolen token can attack what happens after that moment — and now there's a detailed, government-backed roadmap for making sure that moment doesn't last longer than it should.
See where your identity and access controls actually stand today.
View the Threat Intelligence feed → Find Out More About ThreatAngel →📚 Credential Security Series → Read the full series
Comments
Post a Comment