COMMENTARY: The
Talos 2025 Year in Review captures a number that should have prompted a flurry of SIEM rule updates, but didn’t. Fraudulent events associated with the registration of MFA devices grew 178% year over year. Attackers targeted admin-managed registration flows at a rate three times that of user-driven registration flows. A phone call. A pretext. An IT help desk agent is following the script. Ten minutes later, the attacker walked away with an active MFA device for an account they had never authenticated to.
In the last 11 weeks, three data points show this is no longer an edge case. The
New York Department of Financial Services issued a cybersecurity advisory on Feb. 6, 2026, identifying IT help-desk vishing as a reporting risk for regulated entities. On April 15,
SC Media reported that vishing attacks targeting Okta identity systems are pivoting “upstream” from individual user accounts to help desk workflows that create trust. And on April 19,
Vercel disclosed that a compromised third-party AI tool, Context.ai, had been granted broad Google Workspace OAuth permissions by a Vercel employee, giving attackers a foothold into internal systems.
Same pattern, three sources, same 11-week period. The attackers stopped fighting authentication and started manipulating enrollment instead.
The enrollment control plane
In my work reviewing enterprise identity architectures and contributing to IETF working groups on AI agent authorization, the same pattern keeps appearing: the strongest authentication layer is, in practice, limited by the weakest enrollment path beneath it.
Help desk vishing attacks work because the phone call acts as the authentication mechanism. The help desk agent verifies callers using LinkedIn, data broker records, or prior breaches. The attacker passes the human check. The agent acts according to policy. A new authenticator is enrolled. The SIEM sees a legitimate enrollment event from a legitimate admin account. There are no alerts.
The technical stack did exactly what it was supposed to do. That is the problem.
The enrollment control plane is not the login prompt. It is the set of workflows that decides which devices, OAuth applications, service accounts, and AI agents become trusted. MFA device registration, help desk resets, OAuth “Allow All” consent screens, agent registry entries, and MCP gateway onboarding. Each of these creates or modifies a trusted actor, and most organizations view them as IT support rather than privileged change management.
Phishing-resistant MFA does not fix this
In my discussions with CISOs, I am hearing increasingly often that phishing-resistant MFA, FIDO2 in particular, "solves the problem." The prescription is: implement WebAuthn with platform authenticators that require user verification via biometric factors, and the help desk reset workflow is cryptographically bound to the original device.
Phishing-resistant MFA does raise the bar at the authentication step, but none of those cryptographic guarantees survive an enrollment reset. In my experience auditing FIDO2 deployments, there is always a fallback enrollment path for lost devices, new employees, and legitimate hardware failures. That fallback path is always human-mediated. It is always a help desk. It is always the soft target.
Gartner’s
2025 cybersecurity forecast estimates that AI agents will reduce the time required to exploit account exposures by 50% by 2027. The attackers do not need to beat the authenticator. They need to beat the enrollment workflow that bootstraps it.
Human MFA enrollment and AI agent registration are the same problem
The
Vercel incident is the reference case. A Vercel employee granted Context.ai, a third-party AI tool that was later compromised, broad Google Workspace OAuth permissions. The OAuth token became the attacker’s foothold into Vercel’s internal systems. A threat actor later claimed to possess Vercel-related data and offered it for $2 million, though attribution and impact details remain disputed.
Human MFA enrollment and AI agent registration both pose the same architectural challenge. A process builds a trusted actor. If that process hinges on a help desk call, wide-ranging OAuth consent, or administrator approval without cryptographic proof of possession, the trust boundary is procedural rather than technical. The enrollment layer attack that help desk vishing perfected for humans will be the same attack pattern that compromises AI agents, because the architecture is the same.
What does not work
Increasing help desk training is beneficial, but it does not change the control plane. Attackers are winning, not because help desk staff are being negligent, but because the process allows a human conversation to create cryptographic trust.
Manager approval is useful, but urgent recovery workflows are built to bypass the delay. Lost phone, incident response access, shift handoff: enrollment requests are urgent by design.
Behavioral analytics is useful, but
CrowdStrike’s 2026 Global Threat Report shows the average breakout time is 29 minutes from initial access to lateral movement. If the first alert occurs after a new factor is used from a previously unencountered device, the attacker may already be past the identity boundary.
Four controls to implement this sprint
The first fix is not glamorous, but it is essential. You must document every pathway that can create trust, including help desk resets, SCIM provisioning, OAuth consent, an agent registry, the MCP gateway, and break-glass access. A team unable to describe every location where a new authenticator, credential, or agent identity can be created cannot manage enrollment.
Next, pose the difficult question: can any of those paths be completed with just a conversation? If so, that path is doing authentication by persuasion. A phone call should never be sufficient to create a new factor or to grant broad OAuth access. Instead, trust needs to come from something already trusted, such as an enrolled device, a managed recovery channel, or a hardware-backed factor.
For privileged accounts, add a short quarantine window. After a new authenticator, OAuth grant, or agent credential is created, block dangerous actions, such as privilege escalation, mailbox export, cloud key creation, production secret access, and large downloads, for a 30- to 60-minute quarantine period. If the request is legitimate, a second approver may release the hold. The delay does not need to be long, but it should be long enough to interrupt the attacker’s first move.
Finally, weave enrollment into authentication monitoring. If a new factor is followed by a login from a new device, a new IP address, a new ASN, or an impossible-travel pattern, someone should be paged. Most teams already monitor these events and fail to make the necessary connections.
The attacker’s goal isn’t necessarily always to steal the password, defeat the authenticator, or break the cryptography. Increasingly, the goal is to convince the organization to enroll an attacker-controlled trust object for them.
Enrollment is not an IT operations function. It is a privileged-access change. The same decision process that determines whether a help desk caller receives a new authenticator also decides whether an AI application receives broad OAuth access to your enterprise workspace. Both actions result in the creation of trusted actors. As a result, both should require proof of possession, approval separation, and post-enrollment quarantine.
Security teams have spent years hardening the login prompt. The next identity battle is one step upstream: who gets to become trusted in the first place.
