TLS 1.3 uses pre-shared keys for session resumption. A server can issue a session ticket after an authenticated connection, and a later connection can resume with less handshake work. The performance benefit is real, especially for services with short-lived connections and strict latency budgets. The security question is whether the identity and authorization decision from the original connection are still valid when the ticket is used.
RFC 8446 describes resumption as a PSK handshake. The server must bind the ticket to the correct context and decide whether the client may resume. If the original connection involved client-certificate authentication, a proxy identity, or an application-level login, the resumed connection may not repeat every step of that process. The server needs to know which claims are carried by the ticket and how long they may be relied upon.
RFC 9325 recommends limiting how long resumption secrets and tickets remain usable. The exact limit depends on the protocol and deployment, but the design principle is stable: a ticket should not outlive the identity decision it represents. Session tickets can contain encrypted state, or the server can keep state keyed by a ticket identifier. In either case, rotate ticket keys, retire old keys on a schedule, and make revocation of the underlying identity effective for resumed sessions.
A common design mistake is to use a long ticket lifetime to reduce CPU load while keeping permissions dynamic. The server authenticates the original session, then later accepts the ticket without rechecking whether the user is still in a group, whether a device remains compliant, or whether the client certificate has been revoked. That can preserve access after an account change. The resumption layer has no natural knowledge of the application's business rules.
Teams should document the identity source for each TLS endpoint. If client certificates provide workload identity, map the certificate identity to a workload record and define ticket lifetime relative to certificate lifetime and revocation. If an application token or cookie provides user identity, keep the TLS ticket independent from that application session. Termination at a load balancer and re-encryption to a backend creates two contexts. The backend should not assume that a resumed edge connection represents a fresh user login.
Operational controls make the design testable. Set a maximum ticket lifetime, cap the ticket key schedule, and record resumption in connection logs without logging ticket contents. Alert when a service resumes with a ticket that is older than the approved window. For administrative endpoints, consider requiring a full handshake or an additional reauthentication at a lower threshold. Do not rely on a generic TLS library default to express the business policy.
Testing should include a changed authorization state. Connect with a valid identity, obtain a ticket, change the identity's group or revoke its certificate, and then reconnect using the ticket. Observe whether the service accepts the resumption and whether the application data plane blocks the action. Test a rotated ticket key and a backend restart. The expected outcome should be the same as a fresh authentication for the protected operation.
Session resumption is a performance feature with a lifetime decision inside it. A team can keep it fast and safe by making that lifetime visible. The ticket should inherit only the identity facts the server can still verify, expire before the underlying grant becomes stale, and fail closed when the revocation or authorization state is unknown.