AWS’s October 30, 2026 announcement adds opt-in TLS 1.3 security policies for Amazon MSK Provisioned clusters. Existing clusters do not change until a policy is applied. The important operational distinction is between allowing TLS 1.2 alongside TLS 1.3 and guaranteeing that every client can recover from a failed handshake.
What a mixed policy permits
The announcement explains that a policy accepting both protocol versions lets compatible clients negotiate TLS 1.3 while TLS 1.2 clients continue using TLS 1.2. A stricter policy can require TLS 1.3. Neither description establishes which policy your own cluster currently uses.
AWS’s TLS-policy guide names the mixed policy MSK-TLSv1.3-2026 and the stricter option MSK-TLSv1.3-Only-2026. It explicitly says that if a client negotiates TLS 1.3 and its handshake fails, the connection does not fall back to TLS 1.2. A faulty TLS 1.3 implementation can therefore fail under the mixed policy even though TLS 1.2 remains allowed.
Use a fictional client worksheet
Imagine an invented staging exercise with two applications. Application A is configured to use TLS 1.2 only. Application B advertises TLS 1.3 but fails during that handshake. Under the documented mixed-policy behavior, A’s older protocol is permitted; B’s failure is not automatically rescued by retrying TLS 1.2. This is a hypothetical explanation, not a measured MSK result.
Now add Application C, whose capability has not been checked. Mark it unknown. Do not infer its readiness from A’s successful connection or B’s library version. Your worksheet should identify each application’s actual runtime and network path, then attach the observed test result rather than filling gaps with assumptions.
Test the path, not just the advertised version
The guide recommends trying the mixed policy on a non-production cluster first and checking clients, tools and intermediaries. It calls out client TLS libraries and any firewall, proxy, load balancer or inspection appliance in the path.
For your own trial, record the cluster configuration revision, application build, connection path and test time together. A result without that context is hard to reproduce. Define what counts as success before starting: establishing a connection and completing the intended application operation are separate observations worth recording.
Keep the next change tied to evidence
An inventory is useful only if it includes less visible connections. Ask the application owners which scheduled jobs, administrative tools and occasional consumers also use the cluster. Give every unchecked item an owner and a next test, rather than treating the busiest producer as representative of the entire system.
Before a stricter policy is considered, review the unresolved rows and current AWS policy-transition guidance. Keep the previous configuration available and distinguish a planned recovery procedure from one your team has actually exercised. This article provides no production command sequence and makes no claim that a particular cluster or client has passed testing.
Primary sources
- AWS announcement, October 30, 2026: https://aws.amazon.com/about-aws/whats-new/2026/10/amazon-msk-tls/
- AWS Developer Guide, TLS security policies for Amazon MSK, readable AWS China documentation host: https://docs.amazonaws.cn/en_us/msk/latest/developerguide/msk-tls-security-policies.html
Check the mixed-policy assumption
