Workforce Identity Security: MFA, SSO and Help Desk Risk

Attackers rarely break in any more; they sign in, usually as one of your employees. Workforce identity security makes sure that the people who work for an organisation, and only those people, can authenticate to its systems, with access that matches their current role and ends when they leave. This guide covers the attacks on employee accounts, how MFA methods compare on phishing resistance, single sign-on, joiner-mover-leaver processes, help desk recovery, and where workforce identities create and own non-human identities.

Key takeaways

Not all MFA is equal. SMS, one-time codes and simple push approvals can be phished or socially engineered. FIDO2/WebAuthn (including passkeys) and PKI smart cards are the phishing-resistant options CISA and NIST recognise.
The identity provider is a crown-jewel system. Whoever controls it controls access to every federated application.
The help desk is an authentication channel. A reset granted over the phone bypasses every sign-in control, which is how several Scattered Spider intrusions began.
Deprovisioning means more than disabling an account. Leavers must also lose sessions, refresh tokens, OAuth grants and personal access tokens, and their service accounts need new owners.
Workforce identity and NHI security overlap. Employees create tokens, approve OAuth apps and own service accounts, so a compromised human often becomes a compromised machine identity.

What workforce identity security covers

Workforce identity covers the people an organisation employs or engages: staff, contractors, temporary workers, partners with delegated access and, most sensitive of all, administrators. It is distinct from customer identity (CIAM) and from non-human identities such as service accounts, API keys and workloads, which cannot answer an MFA prompt at all. The practical differences between the two families are set out in our Human vs Non-Human Identity guide.

A workforce identity programme spans authentication policy, single sign-on through a central identity provider (IdP), joiner-mover-leaver lifecycle and provisioning, account recovery and support, and extra controls for privileged users. Each is an entry point. Most workforce breaches do not defeat cryptography; they exploit a weak method, a generous session, a stale account or a helpful support agent.

The main attack paths against employee accounts

Credential phishing and adversary-in-the-middle

Adversary-in-the-middle (AitM) phishing relays traffic from a fake login page to the real IdP in real time, so the victim completes their genuine MFA challenge and the attacker captures the resulting session cookie. Any method where the user types a code, or approves a prompt without the authenticator checking which site is asking, can be relayed. CISA’s Scattered Spider advisory describes look-alike domains combining the victim’s name and “sso”.

MFA fatigue and push bombing

With a password in hand, an attacker can send repeated push prompts until the user approves one, or phone the user posing as IT and ask them to accept it. The Storm-2949 campaign followed this pattern: callers persuaded employees to approve MFA prompts, then reset passwords, removed the existing methods and enrolled their own device as a trusted authenticator, locking the real user out.

SIM swap

An attacker who persuades a mobile carrier to move the victim’s number to their own SIM receives every SMS or voice code. CISA cites SIM swap, phishing and SS7 weaknesses as reasons to treat SMS and voice only as a temporary measure.

Help desk social engineering

Rather than defeat MFA, the attacker asks for it to be removed, calling the service desk as an employee with researched personal details. The MGM Resorts breach, the Caesars Entertainment breach and the Co-op Group breach all began with a help desk reset that relied on knowledge-based verification the attackers could research.

Session and token theft

After sign-in, applications trust the session cookie or token. Infostealer malware, or files that capture browser traffic, can hand it to an attacker who skips authentication entirely. In the CircleCI breach, malware on an engineer’s laptop stole a session that had already passed two-factor authentication, and in the Okta support system breach, attackers took cookies and session tokens from HAR files uploaded to support cases and used them to impersonate users.

Password spraying and credential stuffing

Spraying tries a few common passwords against many accounts to stay under lockout thresholds; stuffing replays leaked credentials. Both succeed against accounts without MFA, usually forgotten ones. The Microsoft Midnight Blizzard breach started with a password spray against a legacy, non-production test tenant account that had no MFA, and in the Snowflake customer breaches infostealer-harvested credentials worked against demo accounts that were not protected by MFA.

Authentication: comparing MFA methods

The most useful question to ask of any method is: if a user is tricked into using it on an attacker’s site, does the attacker gain anything? For most methods, yes.

What “phishing-resistant” means

CISA’s Implementing Phishing-Resistant MFA fact sheet calls phishing-resistant MFA the gold standard and names two forms: FIDO/WebAuthn authentication, which it describes as the only widely available phishing-resistant option, and PKI-based MFA such as smart cards. The underlying property is that the authenticator cryptographically binds its response to the genuine relying party, so a response produced for a look-alike site is useless. In W3C Web Authentication, a credential can only be used with the relying party ID it was registered for, which is checked against the site’s origin, so a user cannot hand a valid response to a look-alike domain.

NIST SP 800-63B-4 treats passwords, look-up secrets, one-time passwords and SMS or voice codes as not phishing resistant. It requires verifiers to offer at least one phishing-resistant option at authenticator assurance level 2 (AAL2), requires phishing resistance at AAL3, and states that federal agencies shall require their staff, contractors and partners to use phishing-resistant authentication: a useful benchmark for any workforce.

Method	How it works	Phishing resistant?	Main weaknesses	Where it fits
SMS or voice code	Code sent over the phone network, typed in by the user	No	AitM relay, SIM swap, SS7; NIST classes PSTN delivery as “restricted”	Temporary fallback only
TOTP authenticator app	Time-based code from a shared seed, typed in by the user	No	Code can be phished and replayed while valid	Low-risk access during migration
Simple push approval	App shows “Approve sign-in?” and the user taps yes	No	Push bombing; user cannot tell which session they approved	Avoid
Push with number matching	User types a number shown on the sign-in screen into the app	No	Stops blind approval, but an AitM page can show the victim the number	CISA’s interim step before phishing-resistant MFA
FIDO2/WebAuthn (security keys, platform authenticators, passkeys)	Public-key challenge-response scoped to the site’s relying party ID	Yes	Recovery and enrolment become the weak point	Default for all staff; device-bound keys for administrators
Smart card / PIV (PKI-based)	Certificate and private key on a card, unlocked with a PIN	Yes	Needs mature PKI; narrower application support	Organisations already running PKI

NIST SP 800-63B-4 no longer accepts out-of-band methods where the user merely compares two displayed values and approves, because fatigue attacks make careless approval likely, and it recommends limiting the rate or total number of push notifications since the last successful authentication. Number matching is an improvement on simple push, not a destination.

Passkeys: synced and device-bound

The FIDO Alliance defines a passkey as a FIDO credential that lets a user sign in with the same gesture they use to unlock their device: a biometric, PIN or pattern. It distinguishes two kinds:

Synced passkeys are backed up and synchronised across a user’s devices through a cloud service, so they survive a lost phone.
Device-bound passkeys never leave a single device, for example a hardware security key, and give stronger assurance that the user holds a specific authenticator.

WebAuthn exposes the difference through authenticator data flags: a credential is either backup eligible (a “multi-device credential”) or not (a “single-device credential”), and a separate flag reports whether it is currently backed up, so relying parties can apply different policy. NIST SP 800-63B-4 calls synced credentials “syncable authenticators” and states they shall not be used at AAL3, which requires a non-exportable private key. In practice, synced passkeys are a large improvement for general staff, but administrators should use device-bound authenticators, and the account that holds synced passkeys becomes part of your attack surface.

SSO and federation: the IdP as a crown jewel

Single sign-on concentrates authentication in one place. The user signs in to the identity provider, and the IdP vouches for them to each application using a federation protocol:

SAML 2.0 uses signed XML assertions passed through the browser, and remains common in enterprise applications.
OpenID Connect is an identity layer on top of OAuth 2.0. OpenID Connect Core defines the ID Token, a signed JSON Web Token containing claims about the authentication of the user, including issuer, subject, audience and expiry. Applications must validate those claims rather than simply accept any token.

Concentration is the point, and the risk. Phishing-resistant MFA enforced once at the IdP protects every connected application, but compromising the IdP, or an administrator of it, opens them all. The MGM and Caesars write-ups both describe attackers using the reset account to reach the SSO environment and move on. CISA’s advisory also describes Scattered Spider adding a federated identity provider to a victim’s SSO tenant with automatic account linking, a persistence technique that works only if federation changes go unnoticed. Treat IdP configuration, federation trusts, MFA policy and administrator roles as tier-zero assets: few administrators, reviewed changes and alerting.

Session lifetimes and token theft

Strong authentication protects the moment of sign-in; the session protects everything after it. NIST SP 800-63B-4 gives reauthentication guidance per assurance level: at AAL2 the overall session should last no more than 24 hours with an inactivity timeout of no more than one hour, and at AAL3 the overall limit is 12 hours with an inactivity timeout that should be no more than 15 minutes. The OWASP Session Management Cheat Sheet adds server-enforced idle and absolute timeouts, session identifiers regenerated after authentication, and cookies marked Secure, HttpOnly and SameSite.

Phishing-resistant MFA does not help once a post-authentication cookie is copied, so reduce its value: require reauthentication for sensitive actions such as changing MFA methods, keep refresh tokens short-lived for high-risk applications, alert when a session appears from a new device or network, and harden endpoints against infostealers. Where supported, the OpenID Continuous Access Evaluation Profile (CAEP) lets an IdP and applications exchange events such as “session revoked” and “credential change”, so a revocation in one place can end sessions elsewhere rather than waiting for them to expire.

Joiner-mover-leaver: provisioning and deprovisioning

Lifecycle processes decide how long an identity exists and what it can reach. They should be driven from an authoritative source, typically HR for employees and a sponsor or contract record for contractors. Our IAM and IGA Basics guide covers the governance model; the security essentials are below.

Joiners

Create accounts from the authoritative source, not from tickets, and grant access through role-based birthright bundles plus approved requests. Make enrolment of a phishing-resistant authenticator part of onboarding, backed by an in-person or strong remote identity check, so a temporary password or SMS code never becomes the account’s lasting weak point.

Movers

Role changes are where access drift accumulates: the new role’s access is added and the old one rarely removed, so long-serving staff hold the union of every job they have done. Treat a move as leaver-plus-joiner for entitlements: recalculate birthright access, remove what no longer applies after a short overlap, and confirm exceptions at the next access review.

Leavers

Disabling the directory account is necessary but not sufficient. A complete leaver process also revokes active IdP sessions and refresh tokens; deprovisions downstream accounts, including local ones outside SSO; revokes the user’s OAuth grants, personal access tokens and API keys; removes enrolled authenticators; and reassigns any service accounts or automation the person owned. Speed matters most for involuntary departures and for contractors, whose end dates are often held outside HR systems.

SCIM for automated provisioning

The System for Cross-domain Identity Management is the standard way for an IdP to manage accounts in SaaS applications. RFC 7644 defines the HTTP protocol (create with POST, replace with PUT, partial updates with PATCH, remove with DELETE) and RFC 7643 defines the core schema. Note one subtlety: RFC 7643 defines the User active attribute as a Boolean for administrative status whose definitive meaning is determined by the service provider. Setting active to false may suspend sign-in in one application and do much less in another, and neither SCIM operation is guaranteed to end sessions or revoke tokens the application has already issued. Test what deprovisioning actually does in each application, and give applications without SCIM an owned manual process.

Help desk resets and account recovery

If an employee who has “lost their phone” can obtain a new password and MFA enrolment by quoting their employee number and date of birth, your MFA is only as strong as those questions. The Scattered Spider write-ups above show this is not theoretical, and the Meta AI support chatbot account takeovers show the same failure when recovery is automated: a support bot sent verification codes to an attacker-supplied email address and then allowed password resets, with no binding to the account’s registered contact details.

Designing identity verification for resets

Drop knowledge-based verification. Employee ID, manager name and date of birth can be found or bought.
Prefer self-service recovery with a strong factor. A user with a second registered FIDO authenticator or a stored recovery code should not need to call anyone; NIST SP 800-63B-4 lists saved and issued recovery codes among its recovery options.
For assisted resets, verify with something the caller cannot research: a live video check against photo ID on file, in-person verification, or manager confirmation through a separate authenticated channel. Never use a callback number the caller supplies.
Separate password resets from MFA re-enrolment. Replacing the authenticator is the higher-risk action and deserves the stronger check.
Route privileged accounts to a restricted team with a documented procedure, never a first-line agent.
Notify and hold. Tell the user through an existing channel whenever a reset or enrolment happens, and briefly restrict sensitive actions afterwards.
Back your agents. Urgency and seniority are not grounds to skip a step; refusing a caller who fails verification is the correct outcome.

Alert on an MFA method removed and a new one added within minutes, a reset followed by sign-in from an unfamiliar device, or several resets for the same team.

Risk-based access, step-up and device trust

Authentication strength should follow risk. Identity platforms can weigh signals such as device, network, location, usual behaviour and leaked credentials, then allow, block or demand more.

Step-up authentication asks for a stronger or fresher factor before a sensitive action: approving a payment, exporting data, changing security settings or elevating to an administrative role. The OWASP Authentication Cheat Sheet recommends reauthentication before changes such as passwords or email addresses.
Device trust checks that the request comes from a known, managed, compliant device, typically via a device certificate or management enrolment. An attacker replaying a stolen cookie from their own machine fails that check.
Risk signals are inputs, not guarantees. The Midnight Blizzard write-up describes attackers using residential proxy networks to blend in. Use risk scoring to add friction, not to waive strong authentication for “low-risk” sign-ins.

Administrators and privileged users

Administrators of the IdP, directory and cloud control planes need more than general staff controls. Give each a separate privileged account that is not used for email or browsing, require device-bound phishing-resistant authenticators for it, grant elevated roles just in time rather than permanently, and run it from a hardened, managed workstation. Keep a small number of break-glass accounts with strong offline credentials and alerting on every use. The Privileged Access Management Guide covers vaulting, session recording and just-in-time elevation. Storm-2949 targeted IT staff and leaders with broad Azure permissions: privileged roles must never rest on a factor that can be reset by phone.

Where workforce identity meets non-human identities

Different teams often run workforce and non-human identity; attackers move between them freely.

Users granting OAuth access to third-party apps

When an employee clicks “Allow” on a consent screen, they create a standing, delegated machine credential: the app receives tokens that act as that user, often including refresh tokens. In the Vercel Context.ai breach, an employee connected an unapproved AI assistant to their workplace account with broad permissions; tokens stored by the vendor were later stolen and used against the organisation. Consent phishing turns this into an attack in its own right: the Microsoft OAuth consent phishing campaign used apps from compromised “verified” partner accounts, and the CoPhish technique hosted malicious consent flows in Copilot Studio agents on legitimate Microsoft domains. None needs the user’s password. Restrict user consent, require administrator approval for broad scopes, and review grants regularly.

Personal access tokens and scripts

Developers and administrators create personal access tokens and API keys that act as themselves, then paste them into scripts and CI variables. Such tokens are typically presented without an interactive MFA step, and unless explicitly revoked they can outlive a password reset or even offboarding. The Uber breach shows the escalation path: after social engineering gave attackers network access, they found PowerShell scripts with hard-coded administrator credentials for the privileged access system. Prefer short-lived, identity-based credentials for automation (see the NHI Authentication Guide), set expiry on personal tokens, and scan scripts for embedded credentials.

Humans who own service accounts

Service accounts and application registrations are typically created by a person and quietly depend on them. When that person leaves, the NHI becomes orphaned: still active and privileged, with no one to rotate or retire it. The NHI Lifecycle Management Guide recommends mapping NHIs to an application or service, which has its own owners, rather than to an individual, so ownership survives staff changes. Leaver and mover processes should list and reassign every NHI the person owns.

Compromised humans reaching machine identities

The Storm-2949 write-up describes the attacker using Microsoft Graph to enumerate users, applications and service principals, then reaching Key Vault and other Azure resources; the Midnight Blizzard write-up describes OAuth applications used to escalate privileges and reach mailboxes. Workforce identity controls are therefore NHI controls too: an employee who can create app credentials or read a secrets store is a path to every machine identity behind it.

Practitioner checklist

Inventory every workforce population (employees, contractors, partners, administrators) and its authoritative source.
Roll out FIDO2/WebAuthn or PKI-based MFA to all staff, with device-bound authenticators for administrators.
Retire SMS and voice; use number matching with push limits only as an interim step.
Cover every account with MFA policy, including test, legacy and non-production tenants.
Treat the IdP, federation trusts and MFA policy as tier-zero, with alerting on changes.
Set session and refresh-token lifetimes by risk, require reauthentication for sensitive actions, and use device trust to limit cookie replay.
Drive joiner-mover-leaver from HR and contract data, provision with SCIM where supported, and test what deprovisioning actually revokes in each application.
On leaving, revoke sessions, refresh tokens, OAuth grants, personal access tokens and authenticators, and reassign owned NHIs.
Remove knowledge-based verification from help desk resets; use strong self-service recovery or verified, out-of-band checks, with stricter handling for privileged users.
Alert on MFA method removal followed by new enrolment, resets followed by unusual sign-ins, and bursts of reset requests.
Restrict user consent to third-party OAuth apps and review existing grants.
Scan scripts and repositories for personal tokens and hard-coded credentials, and set expiry on every token users create.

Workforce Identity Security Guide