TL;DR: NYDFS warned that targeted vishing campaigns are using help desk impersonation, real-time credential capture, and MFA code theft to obtain remote access, while SlashID maps detection to identity telemetry and MITM controls. The real weakness is not MFA itself but the trust assumptions around reset, recovery, and login flows.
NHIMG editorial — based on content published by SlashID: NYDFS help desk vishing, MFA bypass, and identity protection
By the numbers:
- 80% of identity breaches involved compromised non-human identities such as service accounts and API keys.
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
- Only 5.7% of organisations have full visibility into their service accounts.
Questions worth separating out
Q: How should security teams stop help desk vishing from bypassing MFA?
A: Treat recovery, reset, and device enrolment as security controls, not support tasks.
Q: Why do MFA codes still fail against vishing attacks?
A: MFA codes fail when the attacker can harvest them in real time and replay them inside the valid session window.
Q: What breaks when password reset and device enrolment are not tightly controlled?
A: An attacker can convert a single successful social engineering call into a valid session, then extend that access through new device enrolment or federation artefacts.
Practitioner guidance
- Harden support-led recovery flows Require cryptographic proof of identity for password resets, MFA re-enrolment, and account recovery so a caller cannot authorise changes by conversation alone.
- Correlate reset-to-login sequences Alert on password reset followed by new device login, new MFA enrolment, or a fresh SSO session from a different geo or ASN within minutes.
- Block unauthorised proxy logins Use MITM detection to identify login pages accessed through non-approved domains, reverse proxies, or suspicious browser contexts before credentials are accepted.
What's in the full article
SlashID's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step mapping from NYDFS guidance to specific control areas across identity verification, MFA posture, and monitoring.
- SlashID's detection patterns for password reset, new device enrolment, and suspicious SSO session minting across identity sources.
- The mutual TOTP workflow for help desk verification, including the bidirectional handshake model and device-enforced proof steps.
- Browser extension and MITM token approaches for blocking malicious login portals and proxy-based phishing flows.
👉 Read SlashID's analysis of NYDFS help desk vishing and identity controls →
Vishing and MFA bypass: are your identity controls keeping up?
Explore further
Help desk vishing exposes a control gap, not a password problem: this attack works because organisations still treat recovery and reset workflows as administrative exceptions rather than first-class security controls. The attacker never has to defeat MFA at the cryptographic layer if a human can be persuaded to authorise the change on their behalf. The implication is that identity assurance now depends on verifying the verifier, not just the end user.
A few things that frame the scale:
- 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage, according to the Ultimate Guide to NHIs.
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
A question worth separating out:
Q: Who is accountable when a vishing attack leads to account takeover?
A: Accountability usually spans identity operations, service desk ownership, and security governance because the failure often sits in the recovery process, not the login prompt. Teams should review who approves resets, who audits enrolments, and who owns containment when a legitimate session is abused.
👉 Read our full editorial: NYDFS vishing attacks expose the limits of MFA on paper