Workforce Identity Management Breaks at the Help Desk, Not the Login

What workforce identity management actually covers

Workforce identity management governs how employees, contractors and internal service accounts authenticate, and what they can reach once inside. In practice it is five things: authentication strength, the joiner-mover-leaver lifecycle, privileged access, access certification, and account recovery.

The fifth one is the subject of this article, because it is the one nobody owns.

This is a different discipline from customer identity. CIAM optimises for registration conversion, consent and privacy rights across a population that self-registers at unpredictable volume. Workforce identity optimises for control and auditability across a population that is known, enrolled through HR, and finite. Running one on the other’s platform is common, and it produces either weak internal control or a hostile sign-up flow.

The gap between those two numbers is the whole argument. Credentials are not usually how the intruder gets in. They are how the intruder gets everywhere else.

The campaign that changed the threat model

Between April 2025 and 2026, one loosely organised group — tracked as Scattered Spider, and also as UNC3944, Octo Tempest and Storm-0875, catalogued by MITRE ATT&CK as G1015 — ran the same play across four industries in roughly four months.

What matters here is not the group. It is that none of these intrusions required breaking authentication. The technique was a phone call.

Why strong MFA did not stop it

1. 1

   Reconnaissance on public sources

   Names, job titles, reporting lines and internal vocabulary are assembled from LinkedIn, press releases and breach data. Enough to sound like a colleague.

   Breaks here: Nothing, realistically. This information is public and treating it as secret is not a strategy.

2. 2

   A call to the service desk

   The caller impersonates an employee, manufactures urgency — a locked-out executive before a board meeting is the canonical script — and asks for a password reset or a new MFA enrolment.

   Breaks here: Identity proofing at recovery that a caller cannot satisfy by knowing public facts. This is the single highest-value control in the chain.

3. 3

   MFA is reset onto the attacker's device

   The agent performs a legitimate administrative action. No exploit, no malware, no alert — from the identity platform's point of view nothing anomalous has happened.

   Breaks here: Alerting on MFA method changes as a security event, and a second approver for high-privilege resets.

4. 4

   A fully legitimate session

   The attacker now holds a valid credential and a valid session token. Conditional access policies evaluate the session as trusted, because by every signal available it is.

   Breaks here: Device compliance as an access condition — a reset credential on an unmanaged device still fails the check.

5. 5

   Lateral movement and exfiltration

   SaaS admin consoles, data platforms and virtualisation infrastructure. In the documented cases this meant Snowflake exfiltration and ransomware deployed to ESXi hosts.

   Breaks here: No standing privilege. If the compromised account holds no permanent admin rights, this stage requires a second, noisier attack.

Read that chain again and notice where the money went. Most organisations have invested in stage one defences and stage five detection. The attack lives at stages two and three, which are usually owned by a service desk measured on call resolution time.

The second gap: tokens outlive authentication

Help desk compromise is the loud failure. Session token theft is the quiet one.

Adversary-in-the-middle toolkits — EvilProxy is the commonly cited example — sit between the user and the real service. The user visits what looks like the genuine login page, enters credentials, and approves a genuine MFA prompt. Everything succeeds, because everything is real. The proxy simply keeps a copy of the resulting session token.

From that point the attacker does not need the password or the second factor. They have the thing those were used to obtain.

This is the part of the problem passkeys do not solve. Phishing-resistant authentication — FIDO2 keys, passkeys, certificate-based auth — is genuinely excellent, and Microsoft reports that phishing-resistant MFA blocks over 99% of identity-based attacks. But it hardens the moment of authentication. A token stolen after a legitimate passkey login is just as usable as one stolen after a password login.

Two further traps are worth naming:

Fallback methods undo the upgrade. Organisations deploy passkeys and keep SMS or push as a backup for enrolment failures. Attackers simply steer the login flow to the weaker method. A phishing-resistant rollout with an unrestricted fallback is a phishing-resistant rollout in name.

Partial rollout leaves the valuable accounts behind. Administrators are frequently last to migrate, because their workflows are the most disruptive to change. This inverts the risk model precisely.

The third gap: the leaver signal dies downstream

1. 1

   HR records the termination

   Workday, ADP or the local equivalent holds the authoritative separation date. This part almost always works.

2. 2

   The identity platform disables the account

   Entra ID or Okta receives the signal, usually through an HR connector or a nightly sync. Also generally reliable, though nightly sync means a window measured in hours.

   Breaks here: Event-driven provisioning rather than scheduled sync, so the window is minutes.

3. 3

   Live sessions continue

   Disabling an account does not necessarily invalidate tokens already issued. A refresh token can outlive the account it belongs to.

   Breaks here: Explicit session and token revocation on termination — Okta's Universal Logout and equivalent revocation flows exist for exactly this.

4. 4

   Federated SaaS goes quiet, local accounts do not

   Anything behind single sign-on follows the identity platform. Anything with a local account — the legacy application, the vendor portal, the tool one team bought on a card — does not.

   Breaks here: An application inventory that distinguishes federated from local, maintained as a condition of procurement.

5. 5

   Derived credentials survive everything

   API keys, OAuth grants, personal access tokens and SSH keys created by that person keep working. They were never provisioned through the identity platform, so nothing about the termination reaches them.

   Breaks here: Ownership recorded at credential creation, so departure surfaces them for reassignment or revocation.

That last stage is where the real residual access lives, and it is the least instrumented. Industry surveys put the share of organisations with a formal process for revoking API keys at offboarding at around one in five, with fewer rotating them at all.

The practical test is uncomfortable and takes an afternoon: pick someone who left three months ago and try to find every credential they created. Not every account they held — every credential they created. The difference between those two lists is your exposure.

What stops what

Controls are usually sold as though each one closes the whole problem. They do not, and knowing where each stops is what makes a sequencing decision possible.

The tooling, concretely

You almost certainly own most of what you need. The named controls below exist on the platforms regulated organisations already run.

Microsoft Entra ID. Conditional Access is the policy engine; the two controls worth prioritising are authentication strength (to require phishing-resistant methods for administrators) and token protection, which binds a token to the device that obtained it so a stolen token cannot be replayed elsewhere. Privileged Identity Management provides just-in-time activation of directory and Azure roles with approval and expiry, which is how standing privilege actually goes away. Most of this sits in the P2 tier — check what you are licensed for before budgeting, because organisations routinely pay for P2 and deploy P1 features.

Okta. Identity Threat Protection evaluates session risk continuously rather than only at login, and Universal Logout terminates sessions and tokens across connected applications when risk rises — which is the control that matters for both token theft and termination. Okta Identity Governance covers access certification and lifecycle.

Privileged access platforms — CyberArk, BeyondTrust — remain the answer for shared infrastructure credentials, session recording and vaulting where the identity platform’s native capability stops.

Governance platforms — SailPoint, Saviynt — earn their cost when certification scope spans dozens of applications with conflicting role models. Below that, native governance in Entra or Okta usually suffices, and buying above your complexity is a common and expensive mistake.

What it actually takes

Sequenced by risk reduction per unit of effort, not by product category.

1. 1

   Harden account recovery

   1–2 weeks

   Identity proofing at reset that a caller cannot satisfy from public information: a callback to a number of record, verification through the manager, or a video check against an enrolled photo for privileged accounts. Alert on every MFA method change as a security event, and require a second approver for administrator resets. This is process and policy, not licensing.

2. 2

   Move administrators to phishing-resistant authentication

   3–4 weeks

   FIDO2 keys or platform passkeys for every account holding elevated rights, enforced through authentication strength policy — and with the weaker fallback methods disabled for those accounts, not merely deprioritised. Administrators first, then the wider population.

3. 3

   Turn on token protection and session revocation

   2–3 weeks

   Bind tokens to devices where your platform supports it, and make revocation an explicit step in the termination runbook rather than an assumed side effect of disabling the account. Test it: disable a test account and confirm the session actually dies.

4. 4

   Remove standing privilege

   4–6 weeks

   Just-in-time elevation with an approver, a short window and session recording. The reason previous attempts failed is that the compliant path was slower than the workaround, so make requesting access faster than holding it was.

5. 5

   Close the derived-credential gap

   2–4 weeks

   Record an owner at creation for API keys, tokens and SSH keys, and add credential reassignment to the leaver checklist. Start with anything that can reach production or regulated data.

6. 6

   Prove the leaver path end to end

   3–5 days

   Pick three people who left in the last quarter and trace every system, session and derived credential. Whatever you find is the real state of your lifecycle, and it is the artifact an examiner or auditor will ask for anyway.

Steps one and three are configuration and process. Step two is mostly logistics. Only step four is a genuine project, and it is the one most programmes start with — which is why so many stall before reaching the controls that would have mattered sooner.

The measurement that keeps this honest

One number, reviewed monthly, tells you whether any of this is working: how many accounts hold privileged access right now, without asking anyone.

Not how many privileged roles exist. Not how many are licensed. How many identities could, at this moment, perform an administrative action without a request, an approval or a time limit.

If that number is not falling, the programme is producing documents rather than change.

Where vaultIAM fits

Workforce identity is where most of our assessment weight sits for banking and healthcare clients, because it is where the largest gap between what is bought and what is enforced usually appears.

We assess read-only against the platforms you already run — Entra ID, Okta, CyberArk, and whatever the estate has accumulated — publish the query list before asking for access, and score ten weighted categories including standing privilege, authentication strength and the joiner-mover-leaver path. You get findings ranked by risk reduction per engineering hour, with a specific note on which controls you are already licensed for and not using.