OpenAI API Key Governance: Creation Rules, Ownership, Expiration, and Zero-Downtime Rotation

You are about to add expiration rules to OpenAI API keys, but you do not want a policy change to take down an application—or to discover at the next rotation that the required replacement key can no longer be created. You may also be deciding whether production should use service-account keys while developers keep user-owned keys.

This guide gives you a practical order of operations: choose ownership by workload, set a lifetime your team can actually rotate within, then replace old keys through a controlled overlap. Keep two facts in mind from the start: new creation rules do not change existing keys, and organization restrictions override project settings.

Start with the answer: the new controls govern future keys, not old ones

You can treat the September changes as two controls: which new key types may be issued, and how long newly created project keys may remain valid.

Date	OpenAI update	Operational meaning
September 10, 2026	Project API keys can be created with expiration dates. Administrators can enforce a maximum key lifetime at the organization or project level.	Newly issued keys can be required to expire, so teams need a repeatable rotation process before enforcing a short lifetime.
September 15, 2026	Organizations and projects can restrict new key creation to service-account keys, restrict it to user-owned project keys, or disable all new API key creation.	Production workloads, individual development, and frozen projects can use different issuance rules.
September 15, 2026	Organization restrictions take precedence over project settings.	A project may tighten the organization rule, but it cannot use its own settings to relax an organization-wide restriction.
September 15, 2026	Existing API keys are unaffected by the new creation controls.	Turning on a rule does not revoke old credentials and does not complete legacy-key cleanup.

Two boundaries matter. First, “disable new key creation” is not the same as “revoke every existing key.” Second, the September 10 description applies the maximum-lifetime requirement to newly created keys. Do not assume that an old key will receive a retroactive expiration date unless you verify that behavior in the actual project.

Separate three decisions: who can create, how long keys live, and how they exit

Design these three decisions separately; one Platform switch cannot complete key governance for you.

Issuance policy determines whether a project can create service-account keys, user-owned project keys, or no new keys at all.

Expiration policy determines whether a new key must expire and the longest lifetime permitted by organization and project rules.

Lifecycle execution determines who creates a replacement, where the secret is stored, how applications receive it, how the transition is validated, when the old key is revoked, and how a failed rollout is rolled back.

The first two can be constrained in the OpenAI Platform. The third still depends on your secret manager, deployment process, observability, ownership model, and incident procedures. Enforcing a maximum lifetime without assigning a rotation owner or allowing enough time for deployment converts a security control into a scheduled outage.

Choose by workload: service accounts for production, user-owned keys for personal development

Prefer a service-account key for production and shared workloads, a user-owned project key for local or short-term work, and disabled issuance only for projects that are genuinely frozen or retiring.

Workload	Usually better suited to	Why	Main risk to manage
Production service, shared backend, scheduled job, team-operated agent	service-account key	The credential belongs to the workload rather than one employee, so staff changes do not determine application continuity.	A single service account used by many unrelated applications creates a large blast radius. Split by project or workload.
Local development, short-lived debugging, exploratory script	user-owned project key	Ownership and individual accountability are clear, and offboarding can include the user’s credentials.	A personal key must not quietly become a shared production dependency.
Archived, decommissioning, or temporarily frozen project	Disable new key creation	Prevents the credential inventory from growing while the project is closed or reviewed.	Freezing issuance too early may block creation of a replacement key needed for rotation or recovery.

A useful test is: should this application continue running after a particular employee leaves the team? If the answer is yes, a production credential generally should not depend on that employee’s user account. Conversely, giving every developer a shared service-account key weakens attribution and spreads the same secret across more machines.

Neither key type is inherently safe on its own. Scope, storage, access control, lifetime, rotation, logging, and revocation determine the practical risk. A long-lived service-account key copied into dozens of workloads remains a serious single point of exposure.

Organization policy is the ceiling: projects may tighten it, not relax it

An organization restriction is the ceiling for every project, so verify the next rotation before you apply it broadly.

Suppose the organization allows only service-account keys. A development project cannot override that rule and start issuing user-owned project keys. A project can usually be made more restrictive within the organization boundary, but it cannot make the organization policy more permissive.

Before changing an organization-wide rule, perform this sequence:

1. List all projects and classify them as production, staging, development, testing, temporary, archived, or decommissioning.
2. Record the key type each project will need at its next rotation, not merely the types it has today.
3. Identify the replacement credential needed by every active workload and confirm that the proposed organization rule permits its creation.
4. Rehearse creation, deployment, validation, and revocation in a low-risk project.
5. Apply the organization restriction only after the rehearsal proves that normal rotation remains possible.

Because existing keys continue to work, an overly strict organization rule may look harmless on the day it is enabled. The failure appears later, when a key nears expiration and the team discovers that policy prevents it from creating the correct replacement. Test the next rotation before relying on the current application’s continued success.

Do not pick one lifetime for everything: start with the time a real rotation takes

Set the maximum lifetime longer than the full time needed to approve, issue, distribute, deploy, observe, and roll back a replacement.

For each project class, define at least the following:

Policy field	Question it must answer
Maximum lifetime N	How long may a newly created key exist from issuance to expiration?
Rotation lead time R	How long before expiration must replacement work begin?
Primary and backup owner	Who is responsible, and who acts if that person is unavailable?
Distribution method	Can the application load a new secret version, or does it require restart/redeployment?
Validation evidence	Which requests, logs, error rates, and usage signals prove that the new key is carrying traffic?
Rollback window	How long is the old key retained after cutover to allow safe recovery?
Exception process	Who may approve an extension, for how long, and with which compensating controls?

R must cover the whole path, including approvals, secret distribution, phased deployment, observation, and rollback. A very short lifetime paired with manual copy-and-paste, cross-time-zone approval, and no backup owner is less reliable than a somewhat longer lifetime backed by automated reminders and a practiced rotation runbook.

Use the organization-level maximum as a common ceiling. High-risk projects can adopt a shorter project-level limit, but a project should not be able to exceed the organization rule. Production services, personal development, temporary tests, and retiring projects may need different internal standards because their owners, impact, and recovery speed differ.

Use this seven-step overlap to rotate without downtime

The safest pattern is to run old and new keys briefly in parallel, then revoke the old key only after real traffic proves the cutover.

1. Build an inventory of current keys

Record the project, key ownership type, workload, application, environment, accountable owner, secret-storage location, deployment method, creation date, known expiration date, and last observed usage. A key with unknown purpose or owner should enter a high-priority investigation queue; do not start with blind bulk revocation.

OpenAI’s August 4, 2026 changelog entry says the Usage and Costs dashboards, Usage API, and Costs API support filtering and grouping by API key. That key dimension can help establish whether a credential is still generating requests. It is only one piece of evidence: low-frequency batch jobs, disaster-recovery paths, and monthly workflows may remain idle for long periods.

2. Create a compliant replacement

Create a new key in the intended project, using the ownership type permitted by current organization and project rules. Give it an expiration date that does not exceed the applicable maximum lifetime. Confirm the issuance rule before the maintenance window rather than discovering a conflict during deployment.

3. Store it as a new secret version

Do not overwrite the only copy of the old value immediately. Keep the old and new secret versions during the controlled transition, with clear states such as “current production,” “rotation candidate,” and “pending revocation.” Do not place keys in source code, container images, deployment tickets, logs, or chat messages.

4. Shift traffic gradually

Start with one instance, one low-risk job, or a small percentage of traffic. Verify authentication, expected project attribution, permissions, and request behavior before expanding the rollout. If an application reads the key only at startup, schedule restarts and capacity so the rotation itself does not reduce availability.

5. Observe both application health and key-level usage

Check successful requests, authentication failures, rate-limit errors, latency, and business-level results. At the same time, verify that the new key begins producing the expected usage and that old-key usage falls. A successful deployment event is not proof that traffic has moved.

6. Keep a time-bounded rollback window

Retain the old key for a predefined observation period after the new key is stable, then revoke it. The window must be long enough to cover delayed workers, multiple regions, and low-frequency tasks, but it must not remain open indefinitely. Permanent dual-key operation doubles the number of valid secrets without delivering a completed rotation.

7. Revoke, verify, and schedule the next rotation

After revocation, confirm that attempts with the old key fail and that the new key continues to succeed. Update the inventory, on-call notes, owner, expiration date, and next rotation deadline. Do not wait until the final days of the new key’s life to rediscover the process.

Legacy keys do not become compliant automatically: migrate them by risk

After you enable the new rules, you still need a separate migration queue for old keys because they keep their existing ownership and lifetime.

Create a separate migration queue and prioritize it by risk:

1. credentials known to have appeared in source code, tickets, logs, or chat;
2. keys whose owner or purpose cannot be identified;
3. user-owned keys associated with people who left or changed roles;
4. keys shared by multiple production applications and therefore difficult to revoke independently;
5. broad-scope or high-impact keys;
6. keys with a clear owner, a single workload, and a tested replacement path.

Do not measure success by revoking every old key on the same date. A safer completion criterion is that each legacy key has a known workload map, an approved replacement, cutover evidence, and a revocation deadline. For a key that cannot yet be migrated, document the exact blocker, owner, compensating control, and expiry of the exception. “Legacy system” is not a permanent risk treatment.

Your internal policy needs at least these 11 fields

An executable policy must name the rule, owner, validation evidence, rollback window, and revocation condition—not just a maximum lifetime.

Policy item	What to record
Scope	Organization, project, environment, and workload classes covered by the policy
Allowed new-key type	Service-account only, user-owned project only, or no new keys
Rationale	Continuity, individual accountability, project freeze, or another documented reason
Maximum lifetime	Organization ceiling and any stricter project limit
Rotation lead time	When an alert or work item must be created before expiration
Secret storage	Approved secret manager and access roles
Deployment	Canary or phased method, restart requirements, and rollback procedure
Evidence	Successful requests, error metrics, key-level usage, and old-key traffic reaching zero
Revocation condition	New key stable, delayed jobs covered, rollback window closed
Exception approval	Approver, reason, compensating control, and exception expiration
Audit trail	Creation, policy change, deployment, revocation, and ownership changes

Assign long-term accountability to a workload or team role, while still naming the person executing the current rotation. “The platform team owns it” is not operational unless the policy also defines an on-call path, deadline, and escalation.

Before enforcement, rehearse the next rotation

Enable organization or project restrictions only after you can answer every item below and complete a low-risk rehearsal.

• every active application maps to a specific project and credential;
• each project’s next required key type is known;
• the organization rule will not prevent a critical workload from creating its replacement;
• production does not depend on one employee’s personal credential;
• the secret store supports versioning or another reliable rollback mechanism;
• the application has been tested to load a new secret, including any restart requirement;
• the team can observe usage or cost by API key and has accounted for low-frequency jobs;
• primary and backup rotation owners are assigned;
• expiration alerts arrive early enough to complete the runbook;
• old-key revocation criteria are explicit, so overlap does not become permanent; and
• each unresolved legacy key has a concrete blocker, owner, and deadline.

Frequently asked questions

Will a new creation restriction immediately break existing applications?

According to OpenAI’s September 15, 2026 changelog entry, existing API keys are unaffected by the new creation governance controls. Changing which new keys may be created does not automatically revoke the credentials already used by applications. The rule can still affect the next rotation, so replacement-key creation should be rehearsed in advance.

Does a maximum lifetime retroactively expire old keys?

The September 10 update describes the maximum lifetime as a requirement for newly created keys. Do not assume it retroactively adds expiration dates to legacy credentials. Verify the actual key details and migrate old keys through a separate process.

Can a project administrator relax an organization-level restriction?

No. The release note says organization restrictions take precedence over project settings. Project policy must remain within the organization boundary.

Should an organization allow only service-account keys?

Use service-account keys first for production services, shared backends, scheduled jobs, and team-operated agents. Use user-owned project keys first for local development and short-lived exploration. An organization-wide service-account-only rule makes sense only when nearly every project fits the first group and development projects already have a workable alternative.

When should a project disable all new key creation?

Typical cases include an archived or decommissioning project, or a temporary freeze during a security investigation. Confirm first that the project will not need a replacement key for rotation or recovery; otherwise the freeze can obstruct the response it was meant to support.

What proves that an old key is safe to revoke?

Use combined evidence: rollout state, successful requests with the new key, error monitoring, key-level usage, execution of low-frequency jobs, and completion of the rollback window. A short interval with no traffic is usually insufficient on its own.

What to do first

Start with three actions: record the key type each project will need at its next rotation, complete one overlap rotation in a low-risk project, and only then enforce organization and project restrictions.

The order matters. If you set the ceiling first, current applications may keep working while the policy quietly blocks the replacement key you will need later. Prove that the next rotation works before you tighten the rules.

Official source:

• OpenAI API Changelog: September 10 and September 15, 2026 updates