Cloudflare Service Keys Stop in September: Find Every Caller

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

Cloudflare Service Key authentication stops working on September 30, 2026. From that date, requests using the X-Auth-User-Service-Key header will no longer authenticate. Integrations need to use API tokens with the permissions required for their work.

The credential change itself is usually the easy part. The harder question is whether you have found every caller.

A Service Key might be sitting in certificate automation, a Kubernetes secret, Terraform variables, a scheduled CI job or a script that runs twice a year. Miss one of those and the migration can look finished right up to the moment an unattended process tries to create or renew a certificate.

Treat this as an inventory and ownership job first. Find every caller, establish what it does, move it to an appropriate token and test the real operation. Retire the Service Key only when each dependency is accounted for.

A direct credential swap leaves the main risk untouched

Cloudflare describes Origin CA keys as Service Keys. Integrations commonly send them in the X-AUTH-USER-SERVICE-KEY header when calling the Origin CA certificates API, and a Keyless SSL key server can use them too. The key value starts with v1.0-, which gives you another useful search signature.

The old credential also has a wide reach. Cloudflare states that an Origin CA key can access every account available to its user. API tokens support finer permissions, expiration and revocation. For Origin CA certificate operations, Cloudflare specifies Zone – SSL and Certificates – Edit.

That does not mean replacing one broad shared secret with one broad shared token. Where practical, give each integration its own token, limited to the resources and permissions it actually needs. Separate credentials are easier to assign, rotate and revoke without disturbing unrelated systems.

Search for fingerprints, not just Cloudflare applications

Asking which applications use Cloudflare will uncover the obvious systems. It can still miss a generic deployment job, an archived repository that remains connected to production or a credential injected outside the application repository.

Search every place that can hold code, configuration or secrets for these fingerprints:

X-Auth-User-Service-Key and X-AUTH-USER-SERVICE-KEY.
Secret values or secret-scanning matches beginning with v1.0-. Treat every match as sensitive; do not paste exposed values into tickets or reports.
The Terraform provider setting api_user_service_key and the environment variable CLOUDFLARE_API_USER_SERVICE_KEY.
Kubernetes OriginIssuer and ClusterOriginIssuer objects using .spec.auth.serviceKeyRef.
Scripts, pipelines and infrastructure modules that create Origin CA certificates.

Cover active and archived repositories, CI/CD configuration, host environment files, systemd units, cron jobs, container definitions, Kubernetes manifests and live objects, infrastructure inputs, and the secret stores behind those systems. Search in a way that does not print credential values into shell history or shared logs.

Use a caller register to expose gaps

Each match belongs in a migration register, including repeated references to the same credential. One shared key used by five callers means five pieces of work. Each caller also needs an owner who understands the integration and can approve a meaningful test.

Caller	Legacy fingerprint	Required change	Evidence it works
Custom client or script	Service Key header or secret beginning with `v1.0-`	Use a scoped API token through the supported token authentication method	Run the actual operation and confirm the expected Cloudflare result
Terraform	`api_user_service_key` or `CLOUDFLARE_API_USER_SERVICE_KEY`	Configure `api_token` or `CLOUDFLARE_API_TOKEN`	Review a clean plan, then complete a controlled apply or equivalent functional check
Kubernetes origin-ca-issuer	`.spec.auth.serviceKeyRef`	Upgrade to a token-capable release and update issuer authentication	Confirm issuer health and safely test certificate issuance or renewal
CI or scheduled job	Legacy variables, injected secrets or constructed headers	Replace the stored secret and update the job configuration	Run the Cloudflare-dependent part of the job
Keyless SSL key server	Origin CA key referenced by its configuration	Plan the supported API-token replacement for the integration	Validate the relevant operational workflow before removing the key

A practical migration register: every legacy fingerprint leads to an owner, a change and observable proof.

Add the repository or runtime location, affected Cloudflare resource, token owner, permission set, deployment status, test evidence and rollback decision. A merged code change is not proof that the running caller has migrated. Neither is a successful build.

Check Kubernetes configuration and the running cluster

The origin-ca-issuer v0.14.0 release helps with discovery. It identifies OriginIssuer and ClusterOriginIssuer resources that use .spec.auth.serviceKeyRef. Its controller also emits a log line when it encounters an issuer configured with an Origin CA Service Key, and the release directs operators to move those issuers to API tokens.

Check both sources of evidence. Git may show the intended state while the cluster still runs an older object. Conversely, a live object may have been changed manually and never committed. Give cluster-scoped issuers extra attention because their effect can extend beyond a single namespace.

Upgrade the controller through the project's normal release process, review the legacy issuers it reports and update authentication deliberately. Verification should reach the certificate workflow itself. A healthy pod or an accepted manifest does not prove that issuance and renewal work.

Terraform credentials may be outside the repository

The current Cloudflare Terraform provider documentation includes both api_user_service_key and the preferred api_token configuration, along with their environment-variable equivalents. Only one of api_key, api_token and api_user_service_key can be supplied to the provider.

A clean repository search is therefore not enough. The provider block may show no credential because authentication comes from the execution environment. Inspect CI secret mappings, Terraform workspace variables, runner configuration and variable definitions as part of the same caller record.

After changing authentication, review the plan for unexpected differences. Then test the Cloudflare operation the configuration is supposed to perform. Successful provider initialization shows that the configuration is acceptable; it does not necessarily show that the token can change the intended resource.

Give each caller only what it needs

For Origin CA certificate operations, start with Cloudflare's specified Zone – SSL and Certificates – Edit permission and restrict the token to the resources needed by that caller. Use separate tokens where practical, choose an expiry that fits the rotation process and record who owns the renewal.

Keep a controlled overlap while callers move across. Once every register entry has functional test evidence, remove the legacy secret injection and search again for the header, key prefix, provider field, environment variable and Kubernetes reference. Then revoke the Service Key.

Plan that final step carefully. Cloudflare notes that changing the Origin CA key immediately invalidates all previously generated values. It also says the change is not recorded in Audit Logs. Capture the decision, approver, time and validation results in your own change record.

Leave a credential process behind

The useful outcome is more than a cutover that works on September 30. You should finish with named owners, narrowly scoped tokens, known expiry dates, documented rotation steps and tests that can be run again when credentials change.

Greg can coordinate the work across repositories, Linux hosts, secret stores, Terraform and Kubernetes: assemble the caller register, connect dependencies with their owners, implement scoped tokens, verify the real workflows and retire the old key with evidence. That makes the deadline manageable and leaves the credential setup easier to operate afterward.