Agent Foskett • Entra ID • Offboarding Investigation

The User Was Disabled… But The Account Was Still Active

The user had left the business.

HR confirmed the termination. IT disabled the Microsoft 365 account. The password was reset. MFA was blocked. The checklist looked complete.

Everything looked secure.

But the phone was still syncing mail.

Teams was still open in the browser.

SharePoint access continued quietly in the background.

The account was disabled.

The session wasn’t.

This Agent Foskett briefing investigates a real-world Microsoft 365 offboarding risk: disabled users, active sessions, refresh tokens, remembered devices and cloud access that can continue after the identity appears to be locked down.

Discuss your environment Back to Investigation Hub

Agent Foskett Microsoft Entra disabled user active session investigation

Briefing summary

Disabling an account can stop new sign-ins, but it does not always tell the full story. GEMXIT investigates stale sessions, refresh tokens, remembered devices and cloud access that may continue after offboarding.

Review account disable events

Investigate stale sessions

Revoke tokens and access

What happened

The situation is more common than many organisations realise. A staff member leaves, the account is disabled, and everyone assumes access has ended. But cloud access is not only controlled by the account object. It is also influenced by active sessions, refresh tokens, remembered devices and application behaviour.

The account was disabled From the admin portal, the identity appeared locked down. New authentication should have been blocked.

The session remained alive Existing authenticated sessions continued to behave as trusted access paths in some applications.

Access continued quietly Outlook, Teams, SharePoint and browser sessions can create confusion when offboarding is treated as a single checkbox.

Mobile apps kept syncing Mobile email clients may continue showing recently synced mail, and some session behaviour may not be obvious from the account status alone.

The dashboard looked finished The account status said disabled, but the access story needed to be checked through logs and application activity.

The logs told the truth SigninLogs, AuditLogs and CloudAppEvents can help reveal whether access really stopped after disablement.

Why disabling an account is not the whole story

Disabling a user account is important, but it is not the same as invalidating every existing session, refresh token, device relationship or application state.

Tokens can outlive assumptions Refresh tokens and remembered sessions can create access behaviour that is not obvious from the user status alone.

Apps cache access Modern cloud apps are designed for convenience, so users are not constantly interrupted by sign-in prompts.

Offboarding needs verification The right question is not only “was the account disabled?” It is “did access actually stop?”

First hunt: find successful sign-ins after the account was disabled

Start with the user and the offboarding time. Look for any successful sign-in or token-related activity after the disable event.

let DisabledUser = "user@company.com";
let DisableTime = datetime(2026-05-20T09:00:00Z);
SigninLogs
| where TimeGenerated > DisableTime
| where UserPrincipalName =~ DisabledUser
| project TimeGenerated,
          UserPrincipalName,
          AppDisplayName,
          ClientAppUsed,
          IPAddress,
          ResultType,
          ConditionalAccessStatus,
          DeviceDetail
| order by TimeGenerated desc

What to review Look for successful sign-ins, repeated app activity, device details, IP addresses and any access after the official disable time.

Why it matters Any access after disablement deserves investigation, even when the admin portal shows the account as disabled.

Best next pivot Compare sign-ins with AuditLogs to confirm exactly when the account was disabled and when sessions were revoked.

Second hunt: confirm the disable event and session revocation

Offboarding should leave evidence. AuditLogs can help confirm whether the account was disabled, whether refresh tokens were revoked, and whether password or MFA actions occurred.

AuditLogs
| where TimeGenerated > ago(14d)
| where TargetResources has "user@company.com"
| where OperationName has_any (
    "Update user",
    "Disable account",
    "Reset password",
    "Revoke user sign in sessions"
)
| project TimeGenerated,
          OperationName,
          Result,
          InitiatedBy,
          TargetResources
| order by TimeGenerated desc

What to review Confirm who disabled the account, when it happened, and whether session revocation was actually performed.

Why it matters A password reset or account disable may not be enough if existing sessions were never revoked.

Best next pivot Move from identity administration events into cloud application activity after the disable time.

Third hunt: cloud application activity after offboarding

If the account was disabled at 9:00 AM, application activity at 9:20 AM matters. CloudAppEvents can help reveal whether access continued inside Microsoft cloud services and connected applications.

let DisabledUser = "user@company.com";
let DisableTime = datetime(2026-05-20T09:00:00Z);
CloudAppEvents
| where Timestamp > DisableTime
| where AccountDisplayName has "user"
   or AccountId has DisabledUser
| project Timestamp,
          AccountDisplayName,
          Application,
          ActionType,
          IPAddress,
          DeviceType
| order by Timestamp desc

What to review Look for file access, mailbox activity, SharePoint usage, Teams activity or application actions after disablement.

Why it matters Identity status is only one part of the story. Application telemetry shows whether business data was still being touched.

Best next pivot Review device ownership, browser profiles, mobile devices and any personal device access associated with the user.

Where this becomes dangerous

The risk is not only that an old account exists. The risk is that access continues after the business believes the person is gone.

Departed employees Offboarding gaps can expose email, files, Teams chats and internal systems after employment ends.

Personal devices BYOD access can be difficult to control if session revocation and device removal are not part of the process.

Shared browsers Browser profiles, remembered accounts and cached sessions can continue to create confusion after the user is gone.

Lost devices If a device is missing, stolen or never returned, an existing session can become a direct access path to business data.

Weak offboarding checklists Account disablement is only one step. Tokens, sessions, devices, groups, apps and mailbox delegation all need review.

False confidence The most dangerous moment is when everyone believes the risk is closed, but the logs show access continued.

What should organisations do?

A good offboarding process does not stop at disabling the user. It verifies access closure across identity, sessions, devices and applications.

Revoke active sessions Session revocation should be part of high-risk user exits, suspected compromise and device-loss workflows.

Remove device access Review registered devices, mobile apps, browser access, Intune state and unmanaged device exposure.

Validate with logs Check SigninLogs, AuditLogs and CloudAppEvents to confirm access stopped after the account was disabled.

Review mailbox delegation Delegated access, shared mailboxes, forwarding rules and app permissions can leave unexpected paths open.

Check OAuth app grants Third-party app consent and OAuth permissions should be reviewed when users leave or roles change.

Align with Zero Trust Access should continuously depend on identity, device trust, session age, risk and business context — not yesterday’s login.

How GEMXIT approaches offboarding security reviews

At GEMXIT, we do not simply ask whether the account was disabled. We look at whether the user, device, session and application access actually stopped.

We review the offboarding trail Who disabled the account? When did it happen? Were sessions revoked? Were devices removed?

We validate real access Logs are used to confirm whether Microsoft 365, Teams, SharePoint, OneDrive and connected apps were still being accessed.

We reduce practical risk The goal is not theory. The goal is to make sure people who leave the business no longer retain quiet access to it.

Final thought

Offboarding does not finish when the account is disabled. It finishes when access has actually stopped.

At GEMXIT We help organisations review Microsoft 365, Entra ID, Defender XDR, Sentinel and Conditional Access controls to identify disabled-user access, stale sessions and offboarding gaps before they become incidents.

Agent Foskett mindset The important question is not only: “Was the account disabled?”

It is: “Did access actually stop?”

Continue the investigation with Cyber Security Is Not Just Antivirus, MFA Session Hijacking, The Session Token Never Expired, The VPN Login Continued After The Exit Meeting, When Nothing Looks Wrong, Identity and Access Security, Zero Trust and the GEMXIT Security Review.

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