Social Engineering Exposed (3/3): Defence That Works

Part one covered how these attacks work: the OSINT, the phone call, and why someone doing their job correctly can still hand an attacker access. Part two covered what a helpdesk reset looks like inside your Entra ID tenant, and why it gives an attacker a registered device rather than one session. This part covers what actually stops it.

The answer is not one setting. It is a combination of process and configuration. Each layer removes a step the attacker depends on. Together they make the attack significantly harder to execute.

Key Takeaways

• Replace KBA at your helpdesk with manager callback: the manager confirms the request, then receives the TAP via a verified channel and hands it to the employee directly
• Require compliant devices in Conditional Access on “Register security information”: blocks the attacker at the registration page before they reach the QR code
• Authentication Administrator is the role that enables MFA reset for non-privileged users; reduce who holds it to the minimum required and use PIM for just-in-time access

What should helpdesk verification look like?

The weakest point in most helpdesk processes is knowledge-based authentication (KBA). Asking for employee ID, date of birth, or a manager’s name tests knowledge that is publicly available or purchasable from breach databases. An attacker who has spent 20 minutes on LinkedIn and HaveIBeenPwned will pass most KBA checks.

The alternative is out-of-band verification: confirming the request through a channel that the caller cannot control.

Manager callback is the most practical method. Before any MFA reset, the helpdesk calls the user’s manager using a number already stored in your directory, not one provided by the caller. The manager confirms the request is legitimate. Only then does the helpdesk act.

The recovery step follows the same logic. The helpdesk issues a Temporary Access Pass (TAP): a time-limited, one-time code that allows the user to register a new authenticator. That code goes to the manager’s verified email or Teams message, not to the caller. The manager hands it to the employee directly. The attacker never receives it, even if they made the original call convincingly.

If the TAP goes to the caller instead, it provides no protection. An attacker who receives a TAP can use it to register their own authenticator, including a phishing-resistant method. The manager callback step is what makes the TAP secure. Without it, issuing a TAP is equivalent to a direct MFA reset.

Both steps in this procedure require Authentication Administrator: deleting the existing authentication method and issuing the TAP. That is exactly why this role should be restricted via PIM and activated only for the duration of a recovery procedure, with the justification logged. TAP requires Entra ID P1 or above and is configured under Protection > Authentication methods in the Entra admin center.

In practice, manager callback is the change that has the most impact for the least disruption. Most organisations can implement it without changing any technology. It just requires a clear policy that helpdesk operators are trained on and held to.

How does Conditional Access reduce blast radius?

Even if the helpdesk procedure is bypassed, Conditional Access can block the attacker before they complete registration.

Require compliant device on “Register security information”. In Conditional Access, under Target resources, select User actions and check “Register security information”. This applies the policy to the registration flow itself.

The way this works in practice: when a user opens the security info registration page, for example during a TAP-based recovery, Conditional Access evaluates the device running that browser session. If the device is not Intune-enrolled and compliant, the page is blocked. The user never reaches the QR code.

For a legitimate user completing recovery on a managed, Intune-enrolled device, this works without friction. The device passes the compliance check. The registration page loads. The user scans the QR code with their phone, personal or otherwise, and completes registration. The CA policy evaluated the managed device’s session, not the phone being registered.

For an attacker who obtained a TAP through social engineering, the outcome is different. They have no managed corporate device. They open the registration page from their own unmanaged device, hit the compliance check, and are blocked before the QR code is ever displayed.

To test this in your environment: create a Conditional Access policy scoped to all users, set Target resources to User actions > Register security information, and set the grant control to Require compliant device. Test with a non-enrolled device and a valid TAP. The registration page should not load.

Sign-in risk policy evaluates each login for anomalous signals: unfamiliar IP, anonymising proxy, known threat actor infrastructure, atypical travel. If the attacker logs in from a flagged source, the policy blocks access or forces additional verification.

The limitation: a prepared attacker using a clean residential proxy generates no risk signal. Sign-in risk is a supplementary layer. It catches careless and opportunistic attackers. It does not reliably stop someone who has prepared. Enable it, but do not treat it as the primary control for this attack.

How do you reduce who can reset MFA?

The built-in role that enables this attack is Authentication Administrator. It can delete authentication methods for any non-privileged user and requires no additional confirmation. In practice, this is the role IT assigns to helpdesk staff who handle MFA resets.

Start by auditing who holds this role. Go to Entra ID, Roles and administrators, and search for Authentication Administrator. Look at each account: is this a human or a service account? If human, do they actively need this role, or did it get assigned during a project and never removed? Are any of these vendor accounts from outsourced providers?

Reduce to the minimum required. Every account that holds the role should have a clear, active reason for doing so.

For the accounts that legitimately need this role, consider Privileged Identity Management (PIM). PIM requires Entra ID P2 or Microsoft 365 E5. It lets you configure the role as eligible rather than permanent: an operator activates it for a time-limited window when they need it, with a justification logged and optionally an approval step required.

PIM does not prevent a social engineering attack. An operator who is manipulated into performing a reset will activate the role as part of their normal process. What PIM adds is an audit trail: every activation is recorded with timestamp and justification, which matters for incident investigation. It also reduces standing access: if an attacker compromises an operator’s credentials without social engineering, the role is not active by default.

Where do you start?

Your helpdesk is a control surface. It has the same authority over who can access your environment as any Conditional Access policy. The changes below address that directly.

The changes with the highest impact, in order:

1. Add manager callback to your helpdesk process for MFA resets. No technology required. Takes an afternoon to document and communicate.

2. Audit Authentication Administrator role assignments in Entra ID. This is the role that enables MFA reset, not Helpdesk Administrator. Remove anyone who does not actively need it. Enable PIM for the remaining accounts if you have Entra ID P2 or Microsoft 365 E5.

3. Enable Conditional Access: require compliant device on “Register security information” if your devices are Intune-managed. In Target resources, select User actions and check “Register security information”. This blocks the attacker at the registration page before they can reach the QR code.

4. Configure Temporary Access Pass as the recovery mechanism within your manager callback process. The TAP goes to the manager’s verified channel, not to the caller.

These four changes cover the main steps of the helpdesk attack described in part two. None require new licenses beyond what Business Premium already includes.

Frequently Asked Questions

Is this attack only relevant for large organisations?

No. Scattered Spider targets large organisations, but the technique scales down. Smaller organisations often have fewer formal helpdesk processes, which makes verification easier to bypass. Any organisation where a phone call can result in an MFA reset is at risk, regardless of size.

Does enabling SSPR (Self-Service Password Reset) help or hurt?

It depends on configuration. SSPR with KBA-only verification creates the same problem at self-service level. SSPR configured to require an existing MFA factor for reset is safer, but still vulnerable if that MFA factor can itself be removed via helpdesk. Configure SSPR to require two methods for reset, and exclude phone call and security questions as valid methods.

What if we don’t have Business Premium or Entra ID P2?

Conditional Access, compliant device policies, and Entra ID audit logs are all available with Entra ID P1, which is included in Microsoft 365 Business Premium and E3. Sign-in risk policies (Identity Protection) are also included in Business Premium. PIM requires Entra ID P2 or Microsoft 365 E5. Manager callback has no licence requirement. TAP requires Entra ID P1. Start with what you have.

Should we enable number matching in Microsoft Authenticator?

Yes. Number matching requires the user to enter a number displayed during the login attempt, making silent MFA approval (push fatigue attacks) much harder. It does not help against a helpdesk reset attack, because the attacker will register their own authenticator after the reset. But it closes a separate, common attack vector and costs nothing to enable.

Where is the Temporary Access Pass configured?

In Entra ID, go to Protection > Authentication methods > Temporary Access Pass. Enable it for the users or groups that include your helpdesk support scope. Set a short lifetime (60 minutes is appropriate for most use cases) and configure it as one-time use only. Document the process for your helpdesk operators so it becomes the default recovery method.

The controls are already in your tenant

Parts one and two described an attack that requires no exploitation of a technical vulnerability. A phone call, 20 minutes of research, and a helpdesk process that was never designed to be tested.

Manager callback is a policy decision. TAP is a configuration change. Compliant device enforcement is a Conditional Access policy. None of these require a new license or a dedicated security team. They require the helpdesk process to be treated with the same rigour as the technical controls around it.

Read the full series: Part 1: How the attacks work · Part 2: The helpdesk attack