Last year at a conference, I sat and listened to various presentations about the upcoming benefits of RCS Business Messaging (RBM) and how it was going to benefit businesses, solve all their engagement issues, offer more rich interaction to consumers and make all the businesses rich! Ok, well, maybe not with so many superlatives. But the point is that RBM will be a game-changer replacement and sometime enhancement for SMS messaging for many.
Among the RBM examples was a 2-Factor Authentication (2FA) example that highlighted a common mistake that, if one is not careful, could lead to devastating consequences. Let me explain where SMS based 2FA has absolutely saved me, more than once.
My password was obviously hacked on X over a year ago. For a few days, I would receive 2FA SMS messages with codes for me to enter. But I wasn’t logging into X at all. So, someone obviously had stolen my X credentials, but they could not finish the login due to the needed security code sent via SMS. Now I know that was not the most secure method to receive 2FA codes (I now use a TOTP based 2FA from an Authenticator app [like Google Authenticator]), but it saved me. I was able to quickly changed my login credentials.

Today, many of us absolutely do rely on 2FA through SMS and email – more traditional, yet flawed methods to keep our accounts safe.
2FA using RBM, while offering significant enhancements over traditional SMS, is not immune to security dangers. Many of the risks inherent in SMS 2FA also apply to RBM 2FA, sometimes with an added dimension due to the platform’s specific architecture.
The example at the conference showed an RBM message with an Accept and Deny button, and that immediately struck me as a huge danger. Certainly, it is a convenience for the user; however, there are big problems with that approach.
Let’s examine the issues and the key vulnerabilities:.
- Accidental Approval/Rejection: The ease of a single tap can lead to users accidentally pressing “Accept” for a fraudulent request or “Reject” for a legitimate one, especially if notifications pop up while the user is engaged in another activity or not paying full attention. This is less likely when a user must consciously type a code. And you never engage with the original login, for example, to respond with a code. An accident “Accept” could be devastating (as in the case of my fraudulent X logins),
- Notification Fatigue: While the “Accept/Reject” method offers convenience in authentication, it also brings significant risks due to potential user errors and malicious tactics. Users, who are often multitasking, may appreciate the simplicity of this method. However, it is this ease that can also lower their defenses against threats and result in catastrophic consequences.
- Attackers could potentially flood a user with multiple RBM 2FA requests. Faced with numerous notifications, a frustrated user might hit “Accept” (or “Reject”) indiscriminately just to clear the alerts, without scrutinizing each request’s legitimacy. This is a known tactic called “push bombing” or “MFA fatigue.”
- Reduced User Scrutiny and Over-Reliance: The simplicity of “Accept/Reject” buttons might lead users to scrutinize the authentication request less carefully compared to manually entering an OTP. Users might implicitly trust the branded message and the button interface, lowering their guard against subtle signs of phishing or spoofing. They might not verify the source or context of the request as diligently as they normally would for a 2FA message with an OTP.
- UI Spoofing and Look-Alike Attacks: Attackers could craft sophisticated RBM messages that perfectly mimic a legitimate service’s branding and 2FA prompt, including authentic looking “Accept” and “Reject” buttons. This could come through P2P RCS channels, instead of RBM. Certainly, we are used to 10DLC SMS messages as perfectly legitimate. While approved RBM messages will have the verified brand name as the sender, such spoofed RCS messages could originate from a phone number and otherwise look perfectly legitimate:
- They might make the “Accept” button more prominent or visually appealing.
- They could subtly alter the text around the buttons to mislead the user (e.g., “Reject this suspicious login attempt?” with “Accept” as the more prominent button to click if they don’t recognize it).
- The rich capabilities of RBM make it easier to create these convincing fakes compared to plain SMS.
- Lack of Context or Obscured Details in Notifications: If the initial notification only displays the “Accept” and “Reject” buttons without sufficient immediate context about the originating service, the specific action being authorized (e.g., login location, transaction amount), or if the full message is truncated, users might make a decision based on incomplete information. They might click “Accept” assuming it’s for a recent legitimate action they took, while it’s actually for a malicious one.
- No Opportunity for “Mental Check” During Manual Entry: The act of receiving a code, switching to an app/website, and manually typing it in provides a brief moment for the user to pause and reconsider the legitimacy of the request. “Accept/Reject” buttons streamline this process, potentially removing that natural “mental check” point.
While I do not recommend using Accept/Reject at all for any 2FA application, there are some additional safeguards that could be implemented to mitigate these risks, should you want to proceed. For instance, incorporating a quick verification step where users are required to confirm a unique detail related to the transaction or login attempt can add an extra layer of security and a specific reference back to the action that required the additional authentication factor. For example, about logging into X, the message should provide more information regarding the login attempt: the device, potential location, date/time, among any other details.
Furthermore, educational initiatives aimed at increasing user awareness about the potential threats associated with “Accept/Reject” notifications can be highly effective. By informing users about the tactics employed by attackers, such as “push bombing” and UI spoofing, they will be better equipped to recognize and respond to suspicious requests. Ultimately, while convenience is important, striking the right balance between ease of use and robust security measures is crucial in safeguarding users against the vulnerabilities inherent in simplified authentication methods.
While the promise of convenience that RBM provides is appealing, it is essential to balance it with robust security practices to safeguard users from the evolving landscape of various threats. Implementing a comprehensive security strategy that blends convenience with vigilance will ensure a safer digital experience for brands and consumers, alike. Or just don’t use some of the flashy RBM features for certain messaging categories, such as 2FA, just because you can.