In April 2024, Cisco Duo sent notifications to affected customers describing an incident at one of its telephony providers. The provider, engaged by Duo to deliver SMS and voice-based multi-factor authentication messages, had been compromised through a phishing attack that exposed an employee's credentials. The attacker used that access to download message logs covering a specific window in March 2024. The logs contained phone numbers, carrier information, the content of some messages (including, in certain cases, MFA codes), and metadata about message delivery. No Duo systems were breached, and the attacker did not obtain access to authentication flows themselves.
The incident attracted attention for reasons that went beyond its direct impact. Cisco Duo is widely deployed as a primary MFA solution in enterprise environments, including in regulated industries and public-sector agencies. A compromise of a tier below Duo, a subcontractor whose existence was, from the customer's perspective, entirely transparent, raised the question of what the authentication supply chain actually looks like from end to end, and how deeply a customer can reasonably be expected to investigate.
What happened and what did not
The public disclosure is specific about scope. The compromised provider handled SMS and voice MFA delivery for Duo during the March 2024 window; the attacker obtained logs, not the ability to intercept future authentications. The logs were downloaded in bulk during the intrusion. Duo confirmed that its own systems, its authentication decisions, and its customers' directories were not affected. The incident was, in the narrow sense, a disclosure of historical data rather than an ongoing compromise.
In the broader sense, the disclosure surfaced several uncomfortable facts. First, the content of MFA messages, including the one-time codes themselves, was retained in provider logs for long enough to be stolen months later. Second, those logs included the phone numbers and, through correlation, the identities of users who had authenticated during the window. Third, the provider's own security posture, not just Duo's, determined the outcome. Fourth, the incident was detected and disclosed by the provider to Duo, who in turn disclosed to customers; the chain of notification took weeks.
None of these facts was specific to Duo. They are properties of the SMS and voice telephony market, where a small number of wholesale providers serve a much larger set of retail authentication platforms. The same facts would apply to any competing MFA vendor that relies on the same tier of telephony suppliers.
The depth of the authentication supply chain
A typical enterprise authentication flow, described at the level most security teams model it, involves three parties: the user, the identity provider (for example, Okta or Azure AD), and the MFA vendor (for example, Duo). In reality, the path that an SMS or voice MFA message travels has four to six additional hops. The MFA vendor holds a contract with a communications platform (Twilio, Vonage, or equivalent). The communications platform holds contracts with one or more upstream SMS aggregators, which in turn hold contracts with carriers, which in turn may deliver through SMSCs operated by third parties. Voice delivery involves a similar chain, possibly different for each geography.
Each link in the chain stores some metadata about the message. Some links store the content. Retention periods vary by jurisdiction and commercial agreement. At any given moment, an MFA code sent to a user's phone has been observed by a chain of intermediaries that the user, the enterprise IT team, and often even the MFA vendor's account manager cannot fully enumerate.
The Cisco Duo incident exposed the depth of this chain concretely. The "provider" mentioned in the disclosure was, in the usual terminology, a fourth party from the perspective of the enterprise customer: the enterprise contracts with Duo, Duo contracts with the telephony provider, the telephony provider contracts with upstream aggregators. Most enterprise third-party risk programs stop at the third-party boundary. Fourth-party visibility is aspirational.
What the incident teaches about MFA posture
The immediate defensive lesson is unsurprising: SMS and voice MFA are weaker factors than phishing-resistant alternatives. NIST deprecated SMS as an out-of-band authenticator for high-assurance use cases in 2016. FIDO2 and WebAuthn, and in some contexts push-based authentication with device binding, offer stronger properties. The Cisco Duo incident reinforces a position that was already established: enterprises relying primarily on SMS for their second factor are exposed to risks that are intrinsic to the telephony supply chain, not specific to any particular vendor.
The less obvious lesson involves retention. MFA codes are single-use and expire within minutes. There is no authentication-flow reason to store the content of an MFA message beyond the few seconds required to deliver it. Any retention beyond that is operational, for billing reconciliation, for debugging, or for regulatory reasons that vary by jurisdiction. The exposure of March 2024 MFA content in April 2024 reflects retention policies that were longer than the authentication flow required. Reducing retention to the minimum operationally feasible duration is a meaningful mitigation for any vendor in this part of the supply chain.
A third lesson involves segmentation. A telephony provider that handles messages for multiple customers, as this one did, becomes a concentrated target. The compromise of a single employee account yielded logs for multiple downstream customers. In principle, the provider's architecture could have segmented logs by customer, limited cross-customer retrieval, and imposed rate limits on bulk export. Whether any of these controls existed in the specific environment is not publicly documented, but the general pattern applies to any multi-tenant provider.
Four practical responses
Migrate away from SMS and voice MFA where possible. The strongest response to a class of incidents that depends on telephony provider security is to reduce dependence on telephony. FIDO2 hardware keys, platform authenticators, and push-based authentication with device binding are available in most modern MFA vendor products. Migration is operationally non-trivial but technically well understood.
Map fourth-party exposure for identity vendors. Identity and MFA vendors sit at a point in the supply chain where a single breach can compromise authentication for every downstream service. Customers should ask, during procurement and annually thereafter, which upstream providers their identity vendor relies on, what data those providers retain, and what the vendor's own incident response posture is with respect to fourth-party events.
Treat MFA logs as sensitive data. Message logs that contain MFA codes, recipient phone numbers, and timestamps are sensitive, even if they are not traditionally classified as such. Vendors and their subcontractors should minimize retention, encrypt at rest with customer-managed keys where feasible, and audit access with the same rigor as they audit production authentication systems.
Rehearse fourth-party incident response. The most common source of friction in fourth-party incidents is that the enterprise customer has no pre-established communication channel with the fourth party, no contractual right to investigate directly, and no rehearsed playbook. A few hours of tabletop rehearsal, walking through "our MFA vendor's telephony provider was breached, what do we do," saves days of confusion under pressure.
How Safeguard Helps
Safeguard maps vendor and sub-vendor relationships so that identity and authentication dependencies are visible beyond the first tier. Teams can record the MFA, identity, and telephony providers each application depends on, track their posture signals, and receive alerts when a relevant incident is disclosed upstream. When a vendor like Cisco Duo publishes a disclosure, Safeguard scopes affected applications by querying the identity integrations in use and flags the controls, secondary factors, session lifetimes, log retention, that should be reviewed first. The platform surfaces fourth-party exposures in procurement workflows, so the "who does your vendor depend on" question is answered before a contract is signed. The result is a continuously updated view of authentication supply chain depth rather than a point-in-time questionnaire.