Ask most people whether their text messages are private and they assume the answer is yes. It is not. A standard SMS is not end-to-end encrypted, and the protection that does exist on a mobile network is thinner than the word "encryption" suggests. That matters if your business sends one-time passwords, account alerts, or anything else a customer would rather keep private.
This guide explains what is really happening when you send a text, where an SMS is exposed, and what "SMS encryption" can and cannot mean for a company that sends messages at scale. It also covers the alternatives worth using when a message genuinely needs to stay confidential.
Is SMS encrypted? The short answer
No, not in the way people usually mean. When you send a text, the mobile network does apply encryption to the radio link between your handset and the nearest cell tower. On GSM networks that job falls to the A5 family of ciphers, and several of them have been publicly broken. A5/2 can be defeated with a ciphertext-only attack, and A5/1 has been cracked using precomputed tables since researchers demonstrated it with off-the-shelf equipment. So even the one layer of encryption SMS does use is not something to rely on for sensitive data.
More importantly, that encryption stops at the tower. Past that point the message travels through the operator's core network and lands on a short message service center (SMSC), where it is handled and briefly stored in a form the network can read. Google says it directly in its documentation for Messages: "End-to-end encryption isn't available for SMS/MMS messages." There is no cipher you can switch on that turns a normal text into a private, sender-to-recipient encrypted message across the public network.
How an SMS actually travels, and where it is exposed
Understanding the risk means following the path a single message takes:
Your phone hands the message to the nearest cell tower, protected only by the radio-link cipher.
The tower passes it into the carrier's core network, where the radio encryption no longer applies.
The message reaches an SMSC, which stores it until the recipient's network can deliver it.
It crosses to the recipient's carrier, often over interconnect links shared between operators, and finally arrives on their handset.
Each hand-off is a point where the message exists in readable form to someone other than the sender and recipient. The carrier can see it. Anyone who compromises the signaling between carriers can potentially reach it. And because messages sit on an SMSC before delivery, "in transit" is not a single instant but a short journey with several stops.
The real threats to unencrypted SMS
The gap between "feels private" and "is private" is where fraud lives. These are the threats that actually exploit it.
Threat | What it is | Why SMS is vulnerable |
SS7 interception | Abuse of the signaling protocol that connects mobile networks | Weaknesses in SS7 can be used to reroute or intercept texts, including one-time passcodes, without touching the target's phone |
SIM swapping | An attacker convinces a carrier to move a number to a SIM they control | Once they receive your texts, they receive your verification codes and can reset accounts |
IMSI catchers | Fake cell towers (also called stingrays) that trick phones into connecting | They can capture nearby traffic and, in some setups, downgrade devices to weaker encryption |
Smishing | Phishing delivered by text | SMS carries no sender authentication a recipient can verify, so spoofed sender names are easy to fake |
Stored and carrier access | Messages readable at the network and on the SMSC | The content is not protected from the operator or anyone with access to those systems |
None of these require breaking a cipher on the recipient's phone. They exploit the fact that SMS was never designed to keep its contents secret from the network that carries it.
What "SMS encryption" can and cannot mean for a business
Here is the misconception worth clearing up, because a lot of writing on this topic gets it wrong. You cannot take a standard SMS and make its contents end-to-end encrypted over the mobile network. There is no setting, no key exchange, and no AES option that survives the trip through the SMSC to a basic handset. The receiving phone has to display plain, readable text, so the network has to deliver plain, readable text.
What a business can actually do is secure everything around the message. Think of it as two separate problems: protecting the systems and connections that generate and send your traffic, and deciding what information is safe to put in a text at all. Both are within your control. The message payload on the final radio hop is not.
How to secure business SMS in practice
For a company sending application-to-person traffic, real security comes from the pipeline, not from encrypting the SMS body. A few measures do most of the work:
Encrypt the connection to your provider. Your messages leave your systems before they ever reach a carrier. Send them over HTTPS if you use a REST API, and use TLS on your SMPP gateway connection if you integrate at that level. This protects the content between your application and the messaging platform, which is the part of the journey you own.
Protect data at rest and control access. Message logs, recipient lists, and delivery reports often contain personal data. Encrypt them in storage, restrict who can query them, and keep audit trails. A reputable transactional platform will already do this: SMSALA's transactional SMS service, for example, runs on TLS-secured APIs and is built for regulated use with SOC 2 Type II and GDPR compliance, which is the level of platform hardening that matters far more than any cipher applied to the text itself.
Send over direct, legitimate routes. Grey routes and unauthorized interconnects add hops and parties you cannot vet. Direct operator connections keep the path shorter and the handling accountable, which reduces both interception risk and delivery failure.
Keep secrets out of the message, by design. The safest way to handle a sensitive value in a text is to make interception useless. A one-time passcode works precisely because it is single-use and expires in minutes, so a code captured after the fact is worthless. That is why secure OTP delivery leans on short lifetimes, single use, and rate limiting rather than on encrypting the code. Never send passwords, full card numbers, health details, or account credentials in an SMS body.
Encrypted alternatives when you need true confidentiality
If a message's contents genuinely must stay private between two parties, SMS is the wrong channel and no amount of pipeline hardening changes that. The options that do provide content confidentiality are richer messaging channels and dedicated apps.
Within Google Messages, RCS chats are end-to-end encrypted when both people have RCS enabled, and Google is explicit that plain SMS and MMS are not. In March 2025 the GSMA published an updated RCS specification that adds end-to-end encryption based on the Messaging Layer Security (MLS) protocol, with the goal of making encrypted messaging work across different apps and platforms, including iOS. That capability is rolling out rather than being universally available on every device today, so treat it as an emerging standard rather than a guarantee. For businesses, RCS messaging also brings verified sender identity and richer content, which addresses the spoofing problem SMS cannot.
Consumer apps built around end-to-end encryption, such as Signal and WhatsApp, encrypt content so that only the participants can read it. They are a fit for conversations, though for automated business notifications they come with their own onboarding, opt-in, and template rules.
The table below sums up where each channel stands on content encryption.
Channel | Content end-to-end encrypted? | Notes |
Standard SMS | No | Radio-link cipher only, broken in parts, plain text through the network |
RCS (Google Messages) | Yes, when both sides use RCS | SMS/MMS fallback is not encrypted; cross-platform E2EE via MLS is rolling out |
WhatsApp / Signal | Yes | App required on both ends; business messaging has its own rules |
Business API pipeline (TLS/HTTPS, SMPP over TLS) | Protects the sending path, not the final hop | Secures your systems to the platform, plus data at rest |
SMS encryption and compliance: GDPR, HIPAA, and PCI DSS
Regulations are often cited as a reason to "encrypt SMS," but none of them mandate a specific text-message cipher. GDPR requires appropriate technical measures to protect personal data. HIPAA requires safeguards for protected health information. PCI DSS requires cardholder data to be protected in transit and at rest. What they have in common is a duty to protect the data, not an instruction about SMS specifically.
Because a standard SMS cannot protect its own contents on the network, the compliant approach is straightforward: keep regulated data out of the message body, secure the platforms and connections that handle it, and document those controls. A verification code or a "your appointment is confirmed" alert is fine. A diagnosis, a full card number, or a password is not.
A practical checklist
If you send business messages and want to get the security right without chasing a cipher that does not exist for SMS, work through this:
Connect to your provider over HTTPS or SMPP over TLS, never an unencrypted link.
Encrypt message logs and recipient data at rest, and limit who can access them.
Route through direct operator connections rather than grey routes.
Put only non-sensitive, and ideally single-use, information in the text itself.
Use RCS or an encrypted app when a message's contents must stay private.
Confirm your platform's compliance posture matches your industry's rules.
Frequently asked questions
Is SMS encrypted end to end?
No. Standard SMS is not end-to-end encrypted. Mobile networks encrypt only the radio link between the handset and the tower, using ciphers that have been partly broken, and the message is readable to the network beyond that point.
Can I add AES encryption to a normal text message?
Not in a way the recipient's phone can automatically read. A basic handset displays plain text, so the network must deliver plain text. You can encrypt the connection between your systems and your messaging provider, but not the SMS content across the public network to an ordinary phone.
Why is SMS still used for two-factor authentication if it is not encrypted?
Because it is nearly universal and needs no app, and because a one-time code is single-use and short-lived, which limits the value of intercepting it. It is weaker than an authenticator app or passkey, but far better than no second factor. For higher-risk accounts, prefer app-based authentication.
Is RCS encrypted?
Within Google Messages, RCS chats are end-to-end encrypted when both parties have RCS enabled. Cross-platform end-to-end encryption for RCS, based on the MLS protocol, was added to the GSMA specification in 2025 and is rolling out. Plain SMS and MMS remain unencrypted.
What is the most secure way to send a sensitive message?
Use a channel with genuine end-to-end encryption, such as RCS between RCS-enabled devices or an encrypted messaging app, and avoid placing sensitive data in a plain SMS at all.
The takeaway
SMS is reliable and reaches almost any phone on earth, but it was never built to keep its contents secret from the network that carries it, and no toggle changes that. For a business, security is not about encrypting the text. It is about protecting the systems that send it, choosing clean routes, keeping sensitive data out of the message, and moving to an encrypted channel when confidentiality is the point. Get those decisions right and SMS stays exactly what it is good at: fast, dependable delivery you do not have to worry about.