Notifications
Clear all
Topic starter
25/08/2026 6:10 pm
TL;DR: Social engineering has evolved from simple phishing emails to phone-based vishing and AI-powered impersonation, with attackers exploiting help desks, caller ID spoofing and cloned voices to bypass MFA and identity checks, according to Trusona. The defensive gap is no longer email hygiene alone, but trustworthy verification of the requester, device and access change request.
NHIMG editorial — based on content published by Trusona: The Evolution of Social Engineering: From Phishing to Vishing
Questions worth separating out
Q: How can help desks stop becoming the weak link in vishing attacks?
A: Make the help desk verify the request through a separate, pre-bound identity method before changing access or disclosing information.
Q: Why do phishing-resistant MFA controls still fail against social engineering?
A: Phishing-resistant MFA reduces token replay, but it does not automatically solve human verification failures.
Q: What do organisations get wrong about identity proofing in the service desk?
A: Many organisations assume the help desk can safely validate identity using employee facts that are easy to research or steal.
Practitioner guidance
- Harden identity proofing for all recovery paths Require government-ID checks, device verification and known-channel callbacks before any MFA reset or account recovery is approved.
- Remove discretionary help-desk approvals from sensitive resets Use scripted workflows for high-risk identity changes, including mandatory step-by-step verification and dual approval for privileged accounts.
- Apply zero trust to support interactions Verify the requester, the device, and the request context before granting any reset or privilege change.
What's in the full article
Trusona's full blog covers the operational detail this post intentionally leaves for the source:
- The step-by-step progression from early phishing to voice-based impersonation and AI-assisted cloning.
- The specific defensive patterns the vendor recommends for proofing, callbacks and scripted reset workflows.
- The examples of how generative AI changes the scale and realism of social-engineering attempts.
- The practical guidance for help-desk teams that need to tighten identity verification without stopping legitimate support.
👉 Read Trusona's analysis of phishing, vishing and AI-powered impersonation →
Vishing and AI impersonation: are help desks ready for the next wave?
Explore further
25/08/2026 6:11 pm
The real control boundary in social engineering is the identity workflow, not the inbox. Phishing has always been a user-behaviour problem, but vishing turns it into an IAM governance problem because the attacker targets reset paths, help-desk discretion and exception handling. That makes the access change process the true control surface. Practitioners should treat support workflows as part of the identity perimeter.
A few things that frame the scale:
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to The State of Secrets in AppSec.
- The average estimated time to remediate a leaked secret is 27 days, even though 75% of organisations express strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
A question worth separating out:
Q: Who is accountable when a social engineering call leads to SSO compromise?
A: Accountability is shared across identity operations, help desk governance, and security architecture. Teams that own resets, MFA recovery, browser telemetry, and identity monitoring all influence the outcome. Framework-wise, this sits under identity governance, access control, and incident response rather than only user training.
👉 Read our full editorial: Social engineering has shifted from phishing to vishing
