On Jan 16, 2026 Google Cloud launched the Public Preview of Managed Workload Identity (MWLID) support for Backend mTLS in Global External Application Load Balancers. This advancement enables organizations to move away from manual operational toil toward automated, identity-centric security, facilitating a more robust Zero Trust environment.
What is MWLID for Backend mTLS?
Backend mTLS ensures that a Load Balancer authenticates itself to your backend workloads, creating a mutual chain of trust. Traditionally, implementing this at scale required manual certificate provisioning, complex private key generation, and “fire-drill” maintenance to rotate certificates before they expired.
MWLID solves these challenges by automating the entire lifecycle of these identities. Instead of a human operator managing files, the Load Balancer itself requests client SSL certificates from a Private Certificate Authority (CA).
-
Fully automatic: MWLID handles the issuance, management, and rotation of certificates without manual intervention.
-
Frequent rotation: To maintain a high security posture, certificates are automatically rotated every 24 hours, eliminating the risk of outages due to expired credentials.
-
Identity-centric: It moves security away from brittle IP allow-lists and toward strong, cryptographic identities.
Understanding the SPIFFE ID
At the heart of MWLID is SPIFFE, which is an open standard (https://spiffe.io) designed to provide interoperability between systems including cross-cloud environments. A SPIFFE ID is a URI structured as:
spiffe://<trust_domain>/:
-
Trust domain: Represents your security boundary, such as your Workload Identity Pool.
-
Path: Uniquely identifies the specific service using Namespaces and Service Accounts (e.g., ns/prod/sa/lb-client).
This allows your backend services to verify exactly which specific entity is connecting, rather than just seeing a “trusted client”. When the Certificate Authority Service (CAS) issues an identity document (certificate) to the Load Balancer, it includes a SPIFFE ID embedded in the certificate’s Subject Alternative Name (SAN) field.
The power of simple configuration
The primary benefit of MWLID is that it decouples security from network topology. The configuration is remarkably simple because the heavy lifting—the “plumbing” of certificate management—is handled by the infrastructure. To enable this, you only need to provision a specific identity on the backend service. Everything else, from certificate signing to 24-hour rotations, happens automatically.
Load Balancer example configuration:
gcloud beta compute backend-services create BACKEND_SERVICE_NAME \
--load-balancing-scheme=EXTERNAL_MANAGED \
--protocol=HTTPS \
--health-checks=HEALTH_CHECK_NAME \
--identity='//dev1.global.123245.workload.id.goog/ns/prod/sa/lb-client' \
--global
By using this single --identity flag, you transition from a manual, error-prone process to a Zero Trust environment where every connection is cryptographically verified and automatically managed.
Configuration flow
The provisioning flow for Managed Workload Identity (MWLID) transitions backend security from manual certificate handling to a streamlined, automated pipeline. To begin, administrators must establish the foundational security infrastructure by configuring a Trust Domain within IAM and a Private CA Pool in the Certificate Authority Service (CAS). Once the environment is prepared, you configure the backend service using the --identity flag, which assigns a unique SPIFFE ID to the workload. With this configuration in place, the automation engine takes over: it requests a certificate from the Certificate Manager, which coordinates with CAS to sign it. Finally, the system automatically attaches this signed certificate to the Backend Authentication config and incorporates the Trust Config, enabling seamless inter-domain trust validation and ensuring the load balancer can securely authenticate to your backends without manual rotation.
Please consult documentation to see more details.
If you’re interested in testing, you may try following Terraform