Skip to main content
Commerce Security Authority
Category: Data Protection Methods

End-User Messaging Technologies

Also known as: AWS End User Messaging, SMS/MMS/voice messaging services, multichannel messaging delivery
Simply put

End-user messaging technologies are services and systems that deliver messages to individuals through channels such as SMS text, MMS, voice, push notifications, and third-party apps like WhatsApp. Businesses use them to send notifications, one-time passcodes, and other communications to customers. As delivery channels, they carry information but are not themselves security or data-protection controls.

Formal definition

End-user messaging technologies are managed communications platforms and APIs that enable applications to send and deliver messages across channels including SMS, MMS, voice, push, and over-the-top messaging apps (for example, WhatsApp). AWS End User Messaging is one such service, providing scalable delivery, message feedback, and monitoring capabilities (including for one-time-passcode delivery and conversion tracking). In payment security contexts, these channels are frequently used to deliver transaction alerts, one-time passcodes (OTPs), and step-up authentication prompts, but they are transport/delivery mechanisms rather than authentication or data-protection mechanisms in themselves. Their security posture depends on how they are configured, what data traverses them, and the controls applied at each hop. Under PCI DSS, sensitive authentication data (full track data, CAV2/CVC2/CVV2/CID, PINs and PIN blocks) must not be stored after authorization; PCI DSS does not categorically prohibit transmitting cardholder data or SAD where such transmission is necessary and properly protected, so any messaging channel handling such data must apply appropriate protection and would fall within PCI DSS scope. Confirm applicable requirements against the current published PCI DSS standard, as numbering and wording differ between versions.

Why it matters

End-user messaging technologies have become a common delivery layer for payment-related communications: transaction alerts, fraud notifications, one-time passcodes, and step-up authentication prompts often reach customers via SMS, voice, push, or over-the-top apps like WhatsApp. Because these channels touch the customer at moments that matter for fraud detection and authentication, teams sometimes treat them as if they were security controls in their own right. They are not. They are transport and delivery mechanisms, and their contribution to a security outcome depends entirely on what data traverses them and how each hop is configured and protected.

This distinction matters for scoping and risk assessment. A messaging channel that carries only a non-reusable OTP or a generic alert presents a different risk profile than one configured to carry cardholder data or sensitive authentication data. Under PCI DSS, sensitive authentication data (full track data, CAV2/CVC2/CVV2/CID, and PINs or PIN blocks) must not be stored after authorization. PCI DSS does not categorically prohibit transmitting cardholder data or SAD where such transmission is necessary and properly protected, so any messaging channel handling such data must apply appropriate protection and would fall within PCI DSS scope. Confirm applicable requirements against the current published PCI DSS standard, as numbering and wording differ between versions.

Treating messaging delivery as a self-contained safeguard can also lead teams to overestimate the assurance provided by, for example, an SMS-delivered OTP. SMS and similar channels are subject to delivery failures, interception risks, and social-engineering attacks that target the recipient rather than the channel. Message feedback and delivery monitoring can help teams observe OTP delivery and conversion, but delivery visibility is an operational metric and is not, by itself, an authentication or data-protection control.

Who it's relevant to

Payment and fraud engineering teams
Teams that build transaction alerting and step-up authentication flows rely on these channels to reach customers. They should treat the messaging platform as a delivery layer, apply protection appropriate to whatever data the message carries, and avoid assuming that channel choice alone provides authentication or data-protection assurance.
Compliance and PCI DSS assessors
Where a messaging channel is configured to carry cardholder data or sensitive authentication data, it may fall within PCI DSS scope and must apply appropriate protection. Assessors should confirm what data traverses each channel, verify that SAD is not stored after authorization, and check applicable requirements against the current published PCI DSS version, since numbering and wording differ between versions.
Fraud analysts and risk teams
Analysts using OTP and alert channels for detection and step-up should understand that delivery and conversion metrics are operational signals, not proof that authentication succeeded or that the message reached the intended person. SMS and similar channels remain exposed to interception and social-engineering targeting the recipient, so these channels are best used as one layer among several.
Cloud and platform architects
Architects integrating services such as AWS End User Messaging across multiple business units are responsible for how API integrations are authenticated, what data is placed in messages, and how transmission is protected. The channel's security posture depends on these configuration decisions at each hop rather than on the service label.

Inside End-User Messaging Technologies

End-user messaging technologies (definition)
Communications delivery channels used to send messages directly to end users, such as email, SMS text messaging, instant messaging, and chat. In a payment security context, they are treated as communication mechanisms rather than as a data-protection control, and their use is relevant to PCI DSS because of what data may be transmitted through them.
PCI DSS treatment of unprotected channels
PCI DSS addresses the sending of primary account numbers (PANs) via end-user messaging technologies. The general principle is that PAN should not be sent via these channels unless rendered unreadable through mechanisms such as strong cryptography. Requirement numbering and exact wording differ between PCI DSS versions, so confirm the specific requirement text against the current published standard.
Cardholder data vs. sensitive authentication data in transit
Cardholder data includes PAN, cardholder name, expiration date, and service code; sensitive authentication data (SAD) includes full track data, CAV2/CVC2/CVV2/CID, and PINs/PIN blocks. SAD may be collected and transmitted as part of the authorization flow when properly protected, but SAD must not be stored after authorization even if encrypted. This is distinct from the question of which channel is used to move the data.
Rendering PAN unreadable for transmission
Where PAN must be conveyed, techniques such as strong cryptography, truncation, or masking may be applied. These transform data differently: encryption reversibly protects data, truncation permanently removes digits, and masking controls display. Their effect on obligations depends on implementation and validation, not on the label alone.
Scope and channel ownership
End-user messaging channels frequently rely on third-party infrastructure (mail servers, SMS aggregators, chat providers) that an entity may not fully control. This affects who is responsible for protecting data in transit and what falls inside or outside the assessed cardholder data environment.

Common questions

Answers to the questions practitioners most commonly ask about End-User Messaging Technologies.

Are end-user messaging technologies a data-protection control?
No. End-user messaging technologies, such as email, SMS, and instant messaging, are primarily communications delivery channels, not data-protection controls. They move messages between parties but do not, by themselves, protect or transform account data. Any protection depends on separate controls layered onto or around the channel, such as encryption, tokenization, or truncation, and on how those controls are implemented and validated. Treating the messaging channel itself as a security control is a common misconception; the channel and the protection applied to its contents should be evaluated separately.
Does PCI DSS prohibit transmitting sensitive authentication data through end-user messaging entirely?
This is a frequent misunderstanding. PCI DSS prohibits storing sensitive authentication data after authorization, even when encrypted. It does not impose a categorical ban on transmitting sensitive authentication data; such data may be collected and transmitted for authorization purposes provided it is properly protected during transmission. Separately, PCI DSS restricts sending unprotected primary account numbers via end-user messaging technologies, since these channels are generally not designed to safeguard message contents. The distinction is between the storage prohibition, the transmission-protection requirement, and the specific handling expectations for messaging channels. Confirm exact wording and requirement numbering against the current published PCI DSS, as these differ between versions.
How should an organization handle a request to send a primary account number by email or SMS?
Sending an unprotected primary account number through end-user messaging channels is generally discouraged under PCI DSS because these channels are not typically designed to protect message contents. If a business process requires such transmission, the account data should be rendered unreadable through a validated control before it enters the channel, for example by masking or truncating the number so only permitted digits appear, or by using a strong encryption or tokenization approach applied to the content. The effect on PCI DSS scope depends on the implementation and validation of that control, not on the label alone. Confirm the applicable requirement against the current published standard.
How do end-user messaging channels affect PCI DSS scope?
Systems that store, process, or transmit account data are generally in scope, and messaging infrastructure that carries account data can bring associated systems into scope. Whether a given messaging path is in scope depends on what data traverses it and how that data is protected. Applying truncation or masking so that no full account data is exposed, or removing account data from the channel entirely, may reduce scope, but only when the control is correctly implemented and validated. Scope determinations should be documented and confirmed against the current PCI DSS, rather than assumed from the channel type.
What controls are commonly layered onto messaging channels when account data may be involved?
Organizations commonly combine several measures rather than relying on the channel alone. Transport protection may be applied to the connection, while masking or truncation limits the data elements that appear in a message. Tokenization can replace account data with a surrogate value so the underlying number does not travel through the channel. Access controls, logging, and data-loss-prevention tooling may help detect or restrict account data in messages. Each control addresses a different risk and has trade-offs; detection-oriented tooling in particular can produce false positives and false negatives, so these controls are intended to reduce risk rather than eliminate it.
Should customer service or support staff be permitted to receive account data through chat or messaging tools?
Business processes should be designed to avoid having full account data enter end-user messaging channels where feasible, since these tools are not generally intended to protect message contents and may retain history in ways that expand exposure. Where account data cannot be avoided, organizations typically apply protective controls, restrict who can view the data, and configure retention so that stored contents comply with data-handling requirements. Note that sensitive authentication data must not be retained after authorization. Staff training and clear procedures help reduce inadvertent disclosure, but the applicable handling requirements should be confirmed against the current published PCI DSS.

Common misconceptions

Encrypting a message means PAN can be freely sent by email, SMS, or chat.
The concern with end-user messaging is not solved by the word 'encrypted' alone. Whether protection is adequate depends on the cryptographic implementation and its validation, and on control over the channel. Verify the applicable PCI DSS requirement wording in the current version rather than assuming any encrypted message is compliant.
Sensitive authentication data may never be transmitted through any channel, even when strongly encrypted.
PCI DSS prohibits storing SAD after authorization, but it does not categorically prohibit transmitting SAD. SAD may be collected and transmitted for authorization when properly protected. The storage prohibition and the transmission channel question are separate issues.
End-user messaging is a data-protection control.
These technologies are communications delivery channels, not security controls. Any protection comes from separate measures such as cryptography, truncation, or masking applied to the data, and from controls over the messaging infrastructure.

Best practices

Avoid sending PAN through end-user messaging channels unless it is rendered unreadable, and confirm the applicable requirement wording against the current published PCI DSS version.
Distinguish cardholder data from sensitive authentication data in message flows, and ensure SAD is not retained after authorization regardless of the channel used.
Where protection is applied, document whether encryption, truncation, or masking is used and validate the implementation rather than relying on the label.
Map which end-user messaging channels touch cardholder data and identify third-party providers, since channel ownership affects scope and responsibility for protection in transit.
Implement policies and user guidance that discourage capturing PAN via email, SMS, or chat, and provide alternative protected methods for handling cardholder data.
Periodically review messaging channels for inadvertent exposure of cardholder data and reassess scope when providers, channels, or the applicable standard version change.