Agent Foskett • Identity Security • Persistent Sessions

The Session Token Never Expired

The user had not entered their password in months.

No MFA prompt. No reauthentication. No interruption. Every morning the laptop opened straight into Outlook, Teams, SharePoint, OneDrive and internal systems.

The session simply continued. Day after day. Week after week. Month after month.

Eventually, the user could not remember the password at all. Because they never needed to.

This Agent Foskett briefing looks at one of the most overlooked identity risks in modern Microsoft environments: persistent sessions, refresh tokens, remembered devices and authentication that quietly stays alive far longer than most organisations realise.

Discuss your environment Back to briefings

Agent Foskett persistent session token and Microsoft 365 identity investigation

Briefing summary

Persistent Microsoft 365 sessions are often treated as convenience features, but long-lived authentication can quietly become a security blind spot. GEMXIT investigates how session persistence, remembered devices and weak sign-in policies create risk in real business environments.

Review sign-in frequency

Investigate refresh token persistence

Reduce long-lived session risk

What happened

The situation is common in real business environments. Users want their applications to stay open permanently because passwords and MFA are seen as interruptions rather than security controls.

Users wanted convenience People asked for Outlook, Teams, browsers and internal systems to stay signed in because repeated authentication was considered annoying.

Passwords became irrelevant Over time, users stopped entering passwords regularly and relied entirely on persistent browser and application sessions.

Nobody questioned the session Long-lived sessions became normal operational behaviour, even when devices were unmanaged, shared or rarely reviewed.

The device became trusted Authentication slowly shifted from proving the user was present to simply trusting an already-authenticated session on a familiar device.

Visibility reduced If users rarely sign in again, organisations may see fewer authentication events and less opportunity to challenge risky access.

Assumptions became the risk The dangerous assumption was simple: because the session still worked, the environment must still be safe.

The problem with “Stay signed in”

“Stay signed in” sounds harmless. But in many organisations, convenience slowly becomes the security model.

MFA prompts become rare If sign-in frequency is relaxed, users may not see regular MFA challenges even though the applications remain accessible.

Refresh tokens keep access alive Authentication may silently renew in the background, allowing access to continue without the user consciously signing in again.

Users forget what authentication is Eventually, the session itself becomes more trusted than the identity behind it.

First hunt: long-lived sign-in activity

Identity logs can help identify users and devices where authentication continuity appears unusually long or where the same device, client and applications keep appearing over time.

SigninLogs
| where TimeGenerated > ago(30d)
| summarize FirstSeen = min(TimeGenerated),
            LastSeen = max(TimeGenerated),
            Apps = make_set(AppDisplayName),
            IPs = make_set(IPAddress)
            by UserPrincipalName, DeviceDetail, ClientAppUsed
| extend SessionDurationDays = datetime_diff("day", LastSeen, FirstSeen)
| order by SessionDurationDays desc

What to review Look for users with unusually consistent access across the same device, browser, IP range and applications over extended periods.

Why it matters Persistent authentication reduces the number of visible moments where identity is actively verified and challenged.

Best next pivot Review Conditional Access sign-in frequency, persistent browser session settings, remembered MFA behaviour and unmanaged device usage.

Second hunt: refresh tokens and persistent access indicators

A successful MFA event does not mean the session is safe forever. MFA protects the authentication event, but session and token behaviour still need to be understood.

SigninLogs
| where TimeGenerated > ago(14d)
| project TimeGenerated,
          UserPrincipalName,
          AppDisplayName,
          ClientAppUsed,
          IPAddress,
          ConditionalAccessStatus,
          AuthenticationRequirement,
          AuthenticationProcessingDetails,
          DeviceDetail
| order by TimeGenerated desc

What to review Look at authentication requirements, device detail, client application, Conditional Access result and whether MFA is being required or silently satisfied.

Why it matters MFA does not automatically mean sessions expire quickly, tokens are revoked, or every future access attempt is challenged again.

Best next pivot Review Conditional Access session controls, sign-in frequency, token revocation processes and whether personal devices are being trusted too easily.

Third hunt: unmanaged devices with persistent access

Persistent sessions are more concerning when the access comes from devices that are not compliant, not managed or not clearly trusted by the organisation.

SigninLogs
| where TimeGenerated > ago(30d)
| extend DeviceName = tostring(DeviceDetail.displayName),
         TrustType = tostring(DeviceDetail.trustType),
         Browser = tostring(DeviceDetail.browser),
         OperatingSystem = tostring(DeviceDetail.operatingSystem)
| where isempty(TrustType) or TrustType !has_any ("Azure AD joined", "Hybrid Azure AD joined")
| project TimeGenerated, UserPrincipalName, AppDisplayName, IPAddress, DeviceName, TrustType, Browser, OperatingSystem
| order by TimeGenerated desc

What to review Check whether persistent access is coming from devices with no clear trust type, unmanaged browsers, personal laptops or unknown operating systems.

Why it matters A long-lived session on a managed device is one thing. A long-lived session on an unmanaged device is a very different risk conversation.

Best next pivot Use Conditional Access to require compliant devices, block unsupported clients and separate trusted corporate access from personal device convenience.

Where this becomes dangerous

The risk is not that a user stayed signed in for one afternoon. The risk is when persistent access becomes normal, unmanaged and forgotten.

Shared devices Old sessions may remain active after staff changes, device handovers or casual shared computer use.

Personal laptops Unmanaged devices can retain access to business email, cloud files and web apps long after the original sign-in occurred.

Departed employees Offboarding that disables accounts but misses session revocation, browser profiles or synced credentials may leave uncomfortable gaps.

Stolen devices An already-authenticated device dramatically reduces attacker effort because the identity challenge may have happened days or weeks earlier.

Weak monitoring If nobody reviews sign-ins, application access or device trust, persistent sessions can become invisible operational risk.

Convenience culture The phrase “just keep me signed in” can slowly override sensible session controls if nobody pushes back with evidence.

What businesses commonly say

This is not a technology problem alone. It is also a behaviour problem. Security slowly bends when convenience becomes the loudest requirement.

“Just keep me signed in.” A small convenience request can become a broad exception if it is copied across the business without review.

“I forgot my password again.” If users forget passwords because they never authenticate, the business has lost an important rhythm of identity verification.

“It is only my laptop.” That may be true today. But the security question is what happens when the device is lost, stolen, reused or accessed by someone else.

What should organisations do?

The answer is not to make every user miserable. The answer is to apply practical session controls based on risk, device trust and business impact.

Set sensible sign-in frequency Use Conditional Access session controls so users are periodically required to prove they are still the right person.

Separate managed and unmanaged devices Trusted company devices should not be treated the same as personal laptops, unknown browsers or shared machines.

Revoke sessions when risk changes Lost devices, staff exits, suspected compromise and password resets should include session revocation and token invalidation where appropriate.

Monitor authentication behaviour Review sign-in logs, device details, application access, location patterns and unusual session behaviour regularly.

Question “always signed in” requests Convenience requests should be discussed as risk decisions, not treated as harmless configuration preferences.

Align controls with Zero Trust Identity, device health, session age, location and application sensitivity should all influence whether access continues.

How GEMXIT approaches session security reviews

At GEMXIT, we do not simply ask whether MFA is enabled. We look at how identity, devices and sessions behave after the first successful login.

We review session behaviour How long do users stay signed in? Which devices are trusted? Are unmanaged devices retaining access for too long?

We validate Conditional Access Session controls, sign-in frequency, MFA requirements and device trust need to work together, not exist as isolated settings.

We reduce practical risk The goal is not to annoy users. The goal is to stop forgotten sessions becoming invisible access paths.

Final thought

Attackers do not always need to steal credentials anymore. Sometimes the authentication already happened weeks ago.

At GEMXIT We help organisations review Microsoft 365, Entra ID, Defender XDR, Sentinel and Conditional Access controls to identify practical identity and session risks before they become incidents.

Agent Foskett mindset The important question is not only “Was MFA enabled?” It is “How long did the trusted session survive after authentication?”

Continue the investigation with the MFA Session Hijacking briefing, When Nothing Looks Wrong, Identity and Access Security, Zero Trust and GEMXIT Security Review.

Develop IT. Protect IT. GEMXIT PTY LTD | GEMXIT UK LTD