OpenAI API key security: expiry, governance and mTLS

OpenAI shipped three new layers of OpenAI API key security between 29 August and 15 September 2026, and none of them touch a key you already issued. Enforced key lifetimes apply to newly created keys, and the new creation controls leave existing API keys unaffected. This post turns the new controls (expiry, creation governance, mTLS and workload identity federation) into a hardening order, and explains which layer none of them can fix: a key that ships inside a client app.

If you run production traffic on OpenAI, the question is not whether to switch these on. It is what order to do it in, and what an audit of your existing keys has to find first.

What changed between 29 August and 15 September 2026

Three changelog entries in three weeks, all aimed at the same problem: long-lived bearer keys that nobody owns.

Date	Control	What it does
29 August	mTLS and X.509 workload identity federation (GA)	Requests must also present a trusted client certificate; certificates can be exchanged for short-lived tokens
10 September	Key expiry and maximum lifetime	Project keys can carry an expiry date; admins can force new keys to expire within a limit
15 September	Key creation governance	Allow only service-account keys, only user-owned project keys, or no new keys at all

Each row links back to the OpenAI API changelog, which is the primary record. The detail below comes from the production best practices guide and the mTLS and workload identity documentation.

Can OpenAI API keys expire?

Yes, since 10 September 2026. OpenAI now strongly recommends setting an expiration date when you create a project API key and running a regular rotation process. Administrators can enforce a maximum lifetime at organisation or project level, and a project limit cannot exceed the organisation limit.

The catch is in the wording. The maximum lifetime requires newly created keys to expire within the limit. A key created before 10 September without an expiry stays valid, and turning on the policy does not change that. The first job is an inventory, not a setting.

That inventory has its own trap. The same guide notes that keys generated before 20 December 2023 do not have usage tracking enabled by default, and their traffic shows as Untracked. If you cannot see which service uses an old key, you cannot rotate it safely, so enable tracking on those keys and watch for a week before you touch them.

How to rotate OpenAI API keys without an outage

OpenAI's documented sequence is simple: create the replacement before the old key expires, update your applications to use it, and revoke the old key once the replacement is verified. According to the API reference, revocations take effect within a few seconds, so revoke only after traffic has moved. We would add one step: keep the key in a secrets manager and read it at startup or on a short refresh, so rotation is a secret update rather than a redeploy.

Restrict OpenAI API key creation to service accounts

The 15 September control is the one most teams should switch on this week. In the API Key Governance section of Platform settings, administrators can allow only service-account keys, allow only user-owned project keys, or disable new key creation entirely. Organisation restrictions always win; a project can add restrictions but cannot loosen them.

Service-account keys are the right default for production because they belong to the workload rather than to a person. A user-owned key in a production service ties the service's access to one person's account, which is the wrong lifecycle for something that has to outlive team changes. Again, existing keys are unaffected, so the setting only stops the problem growing.

OpenAI mTLS: what it adds and what it does not

Mutual TLS adds client certificate verification to OpenAI API requests. Once you activate a trusted certificate for an organisation or project, every request in that scope must present an accepted client certificate in addition to its normal bearer credential. Traffic goes to mtls.api.openai.com, or the mtls-us and mtls-eu regional hosts.

The important sentence in the guide is that mTLS does not replace API keys, service-account credentials or workload identity tokens. It is a second factor for machines: a stolen key alone no longer works in a project with an active certificate. Four limits are worth knowing before you plan around it:

• OpenAI does not perform CRL or OCSP revocation checks. Incident response is certificate rotation and deactivation.
• Private Link is not compatible with mTLS.
• An organisation can upload up to 50 certificate objects.
• Managing certificates needs the api.mtls.write permission, which the organisation owner role includes.

The guide recommends activating a certificate on a non-critical project first and sending representative traffic from every workload before widening the scope. Treat that as a requirement: a missed workload gets certificate_required errors, not a warning.

OpenAI workload identity federation removes the stored key

Workload identity federation lets a trusted workload use an identity it already has instead of storing an OpenAI API key. The workload presents a short-lived token from your identity provider, and OpenAI exchanges it for a short-lived OpenAI access token mapped to a project service account. Documented providers include Kubernetes, AWS, Azure, Google Cloud, Oracle Cloud, GitHub Actions and SPIFFE.

The X.509 variant uses your mTLS trust anchors. An X.509 workload identity token expires after at most one hour and never outlives the client certificate, and there is no refresh token; you repeat the exchange. OpenAI's own recommendations are a dedicated principal per workload, exact claim matching, least privilege and short token lifetimes.

This is the strongest control of the set, because there is no long-lived secret left to leak. It is also the most work: an identity provider, mappings per service account, and renewal logic in every service. We made the broader case for identity over shared keys in our post on AI gateway model routing, and the same reasoning applies here. For CI pipelines specifically, GitHub Actions federation removes a secret that prompt injection in GitHub Actions could otherwise reach.

Should OpenAI keys be in a mobile app?

No. OpenAI's API reference says not to expose your key in any client-side code such as browsers or apps, and to load it from an environment variable or key management service on the server. The GPT-Live guide repeats the point for voice apps: the browser connects, but the key stays on a trusted server.

This is the layer the new controls cannot patch. A key compiled into a mobile bundle or a frontend build is readable by anyone who installs the app. Expiry shortens how long it works; it does not stop it working. mTLS does not help either, because the client private key would have to ship in the same bundle. The fix is architectural: the app calls your backend, your backend authenticates the user, applies limits, and calls OpenAI. That is how our mobile app development team builds AI features, and it is the first thing we check when an AI engineering engagement starts from an existing app.

An OpenAI API key security checklist, in order

1. Inventory every key, owner and consuming service. Enable tracking on keys from before 20 December 2023.
2. Remove any key from client code. Move calls behind a backend.
3. Turn on creation governance at organisation level: service-account keys only for production projects.
4. Set a maximum key lifetime, then rotate existing non-expiring keys onto expiring ones.
5. Move workloads on Kubernetes, the major clouds or GitHub Actions to workload identity federation.
6. Add mTLS for workloads that can hold a private key securely, starting with one non-critical project.

The order matters more than the list. Steps one to four take days and cover every key you have; steps five and six take longer and cover the keys you will create next. Start with the keys that already exist, because they are the ones no new setting will reach.