RCS in 2026: standard, availability and rollout status
RCS is a carrier messaging standard. According to Apple Support, an iPhone needs at least iOS 18 and a supporting carrier for baseline RCS. From iOS 26.5, Apple provides E2EE as a beta with supported carriers and is rolling it out gradually. Availability depends on the region and carrier. The GSMA finalised Universal Profile 4.0 on 26 March 2026, but the specification does not guarantee deployment of every feature on every device or application.
- RCS adds features familiar from messaging apps to standard messaging but remains dependent on network service and device configuration.
- Users should see whether a conversation uses RCS or another message type before sending content that requires specific protection.
- A business should not assume an identical feature set across every device, application, market and carrier.
- Communication design must include recipients without active RCS or with temporarily unavailable data connectivity.
Sources, availability and fallback
Apple Support and GSMA announcements describe baseline service, the gradual E2EE rollout and development of the standard. Business messaging still needs a tested transition to SMS or MMS.
Apple Support - RCS on iPhone
Apple states the iOS 18 requirement, regional and carrier dependency, and the iOS 26.5 E2EE beta conditions.
GSMA - E2EE rollout
The 11 May 2026 announcement describes the start of rollout between iOS 26.5 and current Google Messages.
GSMA Universal Profile 4.0
The official 26 March 2026 announcement describes profile finalisation, new features and backward compatibility.
Google — RBM data security
The documentation distinguishes RBM connection encryption from user-chat E2EE and describes content access and partner responsibilities.
Security and a business communication pilot
Distinguish user-to-user conversations from RCS Business Messaging (RBM). Google states that its RBM does not offer E2EE: it encrypts connections between the device, platform and partner. Do not automatically extend personal-chat protections to a business campaign or agent.
Check conversation encryption
Before sending data, check the encryption indicator in that conversation. Do not assume that every contact or group conversation has the same protection.
Verify sender and recipient
Delivery to a number does not confirm identity. RCS does not remove phishing, number takeover or compromised-device risk.
Pilot on real devices
Test Android, iPhone, carriers, text, media, links, groups, network changes, disabled RCS, fallback and non-delivery.
Process and connected channels
Define the owner, excluded content, privacy, retention and error handling; connect RCS with telephony, email and user support.
RCS encryption must be checked for the specific conversation
End-to-end encryption is not a universal property of every RCS conversation. In iOS 26.5 Apple offers it as a gradually deployed beta with supported carriers, while the GSMA describes rollout between iPhone and current Google Messages. Do not send sensitive content based on the RCS label alone or without an indicator confirming protection.
Recipient identity
Delivery to a phone number does not replace independent identity verification for a high-risk operation.
Information classification
Define which data must not use a channel without confirmed protection, retention and recipient control.
Link and device protection
RCS does not eliminate phishing, false links, number takeover or the risk of a compromised device.
Decisions before using RCS for business communications
A rollout should begin with the business purpose and recipients, not a feature list. Otherwise, the company may build a campaign or service process that works only for some users and lacks a clear failure path.
- Choose fallback according to information classification. SMS/MMS does not preserve an RCS conversation’s E2EE; do not automatically resend content that requires that protection over a different channel.
- Check devices, applications, carriers and regions and prepare tests for RCS, SMS, MMS and non-delivery.
- Define sender identification, recipient verification, link handling, abuse reporting and delivery-error handling.
- Specify retention, history access, privacy rules and evidence needed for a complaint or incident.
- Monitor carrier and OS support changes because feature availability may change independently of the company.
How to run a secure pilot in your organisation
A small test should cover real devices and scenarios, not just one message. The result should decide when to use RCS, when to switch channels and how to handle a missing receipt or feature mismatch.
- Select a limited group of Android and iPhone devices and carriers represented in the intended audience.
- Test text, media, a link, receipts, a group conversation, a network change and a situation without active RCS.
- Check how the interface labels message types and whether users understand the difference between RCS, SMS, MMS and a messaging app.
- Record acceptance criteria, error cases, the escalation owner and the fallback-channel decision.
- Repeat the test after a carrier, application, OS version or managed-device configuration change.
Related communication and security areas
RCS is one channel. A business still needs structured telephony, email, devices, networks and user support so that communication remains available and can be handled after a failure or incident.
Internet telephony
Business numbers, queues, forwarding, continuity scenarios and customer service from multiple locations.
Email security
Protection of another important channel from account takeover, malicious links and impersonation.
IT outsourcing
Management of devices, accounts and networks, coordination with carriers and support for business communication issues.
