PERMISSIVE lets a workload accept both mutual TLS and plaintext, which suits a migration. STRICT accepts only mutual TLS. Start permissive, move every client onto sidecars, check that no plaintext traffic remains, then switch to STRICT namespace by namespace. Leaving PERMISSIVE in place means mTLS is optional, not enforced.
The three modes
Istio's security documentation describes the PeerAuthentication policy and its mutual TLS modes:
| Mode | Behaviour |
|---|---|
| PERMISSIVE | Workloads accept both mutual TLS and plaintext traffic. Useful during migrations when some workloads have no sidecar. |
| STRICT | Workloads accept only mutual TLS traffic. |
| DISABLE | Mutual TLS is turned off. The documentation says not to use it unless you provide your own security solution. |
If the mode is unset, a policy inherits from its parent scope. Mesh-wide policies with an unset mode use PERMISSIVE by default. So an Istio mesh that nobody tuned accepts plaintext.
Why this matters
Teams often say "we run a service mesh, so traffic is encrypted." With default PERMISSIVE, a client that bypasses the sidecar, or a pod without one, can still talk plaintext to your service. mTLS between services is only a guarantee once STRICT is in force for that workload.
A safe migration order
- Inventory which workloads have sidecars and which do not. A pod without a sidecar cannot speak mTLS to a STRICT workload.
- Keep the mesh in PERMISSIVE while you inject sidecars into the remaining workloads.
- Use the observability tooling to find who still sends plaintext. Istio's migration task points to a Grafana dashboard showing which workloads still send plaintext to PERMISSIVE workloads.
- Fix or retire each plaintext sender.
- Apply STRICT to one namespace first, ideally a low risk one.
- Watch error rates and connection resets, then continue namespace by namespace, then mesh-wide.
- Keep a rollback ready: reverting a policy to PERMISSIVE restores plaintext acceptance quickly.
apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata:
name: default
namespace: foo
spec:
mtls:
mode: STRICT
This follows the documentation's example of requiring all workloads in a namespace to use mutual TLS.
Port level exceptions
Workload specific policies can set different modes per port, but only on ports the workload has claimed. Use this sparingly, for a health check port or a legacy client. Record each exception with an owner and an end date.
What Istio handles for certificates
The documentation says Istio provisions X.509 identities to every workload. Istio agents work with istiod to automate key and certificate rotation at scale, creating the private key, sending a signing request, and delivering the result to Envoy over SDS. The agent watches expiry and repeats the process. Your job is mostly the policy and the plaintext holdouts, not manual rotation. See SDS and rotation without redeploys.
Common surprises
- Jobs and cron pods without sidecars calling STRICT services.
- External traffic through a gateway, which is a separate policy question.
Where Safeguard fits
Safeguard does not operate your mesh. It offers policies and gates that can review manifests in pull requests, plus SBOM and dependency scanning. See the framework mapping demo for how controls are tied to evidence.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how a technical control such as encryption in transit is mapped to the framework requirement it supports.
Quick check
What is the default mode for a mesh-wide policy?
An unset mode on a mesh-wide policy uses PERMISSIVE, so plaintext is accepted unless you change it.
Is DISABLE ever appropriate?
The documentation advises against it unless you bring your own security solution.
Can I mix modes in one workload?
Yes, per port, for ports the workload has claimed.
Sources
Last reviewed: 19 October 2026.
