How should organisations reduce the risk of vishing in identity workflows?

Why This Matters for Security Teams

Vishing succeeds when an identity workflow treats a voice call as proof of intent or authority. That is dangerous because social engineers do not need to break cryptography if they can persuade a help desk or finance operator to bypass it. Current guidance from the NIST Cybersecurity Framework 2.0 and NHI research from Ultimate Guide to NHIs both point to the same operational reality: identity controls fail when verification happens in the wrong channel. For NHI Management Group, the issue is not just fraud prevention. It is preventing a compromised conversation from becoming a privileged action across human and non-human identity workflows.

The risk is highest in reset, recovery, and approval paths, where urgency, authority cues, and exception handling often override normal checks. Teams also underestimate how often a vishing call is only the opening move before password reset, MFA enrolment, bank detail change, or payment approval. In practice, many security teams encounter misuse only after a convincing caller has already triggered an exception process, rather than through intentional testing of the workflow.

How It Works in Practice

The safest pattern is to separate the communication channel from the trust decision. A caller may open a request, but the approval must complete in a known portal, managed device, or verified callback path that the attacker cannot easily control. That means a help desk should never use the same inbound call to both authenticate the requester and approve the action. For identity-sensitive work, a second factor is not enough if it is delivered through the same compromised conversation.

Practitioners typically harden vishing-prone workflows by combining procedural controls with technical ones:

• Require step-up verification in a separate system of record for password resets, account recovery, and payment changes.
• Use pre-registered callback numbers or authenticated portal workflows instead of inbound voice approval.
• Apply just-in-time approval with explicit reason codes, ticket references, and dual control for high-risk changes.
• Record and review exception handling, because attackers often target the “temporary” path that bypasses normal policy.
• Train staff to treat urgency, secrecy, and authority claims as attack signals, not evidence.

Where NHI is involved, the same logic applies to secrets, service accounts, and automated approvals. The Ultimate Guide to NHIs shows how weak lifecycle discipline and poor visibility amplify compromise impact, while the 52 NHI Breaches Analysis is a reminder that identity failures often cascade once a single control is bypassed. In operational terms, vishing-resistant design means the person who hears the request should not be the person who can complete the change. These controls tend to break down when small teams rely on informal exception handling because the same operator is allowed to verify, approve, and execute the request.

Common Variations and Edge Cases

Tighter verification often increases friction, so organisations have to balance user experience against the blast radius of a mistaken approval. That tradeoff becomes acute in service desks, payroll, treasury, and executive support, where legitimate urgency is common and attackers exploit that culture. Best practice is evolving, but there is no universal standard for every environment yet.

Some workflows deserve stronger treatment than others. High-value transfers, MFA resets, and account recovery should use the strongest out-of-band checks available, while low-risk changes may use lighter verification if the business impact is limited and monitored. For remote or distributed workforces, callback-only controls can fail if contact data is stale, so identity proofing needs periodic refresh. For outsourced support, contract language matters because the same workflow may be executed by a third party with weaker training and poorer logging.

One practical guardrail is to treat voice as a notification channel, not a decision channel. That principle is especially important where attackers target executives, administrators, or privileged NHI operators who can bypass normal review paths. A mature programme also aligns with NHI and agentic governance patterns in the Why NHI Security Matters Now guidance and the OWASP NHI Top 10, because the same “trust the request, not the channel” failure shows up across human and machine identity workflows.

Related resources from NHI Mgmt Group

• Why do DNS failures create identity security risk for financial organisations?
• How should security teams reduce the risk of Scattered Spider-style identity compromise?
• How should organisations decide whether a high identity alert is real risk or routine activity?
• How should teams reduce the risk of exposed AI credentials being abused?