TLS 1.3 0-RTT resumption is a connection mode that lets a client send application data during the first flight of a resumed TLS 1.3 handshake. It uses prior session state to reduce latency, but early data can be replayed, so it suits idempotent requests only.
How TLS 1.3 0-RTT Resumption Works
TLS 1.3 0-RTT resumption is a latency-reduction mode built on a previously established TLS relationship. It lets a client begin sending early application data before the resumed handshake fully completes, which is why it is faster but also more constrained than ordinary application traffic.
That trade-off matters because 0-RTT is intentionally designed for speed, not for replay resistance. The protocol can carry data before the server has fully re-established fresh handshake state, so the mechanism is only safe when the application can tolerate duplicate delivery or repeat execution.
The distinction is important operationally: a resumed session is not the same thing as a fresh connection, and 0-RTT does not inherit the same guarantees as fully established TLS application data. A system using 0-RTT must treat the early-data window as a special case, not as a generic optimisation that can be enabled everywhere.
Why 0-RTT Creates Replay Sensitivity
0-RTT early data can be replayed by an adversary or by network conditions that cause the same early request to be observed more than once. That is why the feature is suitable for idempotent operations, but unsafe for actions that create side effects such as purchases, password changes, state transitions, or token issuance.
This replay sensitivity is not a weakness in TLS confidentiality itself, but a consequence of allowing useful work to begin before the handshake has fully finished. In practice, the risk sits at the application boundary: the transport can deliver the bytes quickly, but the application still has to decide whether those bytes are safe to process twice.
Modern TLS guidance therefore treats 0-RTT as an optimisation with strict usage rules, not as a universal default. If the business action has durable consequences, the transport savings are rarely worth the ambiguity introduced by replayable early data.
How Organisations Check Exposure and Decide Where to Use It
Exposure assessment starts with knowing which clients and endpoints actually negotiate TLS 1.3 resumption and which application paths accept early data. Teams usually review asset inventory, front-door configuration, CDN or reverse-proxy behaviour, and vendor documentation to confirm whether 0-RTT is enabled, disabled, or selectively permitted.
It is also important to check whether the deployed stack enforces the intended semantics consistently. A service may technically support 0-RTT while the application logic behind it is not prepared for replay, logging gaps, or duplicate processing, which creates a hidden mismatch between transport capability and business safety.
For certificate and trust-chain context, public TLS deployments should still follow established certificate ecosystem guidance, including CA/Browser Forum baseline requirements for issuance and revocation, while protocol-specific behaviour is validated against the relevant TLS implementation and vendor advisories.
Controls for Safe Use and Verification
The safest pattern is to allow early data only on requests that are demonstrably idempotent, stateless, or protected against replay at the application layer. If a request can change state, move money, advance workflow, or mint a security token, it should not rely on 0-RTT as though it were ordinary post-handshake data.
Operators should also confirm that monitoring can distinguish resumed handshakes and early data acceptance from normal request flow. That matters because incidents tied to replay or duplicate submission are easy to misread as application bugs unless logs, edge telemetry, and retry handling are designed to preserve the handshake context.
Where TLS deployment guidance is needed, the most useful references are the general TLS implementation guide and the protocol-specific HTTP/transport guidance. How TLS Works Guide covers 0-RTT in the broader handshake model, and HTTP/2, HTTP/3 and QUIC Security Guide is useful where early data, logging, and transport-layer behaviour intersect.
Risk and Threat Considerations
0-RTT introduces a narrow but real replay risk: an attacker or intermediary that can capture early data may be able to replay it, and the server may not be able to distinguish the replay from the original submission. That makes the feature dangerous for any operation whose safety depends on single execution.
Failure mechanism: The server accepts early application data before the resumed session is fully established, so replayed requests can pass through transport-layer protection and reach application logic more than once.
Impact: Duplicate actions, inconsistent state, unintended side effects, and security-relevant workflow errors can follow if the application treats replayable early data like ordinary authenticated traffic.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SC-23 — Session Authenticity | 0-RTT resumption depends on preserving trust in session-bound TLS traffic. |
| SC-8 — Transmission Confidentiality and Integrity | TLS 1.3 0-RTT protects data in transit while changing when application data may flow. | |
| AU-6 — Audit Review, Analysis, and Reporting | Replay-sensitive early data needs logging that distinguishes resumed handshakes and duplicate requests. | |
| Recommendation — Validate session authenticity controls before allowing replayable early data. Enforce protected transport for traffic that uses resumed TLS sessions. Review logs for duplicate early-data submissions and handshake anomalies. | ||
| CIS Controls v8 | CIS-16 — Application Software Security | Safe use of 0-RTT depends on application design that prevents duplicate side effects. |
| Recommendation — Gate 0-RTT behind application logic that tolerates replay. | ||
Practitioner Guidance
Why practitioners should care: The question is not whether 0-RTT improves latency, it does, but whether the business action can safely tolerate replay. If the answer is unclear, the safer default is to deny early data for that path and require the request to occur after the handshake completes.
What to watch for: Any endpoint that performs non-idempotent work, issues secrets or tokens, or updates durable state should be reviewed before 0-RTT is enabled. The control decision belongs at the application boundary, not just in the TLS configuration.
Practitioner takeaway: Use 0-RTT as a targeted performance optimisation, and limit it to request flows that remain correct even if they are delivered more than once.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 29, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org