You detect activity by reviewing sign-ins, mailbox events, file access and other audit trails after the user’s termination date. Look for any successful authentication, token use, delegated access or changes made after offboarding. Correlate those events with HR termination records, then investigate whether access was missed, shared credentials were used, or the account was not fully disabled.
What makes terminated-user activity visible in Microsoft 365?
The signal is usually a mismatch between offboarding records and post-termination telemetry. A terminated user should not continue to generate successful sign-ins, mailbox actions, file reads, inbox-rule changes or delegated-access activity. Your job is to compare Microsoft 365 audit evidence against the HR termination timestamp and then separate normal residual activity from account misuse, shared credentials or an incomplete disablement.
Start with the account itself, then widen to the identities and pathways that could still act on its behalf. Review Entra sign-in records, unified audit logs, Exchange mailbox events, SharePoint and OneDrive access, and any OAuth app or session activity that was still valid after offboarding. That view gives you both the who and the how of the activity, which matters when a former employee, a shared mailbox, or a delegated process is involved.
A useful practical distinction is whether the account was still authenticating or whether access was coming through something the user had already set up. If you see token use, app consent, delegated mailbox access, legacy sessions, or mailbox forwarding rules after termination, the issue is broader than a simple login check. In that case, review whether the access path was intentionally preserved for business continuity or whether it should have been revoked at offboarding.
Which Microsoft 365 events matter most after offboarding?
Successful sign-ins after the termination date are the first thing to validate, but they are not the only important evidence. Mailbox forwarding, inbox rule creation, privilege changes, file downloads, sharing events and admin or consent activity can all show that the former user still has effective reach into the tenant. Those events are especially important when they occur from new devices, unusual locations, or outside the person’s normal working window.
Mailbox and collaboration telemetry deserve special attention because they can reveal both direct abuse and indirect persistence. A former employee may not log in interactively and still access mail through delegated permissions, an active token, a synced client or a retained session. That is why audit trails across Exchange, SharePoint, OneDrive and Entra are more reliable than looking at termination status alone.
For stronger triage, compare the activity pattern before and after termination. A clean offboarding usually produces a hard stop in legitimate user behaviour, followed only by expected system noise such as delayed sync or retention processing. If the account continues to alter content, grant access, or reach resources after the cutoff, treat it as a control failure until you can prove otherwise. See the Joiner-Mover-Leaver (JML) Guide for the offboarding controls that should prevent this class of gap.
How do you separate benign residual access from a real problem?
Not every post-termination event is malicious, so the key is whether the access should still exist. Shared mailboxes, automation accounts, service-linked access, litigation-hold activity and delegated administrative workflows can all produce events that look suspicious at first glance. The investigation should ask whether the activity was authorised, whether it was expected to continue, and whether the permissions were explicitly transferred rather than simply left behind.
Correlating identity, HR and audit records is the best way to avoid false conclusions. If the audit trail shows activity after the termination date and there is no matching business exception, the likely causes are missed disablement, token persistence, password sharing, stale delegated access or a lingering app credential. If the trail shows only background processing with no new access decisions, the account may be inactive but still present in logs because of retention or sync delay.
That is why offboarding should be validated as a control outcome, not just a workflow completion. If a terminated user can still reach tenant data, the organisation has not actually removed their effective access. The Microsoft 365 Security Guide covers the logging and tenant-hardening settings that make this kind of review practical.
Risk and Threat Considerations
Post-termination activity is a high-value indicator because it often means one of two things: the access was not fully removed, or someone is abusing a remaining trust path. In Microsoft 365, that can expose mail, documents and collaboration data long after employment has ended, especially when tokens, delegated access or shared credentials survive the offboarding event.
Failure mechanism: The account is disabled too late, tokens remain valid, or a delegated or shared access path was never revoked, so activity continues after the termination date without a fresh interactive login.
Impact: Former users, insiders or attackers can read mail, alter files, create forwarding rules, harvest sensitive data, or preserve access for later abuse, which can turn an HR event into an active security incident.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AU-6 — Audit Record Review, Analysis, and Reporting | Post-termination detection depends on reviewing sign-ins and audit trails. |
| IA-5 — Authenticator Management | Terminated-user activity often indicates lingering tokens or credentials. | |
| Recommendation — Review Microsoft 365 audit records for activity that persists after offboarding. Revoke or invalidate authenticators and tokens at offboarding. | ||
| CIS Controls v8 | CIS-5 — Account Management | Offboarding requires timely disablement and removal of lingering access paths. |
| Recommendation — Disable terminated accounts and remove their access paths promptly. | ||
| NIST CSF 2.0 | DE.CM-01 — Networks and Network Services Are Monitored to Find Potentially Adverse Events | Detection here relies on monitoring sign-ins and other Microsoft 365 events. |
| PR.AA-05 — Identities Are Proofed, Bound to Credentials, and Bound to Authenticator | This issue often involves credentials or sessions that remain usable after offboarding. | |
| Recommendation — Monitor identity and SaaS telemetry for post-termination activity. Bind and retire credentials so former users cannot keep authenticating. | ||
Practitioner Guidance
What to verify: Confirm that the termination timestamp, account disablement time, token invalidation and access revocation line up. If the account still has a valid access path after the HR cutoff, treat the event as an offboarding failure first and an investigation second.
Decision rule: If the activity is a successful sign-in, rule change, file action or delegated mailbox use after termination, escalate immediately; if it is only background processing with no access decision, validate retention and sync behaviour before opening a broader incident.
What good looks like: A terminated-user account stops producing meaningful activity, any necessary exceptions are explicit and time-bound, and the audit trail can show exactly why any post-termination access was still allowed.
Practitioner takeaway: The most useful detection is not “did the account exist?” but “did any effective access survive the offboarding date?” That distinction tells you whether you have an audit task, an access-control failure, or an active compromise to contain.
Related resources from NHI Mgmt Group
- What should you monitor to detect suspicious device activity in Microsoft Entra ID?
- How do you detect delegated permissions granted for all users in Microsoft Entra ID?
- How do you detect guest users converted to members in Microsoft Entra ID?
- How do you detect guest users invited by unapproved inviters in Microsoft Entra ID?