Minimum TLS Protocol Version

SecuritySetting.authenticationSettings.minProtocolVersion lets you set a minimum TLS protocol version once — on an Organization, Tenant, Workspace or Security Group — and have it enforced on every proxy in the namespaces that setting selects. It covers both data plane roles: gateway servers and sidecars.

The value is a floor with mandate semantics: a gateway server may configure a stricter minimum of its own, but a weaker one is raised to the mandated value. It only affects TLS that a proxy actually terminates — TLS passthrough, ISTIO_MUTUAL and plaintext servers are never touched, and client-originated (outbound) TLS is out of scope, since Istio exposes no minimum-version field for that side.

Feature flag

This feature must be enabled with the ENABLE_MIN_TLS_VERSION flag on XCP Edge — see below. It is disabled by default.

Enable the feature

Edit the xcp component in the ControlPlane CR or Helm values, and add an environment variable ENABLE_MIN_TLS_VERSION with value true:

apiVersion: install.tetrate.io/v1alpha1
kind: ControlPlane
metadata:
  name: controlplane
  namespace: istio-system
spec:
  components:
    xcp:
      kubeSpec:
        deployment:
          env:
            - name: ENABLE_MIN_TLS_VERSION
              value: "true"

Set a minimum TLS version

Set authenticationSettings.minProtocolVersion on a SecuritySetting, or on the defaultSecuritySetting of an OrganizationSetting, TenantSetting or WorkspaceSetting, following the same configuration hierarchy as the rest of authenticationSettings:

apiVersion: security.tsb.tetrate.io/v2
kind: SecuritySetting
metadata:
  name: tls-floor
  group: bookinfo-sg
  workspace: bookinfo-ws
  tenant: tetrate
spec:
  authenticationSettings:
    minProtocolVersion: TLSV1_3

Value	Effect
TLS_AUTO (default)	No floor. Each proxy keeps whatever minimum it would otherwise use.
TLSV1_0, TLSV1_1	Floor of TLS 1.0 / 1.1. Both sit below the TLS 1.2 that Istio's mesh mTLS uses by default, so setting either one actually lowers the sidecar floor rather than raising it — exactly as it would on a gateway server.
TLSV1_2	Floor of TLS 1.2.
TLSV1_3	Floor of TLS 1.3.

What is affected

Data plane role	Mechanism	In scope
Gateway servers	The mandate is applied directly to the server's minProtocolVersion (and, if needed, maxProtocolVersion) in the generated Istio Gateway. Applies to gateways in both BRIDGED and DIRECT config mode.	SIMPLE, MUTUAL and OPTIONAL_MUTUAL servers only
Sidecars	A generated, namespace-wide EnvoyFilter named min-tls-version-sidecar, patched onto inbound filter chains that actually terminate TLS	Every sidecar in the selected namespaces, except ambient workloads

Not affected, in either role:

• TLS passthrough servers — a passthrough server matches on SNI and forwards the encrypted bytes without completing a handshake, so there is no version for the gateway to enforce.
• ISTIO_MUTUAL servers — Istio's own mTLS stack chooses the protocol version for these; XCP leaves them untouched.
• Plaintext servers — never given TLS settings just to carry a floor.
• Ambient-mode workloads — ztunnel and the waypoint HBONE path already negotiate TLS 1.3 exclusively and don't read EnvoyFilters, so they need no configuration. Gateways in ambient namespaces are still covered, since they terminate TLS like any other gateway.
• Client-originated (outbound) TLS — a gateway originating TLS towards an upstream is unaffected; Istio has no minimum-version field on that side of a connection.

Interaction with a gateway's own TLS settings

A gateway server that already sets tls.minProtocolVersion (and optionally tls.maxProtocolVersion) keeps that setting if it's at least as strict as the mandate. Otherwise TSB raises it and reports an advisory on the gateway:

Advisory	Reported when
TLS001	A server's minProtocolVersion was weaker than the mandate and has been raised to it. A server that sets no minProtocolVersion at all — the usual shape for a hand-written DIRECT mode Gateway — simply inherits the mandate without a warning.
TLS002	A DIRECT mode server uses a TLS mode the mandate can't be applied to (anything other than SIMPLE, MUTUAL or OPTIONAL_MUTUAL).
TLS003	A server's maxProtocolVersion was pinned below the mandate. Raising only the minimum would leave min > max, an invalid range Envoy rejects, so the maximum is raised too.

A TLS001 advisory looks like this in tctl output:

warnings:
  - message: 'minProtocolVersion TLSV1_2 on server "httpbin1" was ignored: the security
      setting for namespace "httpbin-gateway" mandates a minimum of TLSV1_3.'
    ruleId: TLS001

Using configuration profiles

minProtocolVersion is also available under authenticationSettings in a Configuration Profile, alongside trafficMode. This lets a platform team hand a TLS floor down through the profile hierarchy instead of repeating it on every SecuritySetting.