The dangerous account is not always the one breaking in. Sometimes it is the one that already has a badge, a mailbox, a VPN profile, a SaaS session, and access to the folder everyone forgot was sensitive.

That is why insider threat is often misunderstood. The useful question is not “which employee is bad?” It is “what can one trusted identity reach if trust stops being deserved?”

TL;DR

  • Insider threat includes malicious insiders, careless users, compromised employee accounts, and former users whose access was never fully removed.
  • The common failure is not personality. It is excessive access, weak offboarding, poor logging, and unclear data ownership.
  • Modern insider incidents often look like normal work: valid login, valid app, valid download, valid API call.
  • Detection works best when identity, device, data, and behavior signals are viewed together.
  • The goal is not workplace paranoia. The goal is to make trust revocable, scoped, and observable.

The Insider Is Not Always Inside

“Insider” sounds like a person sitting in the office with bad intentions. That version exists, but it is only one shape of the problem.

A practical defender should think in four categories.

The disgruntled insider still works for the organization but has a motive to cause harm, steal data, or leak information. The warning sign is not emotion by itself. People have bad weeks. The risk appears when unusual behavior meets useful access: bulk exports, new sharing links, odd-hours repository cloning, or searches for data outside the person’s role.

The negligent insider is not trying to help an attacker. They reuse passwords, approve an MFA prompt they did not start, upload customer data to an unsanctioned AI tool, or share a document with “anyone with the link.” This is often boring. Boring is still how incidents happen.

The compromised insider account is an external attacker wearing an internal identity. MITRE ATT&CK tracks this as Valid Accounts: adversaries can use real credentials for initial access, persistence, privilege escalation, and defense evasion. This is why a login success event is not the same thing as proof of a legitimate user.

The former insider with residual access is the one many organizations underestimate. The person left. The identity did not. A SaaS account stayed active, a refresh token survived, a personal device kept local files, an API key remained in a deployment script, or a shared admin password was never rotated.

That last category is not dramatic. It is just unfinished administration with incident potential.

A Simple Attack Path

Picture a sales manager leaving for a competitor. During the last week, they export customer lists, pricing notes, renewal dates, and private Slack messages. They do not exploit a vulnerability. They use the CRM, document storage, and chat search exactly as designed.

Now change the story slightly. The manager is not malicious. Their laptop was infected by an infostealer two months earlier. The attacker has browser cookies, saved passwords, and session tokens. From the company’s point of view, the same data access may still look like the employee.

Change it again. The manager already left, but the CRM account was not deprovisioned because it was outside the identity provider. The account still works. The data is still there. The company has no alert because nobody expected the account to exist.

Three stories. Same security lesson: the blast radius belongs to the access model, not the motive.

MITRE’s Data from Cloud Storage technique captures the modern version well. Sensitive data now lives in SharePoint, OneDrive, Google Drive, S3, Slack, Confluence, Salesforce, Dropbox, and dozens of smaller SaaS systems. Attackers and insiders often do not need to touch a server. They query the system that already holds the data.

What Defenders Should Look For

Insider threat detection fails when it hunts for villains instead of behaviors. A good signal is specific, explainable, and tied to business context.

Useful signals include:

  • A user downloading or exporting far more data than their normal baseline.
  • Access to sensitive folders, repositories, tickets, or CRM records outside the person’s role.
  • Logins from new devices, new countries, anonymization services, or impossible travel patterns.
  • New OAuth grants, app passwords, access tokens, SSH keys, API keys, forwarding rules, or mailbox delegates.
  • Privilege changes shortly before unusual data access.
  • Dormant accounts becoming active again.
  • Disabled or terminated users still appearing in SaaS audit logs.
  • Large file synchronization before resignation, termination, vendor offboarding, or contract end dates.

None of these signals proves malicious intent alone. That matters. A finance employee can legitimately export a large spreadsheet. A developer can clone a repository before a flight. A support engineer can view many customer records during an outage.

The value comes from correlation: who the user is, what their role requires, what device they used, what data they touched, whether the access was new, and whether the organization can explain it.

Offboarding Is An Incident Control

Offboarding is often treated as HR paperwork. Security teams should treat it as identity containment.

Microsoft’s Entra guidance for emergency access revocation is blunt about the operational details: disabling the user is not always enough. Administrators may need to revoke refresh tokens, disable devices, deprovision application accounts, and account for applications that manage their own session tokens. Microsoft also notes that there can be a delay between revocation and effective loss of access, depending on how applications handle tokens and sessions.

That is the part many playbooks miss. The identity provider is not the whole environment. SaaS applications, unmanaged devices, local files, shared credentials, service accounts, CI/CD secrets, and personal API tokens can survive the neat checkbox that says “user disabled.”

A useful offboarding checklist asks:

  • Which systems are connected to SSO, and which are not?
  • Which SaaS applications allow direct login outside the identity provider?
  • Which devices hold local copies of sensitive data?
  • Which shared passwords, API tokens, SSH keys, and service accounts did the person know or use?
  • Which groups, repositories, cloud roles, dashboards, and ticket queues did they inherit through teams?
  • Who verifies that access is gone, and where is the evidence?

The answer should not depend on one administrator remembering everything under pressure.

How To Reduce The Risk Without Turning The Workplace Into A Surveillance State

Insider threat programs can become unhealthy if every employee is treated as a suspect. That is bad security and bad management. People work around systems they do not trust.

The better model is boring and technical: least privilege, clear ownership, good logging, and rapid revocation.

Start with the identities. Every human account, admin account, service account, contractor account, and break-glass account needs an owner, a purpose, and an expiration path. If nobody owns it, nobody will notice when it becomes dangerous.

Then reduce reach. Do not give broad access because it is convenient during onboarding. Give the access required for the role, review it regularly, and remove it when the role changes. NIST’s Zero Trust Architecture frames this shift clearly: access decisions should focus on users, assets, and resources, not implicit trust based on network location.

Finally, make sensitive actions visible. Bulk export, mass download, external sharing, mailbox rule creation, privilege elevation, token creation, and access from unmanaged devices should leave logs that someone can actually use. Logging everything into a lake nobody reads is not detection. It is storage.

What You Can Do Today

Run a 30-minute access review with one uncomfortable question: if this account were compromised tonight, what could it reach by morning?

Pick ten identities:

  • One executive.
  • One help desk user.
  • One finance user.
  • One developer.
  • One contractor.
  • One former employee account.
  • One service account.
  • One CI/CD account.
  • One shared mailbox.
  • One break-glass admin.

For each, check data access, admin rights, SaaS memberships, active tokens, registered devices, mailbox rules, API keys, and last activity. You will probably find at least one account that makes everyone in the room quiet.

That account is the article in miniature.

You already know which one it is. You thought of it three paragraphs ago and decided it was probably fine. It is not the malicious employee that gets you — it is the access you forgot to ask about. Go ask.

Sources