Bi-directional MFA: Defending Enterprises from IT Support, Help Desk, and MSP Impersonation.
How to verify IT is really IT before granting access; a guide for teams on Traceless's built-in bi-directional MFA verification strategies.
The Shift Attackers Made That Security Didn’t
For years, cybersecurity has focused on protecting systems. The cybersecurity industry built stronger authentication, layered defenses, and embraced Zero Trust architectures. And it worked against technical attacks.
But attackers adapted. Instead of breaking systems, they started joining conversations. This is the foundation of modern impersonation attacks, especially those targeting Managed Service Providers (MSPs), IT help desks, and internal teams.
It exposes a fundamental gap, MSPs can verify customers but customers have no way to verify the caller was legitimate:
1
Establish Context
Attacker sends a spam or phishing email, creating urgency or confusion.
2
Build Trust via Voice
Follows up with a phone call claiming to be Microsoft support, the Managed Service Provider (MSP), or a known vendor.
3
Lower Defenses
Uses urgent and helpful language: “We detected an issue and are here to fix this."
4
Gain Access
Requests credentials, pushes MFA approvals, installs remote tools.
What bi-directional MFA Actually Solves
MFA protects logins. Endpoint security protects devices. Zero Trust protects access pathways. But none of these systems protect communications. From recent Traceless product interviews, we learned that these attacks follow a remarkably consistent pattern but MSPs do not have systems in place to prevent this type of attack. Instead of employees passively trusting inbound requests, calls, emails, and messages, customers can actively verify identity before taking action. Traceless creates a two-way real-time trust layer for human interactions.
Traceless: Bringing Verification Into Every Interaction
Traceless includes built-in mechanisms that let your IT team prove their identity to end users before any access is granted eliminating the uncertainty that attackers rely on. When an employee receives a call from “IT,” they can verify the identity of the help desk technician in real time before taking action. Even internal peer-to-peer requests across departments like finance, HR, or engineering can be validated without slowing down workflows.
Ticketing system code
Before a technician contacts the end user, a 6-digit code is automatically sent to the user through the ticketing system. When the tech calls or emails, they provide this code and the user already has it waiting.
How it works
- IT opens or updates a ticket; a 6-digit code is generated and delivered to the end user
- The technician calls or emails the user as normal
- The technician reads the code aloud the user confirms it matches
- Trust is established before anything else happens
Push verification via authenticator
The technician triggers a push notification to the employee's Microsoft Authenticator or Traceless Passkey app. Receiving that push in real time, mid-call demonstrates the person on the line is an authorized Traceless user.
How it works
- Technician initiates contact and triggers a push via the Traceless platform
- Employee receives a push notification on their registered device
- Employee approves, confirming the technician's authorization
- Both parties proceed with verified trust
Train employees to watch for these red flags
1
No code or push notification arrives before or during the contact
2
The caller creates urgency and discourages verification ("we don't have time for that")
3
The caller asks the employee to read out a code or approve a push they didn't initiate
4
Contact comes through an unrecognized channel with no ticketing system reference