Attackers are increasingly targeting internal IT service desks because it is often easier to persuade a human than to defeat modern authentication controls. When the service desk can reset credentials or re-enroll MFA, it becomes a direct path to account takeover and downstream damage.

Gartner’s recent guidance, “Protect Your IT Service Desk Against Social Engineering Attacks”, is clear on the core issue: service desks remain vulnerable when they rely on weak validation (like security questions), ad hoc checks, or processes that agents can override under pressure.

This document outlines a practical approach Fischer Identity uses with customers to harden account recovery, including native self-service, native SMS/email one-time codes (OTP) where appropriate, and higher-assurance identity verification through our 1Kosmos integration, implemented in a way that reduces social engineering viability instead of shifting it around.

The trap: “Just add another factor” is not a service desk defense

Self-service password reset and additional authentication methods are helpful for genuine employees. But Gartner explicitly cautions that they do not mitigate social engineering risk at the service desk by themselves, because an attacker will always create a scenario where the user “cannot authenticate” (for example, “I lost my phone” or “my authenticator app is gone”).

So the goal is not “add more authentication.” The goal is:

• Shrink the attack surface (fewer accounts can be recovered via service desk)
• Verify identity when authentication is not possible
• Use contextual trust signals to assess risk
• Remove agent autonomy using application-level policies/workflows
• Increase visibility after recovery events

That is the frame this blog follows.

What Fischer Identity does, aligned to Gartner’s playbook

1) Shrink the attack surface (reduce who can recover via the service desk)

A high-impact move is limiting service desk recovery eligibility—especially for privileged and high-risk users. Gartner explicitly recommends reducing the number of accounts eligible for service-desk recovery and considering mandatory in-person recovery for high-risk populations where feasible.

How we implement this with customers:

• Define recovery tiers (standard workforce vs. high-impact roles vs. privileged IT/admin vs. executives)
• For high-risk tiers: restrict or prohibit remote service desk recovery, and route to in-person or specialized workflows
• Make the policy explicit and enforceable, so exceptions do not become the real process

2) Remove human autonomy with application-level policies and workflows

Gartner’s central control is to minimize social engineering opportunity by removing agent autonomy and enforcing recovery through application-level workflows that cannot be circumvented.

How Fischer Identity helps:

• We structure account recovery and MFA recovery as policy-driven workflows
• The workflow determines whether recovery can proceed—not the agent
• If verification fails or risk is too high, the workflow blocks recovery and routes to escalation

3) Address the most abused request: “My Duo MFA app isn’t working”

Gartner calls out that attackers often target MFA (re)enrollment and will fabricate “can’t authenticate” stories.

So we treat MFA help (e.g., Duo) as a high-risk recovery event, not a routine ticket.

What we offer natively:

• SMS OTP and/or email OTP as a policy-controlled step-up method for specific scenarios (for example, enabling a user to regain access long enough to repair or re-enroll MFA)

Important nuance (to stay aligned with Gartner):

• SMS/email OTP are “Basic” options in Gartner’s table, and they are useful for legitimate users.
• But they are not sufficient as a sole defense against social engineering because attackers will claim they cannot receive them (lost phone, broken device).

How we position SMS/email OTP correctly:

• Use SMS/email OTP as a controlled fallback for lower-risk users and lower-risk contexts
• Add guardrails (policy-based restrictions, throttling, and escalation triggers)
• For high-risk roles or suspicious context, do not rely on SMS/email—escalate to stronger verification (see next section)

4) Establish trust when the caller cannot authenticate: identity verification and verifiable credentials (1Kosmos)

Gartner’s recommended direction for the “can’t authenticate” problem is to verify the caller’s identity using automated identity verification or verifiable credentials—explicitly warning against “video call + hold up an ID,” which is slow, unreliable, and susceptible to deepfakes.

This is where Fischer Identity’s 1Kosmos integration fits cleanly into the model:

• When a user cannot authenticate (password reset, MFA re-enrollment, device change), the workflow can require stronger identity verification before the service desk action is allowed.
• This allows recovery to proceed without relying on agent “judgment.”

5) Evaluate contextual risk signals (and use them to force escalation)

Gartner recommends examining signals related to the caller’s phone number, device, and location—and using these signals to influence whether recovery proceeds or escalates.

Examples Gartner highlights include:

• Phone number intelligence (tenure, SIM age for SIM-swap detection, identity associated with number)
• Location intelligence via links and IP/GPS correlation
• Attacker-in-the-middle (AITM) detection, like links opened multiple times/forwarded

In the Fischer Identity operating model:

• Context signals are used to step up requirements (e.g., from SMS/email OTP → 1Kosmos verification → in-person/specialist)
• The workflow enforces the threshold so agents cannot override it

6) Improve visibility after recovery: treat it as a high-risk event

Gartner recommends a zero-trust posture after recovery: accounts that complete recovery should be placed under heightened scrutiny for 7–14 days, and failed/aborted recovery attempts should be tracked for reconnaissance patterns.

We align to that by helping customers:

• Log and report all recovery attempts (success and failure)
• Flag accounts that underwent recovery for enhanced monitoring windows
• Track spikes in failed recovery attempts across users as a potential campaign indicator

Reference workflow (Password or Duo MFA help)

• User attempts self-service first (reduce routine calls).
• If the user cannot proceed, the workflow routes to service desk with policy controls (agent does not “decide”).
• Workflow collects context signals (phone/location/link telemetry where applicable) and assesses risk.
• Based on risk + user tier:
  • Low-risk: allow SMS/email OTP to regain access and repair MFA
  • High-risk or suspicious: require 1Kosmos identity verification (or route to specialist/in-person)
• Only after verification passes and risk is below threshold, the workflow permits the recovery action.
• After recovery, the account enters a heightened scrutiny window and reporting.

How we measure success

Our success measures are practical and defensible:

• Decrease in successful social engineering attacks tied to service desk recovery
• Decrease in successful red-team simulated attacks
• No increase in average handle time for account recovery calls

We recommend customers adopt those three as the baseline, then add operational metrics (e.g., percent of recoveries handled via self-service, percent escalated to high-assurance flows).

Attackers target the service desk because it is often the easiest way to bypass strong authentication. The fix is not “ask different questions” or “add a factor.” The fix is to make recovery verifiable, risk-based, and enforced by policy—with strong identity verification available when authentication is not.

Sidebar: When SMS/email OTP is acceptable vs. when 1Kosmos is required

Gartner’s table places SMS-delivered OTP and email-delivered OTP in the “Basic” bucket for account-recovery workflows.
But Gartner also warns that authentication methods alone don’t defend against social engineering, because attackers will fabricate a “can’t authenticate” scenario (lost/broken phone, etc.).

So the decision isn’t “OTP or not”—it’s risk + role + context, with a hard step-up path that agents can’t bypass.

Risk signals that should force step-up:

• Phone number intelligence (tenure, SIM age/SIM swap risk, identity associated with number)
• Location intelligence (IP/GPS correlation vs expected location)
• Attacker-in-the-middle indicators (links forwarded/opened multiple times)

Critical “don’t do this”: avoid “video call + hold up ID” checks; often, helpdesk agents aren’t trained to validate all the various IDs and deepfakes (documents/videos) make this unreliable.