API platform engineers evaluating post-quantum TLS migration typically have two distinct questions, which are frequently conflated. The first is capability: does the gateway support hybrid ML-KEM key exchange? The second is interaction: does enabling PQC TLS affect rate limiting behaviour? The answers are platform-specific for the first question and largely consistent for the second. This analysis covers Kong, Tyk, AWS API Gateway, and Cloudflare across both dimensions, then provides a five-step readiness assessment that applies to any gateway deployment.

For broader context on PQC TLS deployment across enterprise egress and VPN infrastructure, see Post-Quantum VPNs: Enterprise Deployment Comparison. For selecting the TLS library appropriate to your gateway architecture, see PQC Vendor Selection: Cryptographic Library Providers.

How API gateways handle TLS and what PQC changes

API gateway TLS deployments fall into three patterns. Pattern A (TLS termination at the gateway) is the dominant model for external traffic: the gateway decrypts inbound TLS, inspects and routes the request, and optionally re-encrypts to upstream services. PQC migration at Pattern A requires the gateway's TLS library to support hybrid ML-KEM key exchange and, eventually, ML-DSA certificates. Pattern B (TLS passthrough) routes encrypted traffic directly to upstream services without termination; PQC migration is entirely at the upstream layer, with no gateway changes required. Pattern C (mTLS) requires both the server-side hybrid key exchange and eventual client certificate migration to ML-DSA for the client authentication component.

The rate limiting question resolves quickly for most deployments. Rate limiting in all four platforms covered here operates at the HTTP request layer, after TLS termination, applying rules based on API keys, consumer identity, request paths, or IP addresses. TLS handshakes, including PQC handshakes, complete before any HTTP-layer rate limit applies. A PQC handshake does not consume a request count. The one exception worth understanding is connection-level rate limiting on high-connection-rate clients, discussed under each platform below.

Session resumption (TLS 1.3 session tickets, RFC 8446 Section 2.2) substantially reduces the frequency of full PQC handshakes in practice. A client that establishes a TLS session and reuses it via session tickets avoids the ML-KEM encapsulation cost on all subsequent connections within the session lifetime. For API clients with persistent HTTP/1.1 keep-alive or HTTP/2 multiplexed connections, PQC overhead accumulates only at initial connection establishment. The deployment pattern that concentrates PQC handshake load is high connection churn: Lambda functions invoking an API per invocation, microservices without connection pooling, or CLI tools that open new TLS sessions per command. These are the clients where the handshake cost compounds.

Kong: nginx/OpenSSL dependency and the OQS-provider path

Kong Gateway (both OSS and Enterprise) uses nginx as its HTTP proxy layer, with OpenSSL handling TLS. Kong's TLS capability is therefore bounded by the OpenSSL version bundled with its nginx dependency. OpenSSL 3.x includes ML-KEM and ML-DSA support via its provider model, but the specific version bundled with a Kong release determines whether hybrid key exchange is available from that release. As of August 2025, Kong had not published release notes documenting GA ML-KEM or ML-DSA support with stated OpenSSL version requirements. [ASSUMED: verify current status at Kong product release notes before deployment planning.]

The OQS-provider path is available for Kong instances deployed with a custom OpenSSL 3.x build. The Open Quantum Safe project's OpenSSL provider (OQS-provider) adds ML-KEM and ML-DSA algorithm support to OpenSSL 3.x without recompiling the OpenSSL core, loading as a provider plugin. Kong instances on OpenSSL 3.x can gain ML-KEM TLS support via the OQS-provider before an official Kong release bundles it. This is a viable interim path for security teams that need hybrid TLS at the gateway ahead of a full vendor release cycle.

Kong's rate limiting plugins operate at the HTTP layer. The kong-inc/rate-limiting and kong-inc/rate-limiting-advanced plugins count requests per consumer per time window, not TLS connections. PQC TLS handshakes are invisible to both plugins. One edge case applies to deployments where the Kong admin API itself is accessed over TLS from a client library that does not yet support ML-KEM: repeated connection failures from an incompatible client could generate retried connections that inadvertently register as admin API activity. This affects management plane access, not data plane API traffic, and is addressable by ensuring admin API clients support hybrid TLS.

Tyk: Go runtime upgrade as the PQC migration path

Tyk API Gateway uses Go's standard library crypto/tls package for TLS. Go 1.23 (August 2024) added experimental support for X25519+ML-KEM-768 hybrid key exchange in TLS 1.3. Go's implementation follows NIST FIPS 203, not the pre-standard Kyber round-3 variant. Tyk instances running Go 1.23 or later have the underlying ML-KEM hybrid capability available at the runtime level. Whether Tyk's configuration layer exposes this as an explicit TLS option depends on Tyk's own TLS configuration API, which as of August 2025 did not document ML-KEM hybrid as a configurable option. [ASSUMED: verify current Go version support status and Tyk configuration documentation.]

The upgrade path for Tyk is simpler than for Kong. Kong requires managing an OpenSSL provider dependency; Tyk's path is a Go runtime version upgrade, which follows Tyk's standard release and dependency update cycle. Once Go's ML-KEM hybrid support is stable (flagged experimental in Go 1.23; later Go versions may promote it), Tyk deployments on a current Go runtime gain PQC TLS support without architectural changes.

Tyk's rate limiting operates at the API key and policy layer, applying request counts per key per time period. Like Kong, Tyk rate limits at the HTTP layer after TLS termination. PQC TLS handshakes have no interaction with Tyk's rate limiting in standard deployments.

AWS API Gateway: platform-managed TLS with no customer configuration

AWS API Gateway (REST API, HTTP API, WebSocket API) uses AWS's internal TLS termination infrastructure rather than a customer-configurable TLS stack. AWS's s2n-tls library, used across AWS services including CloudFront and ALB, has post-quantum hybrid ML-KEM-768 support and has been deployed in those contexts. Whether that s2n-tls PQC capability has been enabled for API Gateway's TLS termination is an AWS internal rollout decision, not a customer configuration option. As of August 2025, AWS API Gateway documentation did not describe hybrid ML-KEM key exchange as a configurable or available option. [ASSUMED: verify current status with AWS release announcements and API Gateway documentation.]

AWS API Gateway throttling (10,000 RPS default at the account level, configurable per stage and method) applies to HTTP requests after TLS termination. PQC handshakes do not consume throttle budget. One scenario worth noting: if clients experience PQC handshake failures due to middlebox interference on their network path and retry those connections, the retried requests count against rate limits once TLS establishes. For architectures where API Gateway clients are AWS Lambda functions, Lambda's execution environment handles TLS using the HTTP client library bundled in the function; Lambda does not expose direct TLS configuration, so PQC at the Lambda-to-API-Gateway layer depends on the HTTP library in use.

Cloudflare: hybrid TLS on by default, with a JA3/JA4 fingerprint caveat

Cloudflare is the most PQC-advanced of the four platforms assessed here. Cloudflare deployed X25519+ML-KEM-768 hybrid TLS across its global network using BoringSSL beginning in 2023. For API traffic routed through Cloudflare's API Gateway (part of Cloudflare API Shield) or Cloudflare Workers, hybrid PQC TLS is on by default for TLS 1.3 connections where the client supports it. No customer configuration is required. An API client already using hybrid ML-KEM is already getting post-quantum TLS at the Cloudflare edge.

For Cloudflare Workers acting as API backends, outbound TLS connections made via the fetch() API use BoringSSL with ML-KEM support, so Workers-to-PQC-capable-server connections already operate with hybrid TLS on the outbound path.

Cloudflare's rate limiting (API Shield rules, Cloudflare Rules) applies at the HTTP request layer and is transparent to TLS handshakes. There is, however, a non-obvious operational interaction with Cloudflare Bot Management that deserves attention for teams using strict TLS fingerprint allow-listing.

Bot Management and similar DPI systems use JA3 and JA4 fingerprints: hashes derived from TLS ClientHello parameters including cipher suites, extensions, elliptic curves, and elliptic curve point formats. A client sending ML-KEM-768 key shares produces a different JA3/JA4 fingerprint than a client sending a classical X25519 ClientHello, because the key_share extension content and negotiated groups change. If Cloudflare Bot Management is configured with an explicit allow-list of known-good JA3 or JA4 fingerprints, PQC-capable API clients will initially produce fingerprints not on that list and may trigger bot detection rules. This is operationally addressable by updating the fingerprint allow-list to include expected PQC-client fingerprints, but it must be planned for before enabling hybrid TLS on client tooling pointed at Cloudflare-protected APIs.

Cross-gateway considerations: session management, upstream re-encryption, and mTLS

Session ticket lifetime is a configurable trade-off that affects how frequently full PQC handshakes occur. Most API gateways support TLS session tickets with configurable lifetimes (commonly 24 hours by default). A longer session ticket lifetime reduces the frequency of full ML-KEM key exchange operations for clients that maintain persistent connections or connection pools. The trade-off is forward secrecy: a compromise of the session ticket key exposes all sessions within the ticket lifetime. The choice of session ticket lifetime should follow from your security policy's forward secrecy requirements, not purely from a desire to reduce PQC handshake frequency.

For Pattern A deployments where the gateway also re-encrypts upstream connections, PQC adds ML-KEM computation on both the client-facing and upstream-facing TLS sessions. The cumulative CPU cost is manageable but worth including in resource planning. ML-KEM-768 Encaps runs in approximately 0.038 ms on AVX2 hardware (CRYSTALS-Kyber specification benchmarks, Avanzi et al., Round 3). A gateway handling 10,000 new connections per second on both ingress and egress would incur approximately 760 ms total ML-KEM CPU time per second across both TLS layers. On modern server hardware this is well within capacity; on CPU-constrained gateway pods with low resource limits it warrants a check.

mTLS deployments that use client certificates for API authentication will eventually require ML-DSA client certificates in addition to server certificate migration. Client certificate migration has the same IETF LAMPS WG dependency as server certificate migration: ML-DSA Object Identifiers for X.509 are being defined in draft-ietf-lamps-pqc-certificates. For controlled mTLS environments where all clients are organisationally managed (internal service meshes, closed B2B API networks), private CA issuance of ML-DSA client certificates is feasible ahead of public CA support. For externally issued client certificates, the timeline follows public CA adoption of ML-DSA.

Five-step API gateway PQC readiness assessment

Apply this sequence to any gateway deployment before planning a PQC TLS migration:

Step 1: Identify your TLS termination pattern. Is TLS terminated at the gateway (Pattern A), passed through (Pattern B), or mTLS (Pattern C)? Pattern B requires no gateway-layer PQC changes. Document the pattern for each gateway instance.

Step 2: Identify the TLS library. What library does your gateway use: OpenSSL 3.x (Kong, nginx-based), Go crypto/tls (Tyk), BoringSSL (Cloudflare), or s2n-tls (AWS)? Check the library's changelog for FIPS 203 ML-KEM hybrid support and the specific version that introduced it. Platform-managed TLS (AWS API Gateway) requires checking vendor announcements rather than library changelogs.

Step 3: Assess your rate limiting layer. Is rate limiting applied at the TLS connection layer or the HTTP request layer? For the four platforms in this analysis, rate limiting is HTTP-layer in all cases. PQC TLS has no interaction with HTTP-layer rate limiting. If you operate a custom or less common gateway, verify where rate limiting attaches to the request lifecycle.

Step 4: Test through your network path. Deploy hybrid TLS in a staging environment and verify there is no middlebox interference on the path from representative clients to the gateway. Test the ClientHello with a hybrid-capable client using openssl s_client against an OQS-OpenSSL or BoringSSL build and capture results with Wireshark or tcpdump. Include any TLS inspection proxies and WAN appliances on the test path, not just direct connectivity to the gateway.

Step 5: Plan session resumption and connection pooling. For high-connection-rate API clients, connection pooling and session resumption reduce full ML-KEM handshake frequency significantly. Ensure HTTP/2 multiplexing is enabled on persistent clients. Set session ticket lifetimes appropriate to your forward secrecy requirements. Document the trade-off explicitly.