Cloudflare Service Keys: Audit Old Automation Before September 30

By Greg Nowak. Last updated 2026-07-21.

Cloudflare Service Key authentication stops working on September 30, 2026. As of July 21, that leaves about ten weeks to find and migrate any automation still sending the X-Auth-User-Service-Key header.

The risk is unlikely to be your newest application. Look instead at the operational glue: DNS update scripts, certificate jobs, deploy hooks, old PHP utilities, CI variables, scheduled tasks, and tools inherited with a client account. These integrations can remain invisible until a deployment, renewal, or recovery procedure needs them.

This should be treated as a small reliability project, not a credential search-and-replace. Each job needs an owner, an appropriately scoped API token, a tested cutover, and a record of where the new secret lives.

What Cloudflare is removing

Cloudflare deprecated Service Key authentication on March 19, 2026. After September 30, API requests using X-Auth-User-Service-Key will no longer be supported. API Tokens are the replacement and add fine-grained permissions, resource scoping, expiration, IP restrictions, and independent revocation.

Origin CA keys are part of the same cleanup. They commonly begin with v1.0- and are passed in the Service Key header when scripts call the Origin CA certificates API. Cloudflare says these keys can reach every account available to the user; their replacement for certificate operations is an API token with Zone → SSL and Certificates → Edit.

If you use cloudflared, Cloudflare advises running a version from November 2022 or later because those versions use API Tokens. Teams using origin-ca-issuer need a release that supports API Token authentication.

Find the dependency before choosing the token

Start with repositories, deployment directories, CI configuration, cron definitions, infrastructure code, and secret stores. The following searches retain their value:

rg -n 'X-Auth-User-Service-Key|v1\.0-' .
rg -n 'origin-ca|/certificates|cloudflare' .

A match is only the beginning. Record what the job changes, which account and zones it reaches, where it runs, how frequently it runs, who notices failure, and where its credential is injected. Also search CI and hosting dashboards: a legacy secret may not appear in source control at all.

Do not assume that every result is active. Conversely, do not delete an old credential merely because nobody recognizes it. Trace the caller, inspect recent job logs where available, and identify a safe test before changing production access.

Choose the narrowest practical token

Cloudflare separates permissions from resources. A DNS updater may need Zone DNS Edit, but only for one named zone. A reporting job may need Zone DNS Read. An Origin CA workflow needs certificate permissions, not general DNS access.

Use one token per automation as a sensible default. This makes ownership, rotation, and revocation clearer and prevents a leak in one client workflow from exposing unrelated sites.

Account API tokens act as service principals and are not tied to an employee. Cloudflare positions them for durable integrations such as CI/CD, although endpoint compatibility must be checked. Creating one requires Super Administrator permission. User tokens remain useful for ad hoc work performed on behalf of a particular administrator.

Where the runner has stable egress, consider an IP restriction. Set an expiration where rotation is operationally realistic. Cloudflare shows the token secret only once, so place it directly in a secret manager, CI variable store, or platform vault—never in a repository or shared operations note.

Test activity, scope, and the real job

For a user-owned token, Cloudflare provides this status check:

curl "https://api.cloudflare.com/client/v4/user/tokens/verify" \
  --header "Authorization: Bearer <API_TOKEN>"

For an account-owned token, use the account-specific verification endpoint:

curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/tokens/verify" \
  --header "Authorization: Bearer <API_TOKEN>"

An active response confirms that the credential works; it does not prove that its permissions and resources fit the job. Follow it with an endpoint-level smoke test. For read access, request the expected resource and confirm an unrelated zone is denied. For write access, use a controlled change with a documented rollback. Then run the automation from its real environment so you also test secret injection, network restrictions, and runtime configuration.

A workable migration sequence

1. Inventory headers, key patterns, helpers, scheduled jobs, and externally stored variables.
2. Map each active caller to its business purpose, owner, account, zones, and required operations.
3. Create a separately named, minimally scoped token with suitable ownership and restrictions.
4. Deploy it alongside a rollback plan and test from the actual runtime.
5. Remove the old header, monitor the next normal run, and revoke the legacy key only after dependencies are accounted for.
6. Record the token owner, scope, storage location, expiry, and rotation procedure.

The deadline creates urgency, but the payoff lasts longer: fewer shared secrets, clearer operational ownership, and automation that is easier to support.

Need a second pair of eyes?

If your Cloudflare setup spans client accounts, older certificate tooling, or several deployment systems, Greg can help inventory the dependencies, design sensible token scopes, and manage a tested cutover. Discuss your Cloudflare token audit with Greg.

Related on GrN.dk

• Cloudflare Service Keys Stop in September: Find Every Caller
• Background AI Tasks Need Queues, Not Just Longer API Calls
• Cloudflare Resource Tagging Beta: Labels With Governance Consequences

Need help with this kind of work?

Discuss your Cloudflare token audit with Greg Get in touch with Greg.

Sources

• API deprecations
• Get Origin CA keys
• Create API token
• Account API tokens
• Account token verification API