Request a demo

The sign-in page was real. The caller wasn't.

A request to update a passkey can be the pretext for device-code phishing. A real sign-in page does not verify the IT caller.

By Fctr Identity 3 minute read

The dangerous part of device-code vishing is that the employee may see Microsoft's real sign-in page and complete a real authentication flow. The mistake is trusting the person who told them to do it.

How does Microsoft device code phishing work?

ReliaQuest documented a July 2026 campaign in which a caller impersonated an employee's manager and walked the employee through entering a device code. The employee did not share a password, but the completed flow gave the attacker an authenticated session that was followed by MFA registration and SharePoint access.

The attacker starts the device authorization request. The employee opens Microsoft's expected destination, enters the supplied code, and authenticates. The resulting session goes to the attacker.

Huntress reports a 1,380% increase in device-code phishing activity when comparing July–December 2025 with January–April 2026 in its SOC telemetry. Microsoft and Proofpoint have also documented growing automation and criminal tooling around the technique.

Passkey-themed vishing starts with a fake IT call

In its September 9 advisory, Microsoft describes callers posing as IT and pressuring employees to update passkeys, MFA, or single sign-on settings. The supposed security update is the lure, not necessarily the attacker's real objective.

One observed sequence used device-code authorization: the employee entered a code on Microsoft's legitimate authentication page, issuing a token to an attacker-controlled client. Other sequences used phishing pages to intercept sign-ins. Microsoft also observed attackers adding their own authentication methods after gaining access and collecting cloud data.

The support request deserves scrutiny before the employee reaches the sign-in page. A request framed as improving security still needs a verified caller behind it.

Passkeys are not the problem

We should be precise about the control failure. Passkeys remain a significant improvement over passwords and phishable one-time codes. The problem is not weak passkey cryptography.

Authentication proves that the employee exercised an authenticator for the account and relying party. It does not prove that the person directing the employee on the phone is an authorized support representative. An employee can strongly authenticate the wrong session because they trusted the wrong person.

Verify the IT support caller before entering a device code

Organizations should block device-code authentication unless there is an explicit business need, protect authentication-method registration, and monitor unusual sign-ins and MFA changes. After a confirmed compromise, revoke sessions and remove unauthorized authentication methods. Caller verification does not replace those controls.

Our view is simple: an employee should not complete a sensitive sign-in, enrollment, or recovery step just because someone on the phone sounds like IT.

Use a known company support or verification destination, rather than relying on a link or phone number supplied by the caller. Check the caller through the organization's approved process before acting. A valid sign-in page does not establish that the request is legitimate.

That is why Fctr verifies callers in both directions. An employee can verify someone claiming to be IT before following security instructions. When an employee calls the helpdesk, the helpdesk can verify that employee before a supported unlock, reset, recovery, or other sensitive action becomes available under the organization's role and policy controls.

Strong authentication should remain in place. Risky sign-in flows should be constrained. But the human giving the instruction also has to be verified.

See how Fctr verifies IT support callers before employees follow sensitive instructions.

Sources