Inside the Twilio Authy Breach: What Happened, What Did Not, and What It Means for SMS Trust

Alright, so that Twilio Authy thing back in July 2024? On the surface, it didn't look like a total disaster. I mean, no passwords got out. No one swiped the secret codes for your two-factor authentication. And sure, thirty-three million phone numbers is a big number, but honestly, we've seen WAY worse data dumps this year, right?

But here's the thing: in the months since, we've seen that Authy data pop up in all sorts of nasty attacks. Why? Because a phone number paired with a known MFA app isn't just a contact. It's a flashing neon sign that says, "Hey! This person uses two-factor authentication! They probably have accounts worth stealing!" Throw that in with all the other email addresses and reused passwords floating around from old breaches, and that Authy list became a sniper's guide for smishing campaigns, specifically targeting folks susceptible to MFA fatigue.

What the Breach Actually Exposed

Okay, let's break down what actually happened. The bad guys found an API endpoint, basically a digital doorway, that didn't ask for a key. They could just walk right in and see if a given phone number was registered with Authy. So, they started hammering it, trying out big blocks of phone numbers, and built themselves a nice list of confirmed Authy users. That list? Yeah, it ended up on one of those dark web forums.

Twilio, to their credit, handled the disclosure pretty cleanly and patched that doorway up fast. Good on them for that.

Now, what *didn't* get out is just as important. The actual TOTP secrets that Authy uses? Safe and sound. Your login credentials? Not touched. It was just the phone number, and the fact that you used Authy. If you're not in the security world, that might sound like small potatoes. But if you're plotting an SMS-based attack, that information is a massive leg up.

The Downstream Pattern We Have Watled Develop

It didn't take long. Within weeks, our partners started seeing smishing campaigns pop up in their detection feeds, using that Authy list. These weren't your run-of-the-mill, poorly-written scam texts. These were tailored. They'd mention specific services the target probably used, push them to fake login pages, and sometimes, those texts would be followed up by a phone call from someone saying, "This is your bank, calling to confirm the alert we just sent."

What made these campaigns so much more effective than the usual garbage? The precision. A random SMS phishing campaign might get a tiny fraction of people to click. But when you're hitting confirmed MFA users, and you mention a service they actually use, that conversion rate shoots way up. That bump is big enough to justify the bad guys spending a lot more time and effort on each target. That's why you saw longer conversations, better English, and those slick handoffs to voice calls.

Why SMS Remains the Soft Spot

Look, the deeper lesson from this Authy whole mess is that SMS, bless its heart, is doing two jobs that really shouldn't be the same job. It's delivering those one-time codes for authentication, and it's also a general communication channel for marketing or customer service. Those two things? Totally different security requirements, totally different risks. And honestly, as an industry, we haven't bothered to separate them.

When an attacker has your confirmed phone number, the SMS channel becomes a super easy way to mess with the person on the other end. They don't need to break the fancy crypto stuff behind TOTP. They just need to trick you into typing that code into the wrong box. You can have the strongest second factor on Earth, but it's useless if you've been talked into giving an attacker access to your session.

The Conversation Enterprise Teams Should Be Having

So, if your organization uses SMS for two-factor authentication, the right move after the Authy breach isn't to suddenly freak out and switch everything to app-based MFA overnight. The smart play is to actually look at where SMS is doing double duty, and then ask yourself, "Is the headache of separating these channels worth less than the risk of keeping them combined?" My money says yes.

A couple of questions usually pop up when we have these chats. Does your customer service team send transactional texts from the same number or ID that your authentication codes come from? If they do, an attacker who spoofs that sender ID gets a whole lot more trust. And how about password resets? Do they also rely on SMS, creating a situation where a simple SIM swap could take down your second factor and your reset option? Most places, they do. The fix isn't technically hard, but it can be an operational pain in the backside.

What to Do About SMS as a Second Factor

Alright, the honest answer to "Should we still use SMS for MFA?" is, it depends. Depends on what you're protecting, and who you're protecting it from. For consumer accounts, where the only other option is no second factor at all, SMS is still a meaningful step up. But for high-value accounts, employee access, or anything that touches money? SMS has been a known weak link for years. The Authy breach is just another big reason to treat it that way.

There are other options, you know. Authenticator apps are your cheapest upgrade. Passkeys are a more robust long-term solution if your organization can handle the user experience changes. And hardware tokens? Still the absolute gold standard for your most valuable users. None of these are new ideas. What *is* new is that the price tag for sticking with SMS just went up, because the bad guys are getting much, much better at hitting exactly who they want to hit.

The Vendor Risk Lesson

The Authy incident is also a pretty clear example of how even a security-focused vendor can accidentally create risks through some minor feature. That vulnerable endpoint wasn't even part of their core authenticator service. It was just a convenience feature that, looking back, absolutely should have required authentication.

Most security teams, when they audit their vendors, focus on the main product. The Authy breach is a good reminder that your attack surface is the *entire* API, not just the parts the vendor hypes up. So, the right question to ask isn't just, "How do you protect your main service?" It's also, "What *other* endpoints does this service expose, and what could a bad guy do with them?"

What the Next Wave Looks Like

I fully expect that Authy data to keep kicking around, getting combined with other breach data, for years to come. A list of confirmed MFA users doesn't expire quickly, because phone numbers stick around longer than passwords, and the list's value doesn't go down just because it's been used a few times. Every time it gets mashed up with a new email or password dump, it creates another fresh target list.

For organizations dealing with these campaigns, you need to assume the targeting is going to get even more precise over time, not less. The best defenses are the ones that take the human element out of the verification process as much as possible, and that make a successful social engineering attack so expensive that the bad guys just move on to an easier target.

A Short Action List

If you only do three things this quarter, make them these: First, audit every single workflow where SMS is the *only* way to verify an action that moves money or grants access. Tighten that up. Second, publish a clear list, right inside your product, of what your support team will *never* ask a customer to do via SMS. Set that expectation. And finally, start tracking the answer rates and click-through rates on your own outbound SMS messages. That trend will tell you exactly how much value that channel still holds for you.