For years, authentication security has focused on making one moment harder for attackers: the login. Password rules became stricter, multifactor authentication (MFA) added another check, single sign-on brought access under greater control and passkeys are now making phishing-resistant authentication easier to deploy.
All of that has made authentication stronger. But there's an awkward reality hiding just behind the login screen. Once someone has successfully proved who they are, most applications don't keep asking them to prove it again every time they open a file, read an email or move between pages.
That would be secure in much the same way that locking every internal door in an office would be secure. It would also make getting anything done incredibly irritating. Instead, the application creates an authenticated session.
A cookie, token or another session secret essentially tells the system that authentication has already happened, allowing the user to continue working without starting from scratch every few minutes. And attackers have noticed. Microsoft has documented several campaigns in 2026 where attackers captured or obtained authenticated tokens and used them to access enterprise environments.
Meanwhile, SpyCloud says it recaptured 8.6 billion stolen session cookies from criminal sources in 2025 alone. The login is still important. But increasingly, the more interesting security question is what happens to the trust it creates afterwards.
What Happens After Authentication Succeeds?
Authentication is an event. You provide evidence that you are who you claim to be, the system checks it and, assuming everything looks right, you get access. That evidence might include a password, an authenticator app, a security key, biometrics or a passkey. Once you're in, session management takes over.
NIST explains that a session can begin in response to authentication and continue across multiple interactions until something ends it, such as a logout or timeout. This prevents users from having to repeat the complete authentication process whenever they do something new.
The session needs some way to connect the person or software that authenticated with the service they're using. NIST calls this a "session secret". In a web browser, that might be a session cookie. Other applications can use different mechanisms, but the basic idea remains the same. In other words, authentication establishes trust and the session carries it forward.
That distinction becomes especially important with access tokens. NIST warns that the presence of an access token shouldn't automatically be treated as evidence that the original user is still present. Access and refresh tokens can remain valid after the authentication session has ended and the user has left the application.
There are good reasons for this architecture. Nobody wants to complete MFA before reading every email. But it means authentication security has two related jobs: establishing who should get access in the first place, then protecting the authenticated state that allows that access to continue. Attackers don't necessarily have to beat both.
Attackers Can Target The Trust Authentication Creates
Traditional phishing makes intuitive sense. An attacker tricks someone into giving away their username and password, then uses those credentials to log in as them. MFA makes that considerably harder because the password alone is no longer enough. Session hijacking changes the target.
Instead of only trying to steal what a user needs to authenticate, an attacker can target the cookie or token created once authentication has already succeeded. If that artefact can be reused, the attacker may be able to inherit an authenticated session. Microsoft saw exactly this in a 2026 campaign it tracks as Storm-2755.
Attackers used adversary-in-the-middle (AiTM) techniques to proxy the authentication flow and capture credentials alongside session cookies or OAuth access tokens. Microsoft observed stolen session tokens being replayed while the same session ID remained active. That access wasn't theoretical.
Storm-2755 targeted payroll and HR processes, using authenticated sessions while pursuing direct financial gain. Microsoft observed non-interactive sign-ins occurring roughly every 30 minutes until defenders revoked the active session tokens. Phishing isn't the only way authenticated access can be stolen.
Infostealer malware can extract credentials, cookies and authentication tokens from compromised devices. SpyCloud says the 13.2 million infostealer infections it recaptured from criminal sources in 2025 contained 642.4 million credentials and 8.6 billion cookies.
Those figures come from SpyCloud's own recaptured criminal-underground dataset, so they shouldn't be read as a measurement of every stolen session worldwide. But they do show how much value attackers are placing on authentication artefacts that can provide access without starting at the login screen.
This is why describing every successful account compromise as an "MFA bypass" can miss an important part of what actually happened. Sometimes the attacker hasn't broken the authentication control at all. They've found another way to obtain the access it created.
Stronger Authentication Doesn't Solve Session Security
This doesn't make MFA, passkeys or phishing-resistant authentication less important. Quite the opposite. Making it harder for attackers to impersonate legitimate users removes some of the easiest paths into enterprise systems. Microsoft, for example, began rolling out passkeys as the default phishing-resistant authentication method for eligible Microsoft Entra ID users on 1 September 2026.
The company is encouraging organisations to move away from more easily phished methods such as SMS and voice authentication. Yet Microsoft's threat research published just eight days later demonstrates why authentication and session security can't be treated as the same problem.
Researchers found attackers using passkey, MFA and SSO-themed lures to impersonate IT helpdesks. The passkey itself often wasn't what the attacker wanted. Instead, the story gave them a believable reason to guide victims into AiTM phishing or device-code authentication flows.
In one attack sequence, the victim entered a device code on Microsoft's legitimate authentication page. That authorised an attacker-controlled client and issued it a token. The attacker then replayed the compromised token and continued the attack. There's an important distinction here. The attacker didn't passkey cryptography.
Nor does the campaign demonstrate that stronger authentication has somehow become pointless. The authentication mechanism and the surrounding process are different parts of the same system. Phishing-resistant authentication can make one part significantly harder to compromise.
It doesn't guarantee that every token, session or authentication flow connected to it will remain under the legitimate user's control. That leaves security teams with a wider problem than deciding how somebody should prove their identity.
They also need to decide how long the resulting trust should last, when it needs to be checked again and what happens when there's evidence that somebody else has inherited it.
A Compromised Session Changes The Incident Response Problem
Imagine an employee's password has been compromised. Resetting it is an obvious response. If the account is protected by MFA, security teams may also investigate the enrolled authentication methods and remove anything suspicious. But what happens to sessions that are already active?
If an attacker has stolen valid authenticated state, changing the original password doesn't necessarily answer that question. Incident response needs to establish:
- what access remains valid;
- which sessions are still active;
- whether any compromised tokens can continue being used.
Storm-2755 shows why. Microsoft found that the attacker could maintain authenticated sessions through repeated token replay until remediation revoked the active session tokens. In some cases, password and MFA changes were also observed as the attacker sought more durable persistence.
Visibility is another part of the problem. SpyCloud's 2026 Identity Threat Report surveyed more than 750 security decision-makers and practitioners. Sixty-eight per cent said their organisation had experienced an identity-based event during the previous year, with affected organisations reporting eight events on average.
More relevant to identity incident response is the difference SpyCloud found around stolen session cookies. Organisations reporting identity events were less likely to have visibility into them, at 37 per cent compared with 50 per cent among organisations that hadn't reported an identity event.
Correlation doesn't prove that the visibility gap caused those incidents. It does, however, point towards a practical problem. Security teams can't reliably terminate compromised authenticated access they don't know exists. A password reset may still be necessary. So might removing an unauthorised MFA method or dealing with malware on the endpoint.
But session revocation and token invalidation need to be part of the same conversation if the goal is to end the attacker's access rather than simply repair the credential they started with.
Identity Security Has To Protect The Life Of The Session
Once authentication and session management are treated as separate but connected security problems, the defensive priorities become easier to see. The answer isn't another authentication factor stacked on top of the existing ones.
It's understanding what happens to trust after authentication and making sure that trust doesn't continue unquestioned simply because the original login was legitimate.
Know what keeps users authenticated
Start with something deceptively simple: what actually keeps your users logged in? Security and IAM teams need visibility into how important applications maintain authenticated sessions, which identity providers are involved and what cookies or tokens allow access to persist. The length of that persistence also deserves attention.
A short-lived session and a refresh token capable of extending access create very different exposure windows. This becomes more complicated in federated environments. NIST notes that an identity provider and the applications relying on it can manage sessions separately. Ending the identity-provider session doesn't necessarily terminate every application session that was created from it.
For security architects, that creates a useful diagnostic question. If a user account were compromised right now, could the organisation identify the sessions created from it and understand which ones would remain valid after the obvious remediation steps? If the answer isn't clear, the authentication architecture may be stronger than the organisation's understanding of what happens afterwards.
Decide when trust needs to be rechecked
Sessions need to last long enough to be useful, but usefulness isn't the only consideration. The level of confidence established at 9am shouldn't automatically remain unchanged hours later if the context around that session has changed significantly. NIST recommends periodic reauthentication and distinguishes between overall session timeouts and inactivity timeouts.
It also describes session monitoring, sometimes called continuous authentication, where characteristics such as usage patterns, device and browser information, location and IP address behaviour can be evaluated for possible fraud. The goal isn't to make employees authenticate constantly.
That simply recreates the usability problem sessions were designed to solve. Instead, organisations can decide which changes or higher-risk actions justify asking for fresh evidence. A user downloading an unusual volume of sensitive files, accessing a high-value system from a different context or attempting a particularly sensitive action may warrant more scrutiny than somebody continuing an ordinary working session.
The important shift is treating authenticated trust as something with conditions, rather than something granted once and assumed until logout.
Make compromised access easy to end
Detection has limited value if security teams can't quickly remove the access they've identified as compromised. That means session revocation needs to be considered alongside password resets, credential rotation and MFA remediation.
Security operations and IAM teams need a clear understanding of who can terminate sessions, which systems respond to revocation and how quickly those decisions take effect across connected applications. NIST recommends terminating or reauthenticating sessions when monitoring identifies potential fraud.
SpyCloud's 2026 survey points in a similar operational direction, with 35 per cent of respondents planning to automate identity-related incident-response workflows over the following 12 to 18 months. The real measure isn't simply whether the organisation detected token theft.
It's how quickly it can turn that detection into the end of the attacker's usable access. That brings authentication, session management and incident response into the same lifecycle. Security teams establish trust, decide how long it can reasonably persist, watch for evidence that the situation has changed and need a reliable way to withdraw it when it has.
Final Thoughts: Authentication Is An Event, Trust Has A Lifecycle
Authentication has improved enormously. MFA has made stolen passwords less useful on their own, while passkeys and other phishing-resistant methods are making some of the most familiar authentication attacks harder to pull off. None of that changes the practical need for sessions.
People need to stay logged in long enough to work, and applications need some way to remember that authentication has already happened. But that convenience creates something valuable: authenticated state. And anything that provides valuable access eventually becomes interesting to attackers.
Strong authentication establishes trust. Strong session security protects what happens to that trust afterwards. Treating the two as part of the same lifecycle gives IAM and security teams a much clearer way to think about post-authentication risk, from the moment a session is created to the moment it needs to end.
As authentication continues to improve, attackers will keep looking for the access paths those controls leave around them. Keep following EM360Tech for the latest research and expert insight into how identity threats are changing, and what those changes mean for enterprise security.
Comments ( 0 )