MFA usage is at an all-time high in large organizations – 87% of companies with over 10,000 employees now use MFA in some form. This widespread adoption has significantly reduced compromises of unprotected accounts (Microsoft famously noted that 99.9% of hacked accounts lacked MFA). 

Yet, even as enterprises have broadly adopted MFA for their workforces, attackers are finding ways around it. They exploit processes around MFA, like enrollment and recovery, which often rely on human verification. Procedural weaknesses. A recent industry report highlighted that despite MFA being in place, 28% of users still face attacks through methods like SIM-jacking (SIM swap fraud), MFA “prompt bombing,” and adversary-in-the-middle (AiTM) schemes. Threat actors are actively probing the gaps that remain in MFA workflows. 

Protecting against threats to secure MFA enrollment, especially in large enterprise settings (2000+ employees), requires stronger identity verification and adaptive risk-based workflows. 

The weakest link in MFA enrollment 

One major gap is MFA enrollment and reset. This includes the initial setup of MFA for a user and the process to re-enroll or recover MFA when a device is lost or credentials need resetting. These stages often involve a helpdesk or self-service workflow to verify the user’s identity and issue a new factor. 

Attackers have realized that if they can socially engineer this step, they effectively bypass MFA entirely. Why bother cracking a one-time passcode or a FIDO security key, when you can call support and get them to turn off or transfer the factor? 

Unlike technical exploits, these “helpdesk hacks” exploit human trust. The criminals do their homework: they gather personal details of the target from corporate directories, social media, or past data breaches. Then they contact the IT service desk posing as that employee, often using urgent pretexts. A common ploy is claiming “I’m stuck late on a critical project and I’m locked out – I got a new phone and need my MFA reset ASAP.” Armed with personal info to answer security questions the attacker convinces the support agent that they are legitimate. 

The helpdesk, following routine, might reset the MFA authentication or enroll the “new device,” inadvertently letting an intruder in. Even the strongest MFA or passwordless login won’t help if an attacker can con an IT rep into enrolling the attacker’s device as a valid second factor. Social engineering bypasses multi-factor authentication by tricking support staff. Faced with a convincing plea – especially one that uses insider language, personal details, or pressure (“the CFO needs this now!”) – even well-intentioned staff can err on the side of customer service. Unfortunately, that lapse can be extremely costly for an organization. 

Helpdesk scams expose MFA’s Achilles’ heel in 2025 

Real-world incidents in the past year underscore how damaging this attack vector can be. A hacker group known as “Scattered Spider” launched a series of social engineering attacks targeting enterprise service desks at major UK retailers in 2025. They succeeded in duping IT helpdesks at companies like Marks & Spencer and others into resetting credentials and MFA protections, thereby gaining unauthorized internal access. The aftermath was severe: Britain’s Cyber Monitoring Centre estimated that these retail cyberattacks – enabled by helpdesk scams – cost between £270–440 million (about $360–590 million) in total damages. 

Across the pond, U.S. firms have learned similar lessons. The infamous MGM Resorts breach in late 2023 began with an attacker impersonating an employee in a call to IT support. By convincing the helpdesk to reset the employee’s MFA account, the hacker opened the door to the casino giant’s network and eventually deployed ransomware. The ease with which the intruder talked their way past MFA shocked many: it reportedly only a 10-minute phone call to compromise one of the world’s largest hospitality companies.  

These high-profile attacks highlight that MFA is not fail-safe if its enrollment or recovery can be subverted. Organized cybercriminals now actively target these processes. The UK’s National Cyber Security Centre and U.S. agencies like CISA have issued warnings about IT helpdesk social engineering campaigns. Security journalists have even termed it the “Achilles’ heel of MFA” – the notion that you can diligently enforce MFA for all users, yet a single support desk blunder can undermine it all. 

These developments raise the stakes for enterprises: the old ways of vetting users (knowledge questions like “mother’s maiden name?”, or trusting caller ID) are no longer sufficient. Attackers know that many organizations haven’t bolstered their enrollment and recovery workflows to the same level as their login processes. 

How identity verification strengthens MFA enrollment and reset workflows 

If the root problem is that helpdesk or enrollment processes are too easily tricked, the solution is to make identity verification more robust whenever MFA is set up or reset. In practice, this means moving beyond superficial checks (like providing personal data or one-time codes) and towards verification methods that are much harder for an impostor to spoof. 

Think about how high-assurance scenarios are handled: for example, issuing a passport or employee badge. You typically have to show a valid photo ID, maybe get your picture taken, or otherwise prove “something you are” or “something you have” that can’t be gleaned from a data breach. 

Enterprises are now bringing similar rigor to MFA enrollment. Before a new device can be enrolled as an MFA factor (or a factor reset), the user’s identity should be strongly authenticated. This could involve steps like: scanning a government-issued ID and matching it to the person’s selfie (to ensure a real live person and not a deepfake), verifying a trusted attribute (e.g. checking that the phone number or email truly belongs to that user in company records), or requiring a second staff member’s approval for high-risk changes. 

For example, if an employee calls IT for an MFA reset, the helpdesk might send a separate verification link or code to a pre-registered personal device or alternate contact method on file, rather than relying solely on the information provided over the phone. Simply put, you don’t fully trust the inbound caller – you double-check using a channel that the attacker hopefully can’t access. 

Just as important, MFA resets should not be too easy to perform. This might mean that certain high-privilege accounts can only have their MFA reset if the user physically shows up with ID at the IT office, or at least that a supervisor signs off on the request. While that might be inconvenient in some situations, it raises the bar significantly for attackers. A random scammer would have a hard time meeting that requirement, especially if they are operating remotely from another country. 

Risk-based enrollment workflows to detect fraudsters early 

Leading enterprises are also adopting risk reduction workflows around MFA enrollment. The idea is to use contextual signals and analytics to sniff out suspicious attempts before fully processing them.  

Not every MFA enrollment request is equal.  A user walking into IT with their corporate badge asking for help is very different from a late-night phone call from an offsite contractor you’ve never met. Layering in risk checks allows companies to dynamically adjust how an enrollment or reset is handled. Low-risk scenarios sail through with routine steps, while anything risky triggers additional safeguards (or is blocked entirely). 

What kind of risk signals make a difference? Here are a few examples that enterprises in 2025 are using: 

Device and network fingerprints: When someone initiates an MFA enrollment (especially via self-service portals), the system can examine the device and network they’re coming from.

Phone number and email reputation: Often, MFA involves a phone number (for SMS or voice calls) or an email for one-time links. These identifiers can be checked against fraud risk databases. 

Call center risk analytics: When MFA resets happen via call centers, specialized signals can be analyzed in real-time. Is the incoming call number spoofed (appearing as the employee’s number, but actually originating elsewhere)? Is the caller using a strange VoIP service or a voice changer (which might be detected by voice analytics)? 

These workflows reduce reliance on human judgment. Rather than expecting a helpdesk employee to play detective on every call (which is unrealistic at scale), the system automatically enforces verifications when elevated risk is detected. Essentially, even if someone has convinced an agent they are Alice from HR, the system says “OK, if you are Alice, prove it through this additional step.” A legitimate Alice will understand the precaution, while the attacker is likely to be unable to comply and will abandon the attempt. 

Orchestrating secure MFA enrollment with ID Dataweb 

Implementing the above might sound complex: how do you plug in identity document scans, carrier checks, device assessments, etc., into your existing IT environment without a monumental project? 

Platforms such as ID Dataweb provide a centralized way to design and enforce these MFA enrollment workflows across all your systems, without custom-coding each integration. With a visual policy builder, you can literally drag-and-drop steps like “Verify user’s ID with document scan” or “Call phone risk API” into the authentication/enrollment flow. ID Dataweb’s platform comes with a library of pre-built integrations – from various identity verification providers to fraud signal APIs – which makes this plug-and-play. 

One day you might use a built-in document verification; down the road you could swap in a new biometric service with minimal effort. This agility is crucial in 2025, because the threat landscape is constantly shifting. When a new type of attack emerges, you want the ability to adjust your MFA workflows in days, not months. 

ID Dataweb’s approach also emphasizes consistency and central control. A security team defines the verification requirements and risk thresholds once, and the platform enforces them uniformly across your enterprise apps. This prevents the scenario where one application or business unit has a weaker enrollment process than another. For example, you can ensure every MFA enrollment – whether for a VPN account, an HR system, or a cloud dashboard – goes through the same identity proofing steps and risk checks. No app is an outlier with “lax” rules, because the orchestrator routes all requests through the policy you’ve set. 

At the same time, orchestration helps balance security with user experience. Workflows can be adaptive, meaning low-risk enrollments don’t face unnecessary hurdles. The platform might integrate with your HR database or user context: if a user is new and just went through identity proofing during onboarding, the policy might skip doing it again for MFA setup, since trust was established minutes ago. But if a user is trying to enroll a new factor from an unknown device in a different country, the policy can step up and require fresh verification. 

It’s worth noting that enterprises of all sizes (including those 2,000+ employee companies with big helpdesks) are moving toward these orchestrated workflows. They not only dramatically improve security, but also can reduce support workload in the long run. Enabling secure self-service options (like letting users re-enroll MFA through a guided app that includes identity verification), enables companies to handle many requests without a live agent – and do it more securely than a phone call.