0-RTT can increase replay risk because early data may be accepted before a full session is re-established. If an attacker captures that data, they may resend it to trick a server into repeating a valid action, such as a login request. Security teams should treat cached 0-RTT data as sensitive session material and apply strict replay controls or disable it where risk is unacceptable.
Why 0-RTT Changes the Replay Model
0-RTT is attractive in mobile apps because it reduces startup latency, but that speed comes with a weaker trust assumption. The client may send data before the server has fully re-established the session, so the server has less context to distinguish a fresh request from one that has already been seen. That is why 0-RTT should be treated as a special-case path, not a normal request flow.
In practice, the replay problem is not just theoretical. If the early data carries an action with side effects, like a login, purchase, or state change, a captured request can sometimes be resent and accepted again. The safer design is to limit 0-RTT to idempotent or low-risk operations and require stronger confirmation for anything that changes security state or business state.
Mobile environments can make this harder because apps reconnect often, move across networks, and depend on session resumption for performance. That combination increases the chance that developers will enable 0-RTT broadly and overlook which API calls are safe to repeat. The key question is not whether 0-RTT works, but whether the application can tolerate duplicate execution of the same early request.
Where Replay Exposure Comes From in Mobile Flows
Replay exposure comes from the gap between early acceptance and full session validation. During that gap, an attacker who captures traffic can resend the same early data, hoping the server will process it again before replay protection or session state catches up. That risk is highest when the request is valid on its own and the server does not bind it tightly enough to a unique session, nonce, or freshness check.
Security teams should pay special attention to requests that look harmless at the transport layer but are meaningful at the application layer. A repeated authentication attempt, token exchange, password reset step, or privileged action can have different consequences if the server does not enforce one-time semantics. RFC 9449: OAuth 2.0 Demonstrating Proof of Possession (DPoP) is relevant here because sender-constraining tokens is one practical way to reduce the value of stolen material in replay scenarios.
Mobile app teams also need to distinguish transport replay risk from application replay risk. Even when the underlying protocol supports early data safely, the app can still be vulnerable if the business operation is replayable. That is why replay resistance has to be designed at the request and transaction layer, not assumed from the transport layer alone.
What Good Replay Controls Look Like
Good control design starts with classification. Identify which requests can be repeated without harm, which require one-time processing, and which should never be accepted in early data at all. Then enforce the policy consistently across mobile clients, backend APIs, and any gateway or load balancer that terminates or forwards the session.
For the highest-risk flows, the practical choices are usually to disable 0-RTT, require a fresh authentication step, or add server-side freshness checks that reject duplicates. Controls are strongest when the server can prove that a request is new, not merely when the client says it is. In other words, replay protection should be server-enforced, not client-claimed.
For lower-risk flows, a bounded replay window may be acceptable if the operation is idempotent and the business impact of duplication is trivial. That decision should be explicit and reviewed, especially in mobile apps where session resumption is frequent and transport assumptions are easy to lose track of.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Covers session and credential freshness controls that reduce replay exposure. |
| IA-2 — Identification and Authentication (Organizational Users) | Applies because replay risk often targets authenticated user sessions and login flows. | |
| SC-23 — Session Authenticity | Directly addresses protecting session state against replay and impersonation. | |
| Recommendation — Enforce lifecycle and freshness rules so sensitive requests cannot be reused after capture. Require strong re-authentication for state-changing mobile actions. Validate session authenticity before accepting early or resumed requests. | ||
| OWASP ASVS | V9 — Self-contained Tokens | Relevant where mobile apps rely on tokens or bearer material that can be replayed. |
| V10 — OAuth and OIDC | Applies when mobile authentication and token exchange are part of the replayable flow. | |
| Recommendation — Use token designs that resist replay and bind tokens to the intended session context. Harden OAuth flows so authorization artifacts cannot be reused by an interceptor. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | Replayable early data can undermine API authentication if freshness is not enforced. |
| API6 — Unrestricted Access to Sensitive Business Flows | Repeated 0-RTT requests can re-trigger sensitive business actions if not guarded. | |
| Recommendation — Reject API authentication flows that accept duplicated or stale request material. Protect sensitive flows with server-side duplicate detection and freshness checks. | ||
Practitioner Guidance
What to prioritise: Start with any 0-RTT-enabled request that can change authentication state, authorise access, or trigger a business action. Those are the flows where replay creates real loss, not just protocol noise.
What to verify: Confirm whether the backend rejects duplicate early data, binds sensitive requests to freshness markers, and treats repeated submissions as failures rather than successes. If you cannot demonstrate that behaviour, do not assume replay safety.
Decision rule: If an operation must be safe even when received twice, it may be a candidate for 0-RTT. If duplicate execution would be harmful or ambiguous, keep it out of early data and require a full re-established session first.
Practitioner takeaway: 0-RTT is a performance optimisation with a security cost, so the right control is not blanket prohibition or blanket enablement, but strict scoping of which requests can ever be replayed safely.
Related resources from NHI Mgmt Group
- Why does mobile access to cloud applications increase the risk of data exposure?
- Why do mobile and partner APIs increase fraud and data-exposure risk?
- Why do AI agents and LLM applications increase the risk of unauthorized access and data leakage?
- Why do mobile applications create privacy and security risk even when users never intentionally share sensitive data?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 29, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
