OpenAI made mutual TLS and X.509 workload identity federation generally available on August 29, 2026, according to the API changelog. These capabilities give service operators certificate-based identity options. They solve different parts of authentication, so a deployment needs to choose deliberately between strengthening transport authentication and replacing long-lived API keys with federated credentials.
mTLS adds a certificate requirement to API authorization
The mTLS guide requires a trusted client certificate as well as normal bearer authorization. Uploading a trust chain is distinct from activating its enforcement. An operator must also use the supported mTLS endpoint rather than assume every API hostname enforces the certificate policy.
That distinction creates a rollout responsibility. Before activation, identify each caller and test its certificate presentation on the intended host. After activation, confirm that a caller without the required certificate is rejected. Testing only the successful path leaves the central control unverified.
X.509 federation changes how the bearer token is obtained
With X.509 workload identity federation, certificate identity is exchanged for a short-lived bearer token and mapped to a project service account. The certificate and the token have separate roles; replacing a static key does not remove authorization checks on the identity that receives the token.
Choose a stable workload identity and a narrowly scoped service account. A certificate shared across unrelated services would make attribution and revocation harder. If one service fails a security review, operators should be able to suspend its access without interrupting every workload using the same identity.
Certificate lifecycle work remains with the operator
The mTLS documentation says the service does not perform certificate revocation checks through CRL or OCSP. Certificate expiry alone is therefore an incomplete response plan. Operators need to understand how trust deactivation and credential rotation affect the clients they run.
Exercise renewal before the first expiry event. Test overlapping valid credentials, incorrect chains and a revoked organizational identity in a nonproduction workflow. Keep private keys out of application logs and ensure that a token-exchange failure remains observable rather than falling back silently to a forgotten static key.
Adopt the feature when ownership is clear
The strongest use case is an organization that already operates workload certificates and can manage identity issuance, service account permissions and incident response together. Adding certificates without that ownership can introduce another outage mechanism without improving control over the callers.
Measure success through verified access boundaries: which workload authenticated, what it was authorized to do, whether invalid identities were blocked, and how quickly access could be withdrawn. General availability makes the feature usable for supported integrations; it does not certify the security of a particular deployment.