The Cisco Duo telephony-supplier incident is prevention math, not theater. According to BleepingComputer on 15 April 2024, a threat actor phished credentials of an employee at an unnamed North American supplier that sent Duo multifactor authentication over SMS and VoIP, then downloaded MFA message-log metadata for traffic roughly from 1 March to 31 March 2024. Cisco assessed about 1% of Duo customers were impacted. The provider said message contents were not accessed and the access was not used to send messages. Phishing-proof device-bound MFA that never delivers codes by SMS or voice removes that supplier log path for those factors. Customer-side MFA does not rewrite a completed supplier workforce phishing attack. For the full attack chain and disclosure timeline, read the companion on legacymfa.sucks.
FAQ
Would phishing-proof MFA have stopped the Duo SMS supplier log exposure?
Phishing-proof MFA stops this class of exposure for identities that never receive MFA over SMS or voice, because there is no telephony supplier holding phone numbers, carriers, timing, location-related fields, and message-type metadata for those factors. It does not undo logs already downloaded after a completed supplier breach. On the initial-access phase, phishing-proof MFA at the supplier workforce login would have blocked remote reuse of a stolen password alone. Public reporting does not document the provider’s MFA type. Cisco Duo customer MFA, including any customer move to device-bound keys, does not sit on that supplier login path and cannot rewrite it.
How does dropping SMS and voice MFA remove the telephony log surface?
SMS and voice MFA force a third party to route messages and retain delivery metadata outside the enterprise IdP. In the Duo case, stolen fields included phone number, carrier, location data, date, time, and message type for specific Duo accounts in the March 2024 window. A device-bound architecture that authenticates with origin-bound hardware signatures never places a transferable code on that wire, so that supplier dependency disappears for users on the phishing-proof path. Prevention, not detection, is the point: you do not monitor telephony logs you no longer create.
Can enterprise or Duo-customer MFA 2.0 fix a supplier employee phishing attack?
No. Enterprise or Duo-customer MFA 2.0 does not fix phishing of an employee at Duo’s telephony provider. The documented credential-phase failure was supplier workforce access on or about 1 April 2024, then a download of SMS and VoIP MFA delivery logs. Closing phishable factors at your IdP hardens your login and recovery. It does not police a vendor’s employee password. Require suppliers that still touch identity delivery to run phishing-proof workforce authentication themselves, and stop buying factors that require those suppliers when you can avoid them.
What remains after SMS MFA metadata is already stolen?
What remains is residual reconnaissance risk, not a second MFA prompt you can magically re-run. Cisco warned that the metadata could fuel targeted SMS phishing and social engineering. Related coverage of residual SMS MFA risk points to cases like Uber 2022, where attackers who already knew how to reach an employee phone path used social engineering against MFA. MFA cannot recall logs already taken. Revoke and customer notice are hygiene for the incident that happened. Going forward, removing SMS and voice factors stops new metadata of this class from existing. Malware on an already-logged-in PC is a harder, separate problem and was not the documented path here.
Are passkeys enough if some users still get SMS MFA?
No. Passkeys are phishing-resistant at the login ceremony. If any cohort still receives SMS or voice codes for authentication, recovery, or step-up, that cohort still feeds a telephony supplier log surface like the one Duo disclosed. MFA 2.0 is phishing-proof across the identity lifecycle only when no phishable factor appears at registration, device onboarding, authorization, authentication, or decommissioning. Partial passkey rollout with SMS still in the mix leaves the supplier path open for whoever remains on the phone channel. Public reporting does not establish that Duo customer OTP bodies were exposed; the prevention claim is still to stop creating the metadata channel at all.
