# Cloudflare Access adds automatic cleanup for inactive service tokens Administrators can now set a 30-to-365-day inactivity window and choose whether Cloudflare disables or deletes tokens that stop authenticating, with policy-referenced tokens excluded from cleanup. Canonical URL: https://freelancenews.online/news/cloudflare-access-adds-automatic-cleanup-for-inactive-service-tokens-aa613cde Published: 2026-09-25T23:18:37.271Z Updated: 2026-09-25T23:18:37.271Z Source published: 2026-09-22T00:00:00.000Z Event date: 2026-09-22 Review status: source-reviewed Review method: Automated comparison against retrieved source text; not independent fact-checking. ## Report Cloudflare has added a setting that lets Access administrators automatically disable or delete service tokens that go unused, according to a changelog entry on the company's developer documentation site. The mechanism is configured by choosing two things: an inactivity period, and the action Access should take once a token reaches that limit. The changelog describes the capability as something administrators can now set up, rather than a default behaviour applied to existing accounts. The inactivity period is selectable within a defined range. Administrators can set it anywhere from 30 to 365 days, and when a token crosses the chosen threshold Access either disables it or deletes it, depending on which behaviour was selected. The changelog presents these as the two available outcomes and does not describe any intermediate state or staged escalation between them. Eligibility is narrower than the headline feature might suggest. According to the changelog, a token becomes a candidate for cleanup only when three conditions hold together: it must be older than the configured period, it must not have successfully authenticated during that period, and it must not be directly referenced by an Access policy rule. The third condition is the most consequential for teams, because a token still wired into a policy is excluded from automatic removal even if it has been quiet for a long time. The changelog also states that cleanup runs gradually in the background. As a result, tokens that qualify may not be disabled or deleted immediately once they pass the threshold. Administrators should therefore not read the configured period as a precise deadline, and any expectation that a token will disappear on a specific day is not supported by the documentation. The practical effect is a rolling process rather than a single scheduled sweep. The announcement is framed around the problem of inactive credentials accumulating in an Access configuration. The changelog does not describe how tokens are surfaced to administrators before cleanup, nor does it specify notification behaviour, so it is unclear from the supplied text whether an operator would learn about an impending deletion in advance. It also does not explain what happens to a token that is disabled rather than deleted, or whether either outcome can be undone. For freelancers and small studios that maintain client Cloudflare accounts, the feature is a configuration decision rather than something that happens by default. The changelog describes the capability as something administrators can now set up, and points to separate configuration instructions under a page titled Manage inactive service tokens. Nothing in the supplied excerpts indicates that cleanup is enabled automatically for existing accounts, so teams that want the behaviour would need to configure it themselves. The 30-day floor is worth noting for anyone running intermittent workloads. A token used by a monthly batch job, a seasonal integration or a client project that pauses between phases could sit unused for longer than a short window, and if it is not referenced by a policy rule it could qualify for cleanup. Choosing a period near the lower end of the range therefore carries more risk for irregular usage patterns than choosing one closer to a year. Conversely, the upper end of the range limits how much the feature actually reduces credential sprawl. A 365-day window means a token can remain unused for a full year before anything happens to it. Administrators weighing the setting are effectively trading off the speed of cleanup against the chance of disrupting a legitimate but infrequent integration, and the changelog offers no guidance on which end of the range suits which scenario. The exclusion for tokens directly referenced by an Access policy rule creates a second layer of protection that is easy to overlook. A token that is still attached to a policy will not be cleaned up regardless of how long it has been idle, which means stale credentials embedded in policy rules may persist unless someone reviews those rules separately. The feature addresses unused tokens, not unused policy references. The background execution model has an operational consequence that the changelog states plainly: eligible tokens may not be acted on immediately. For teams that audit their credential inventory, this means the state of a token at any given moment may not match what the configuration implies. Any internal documentation or runbook that assumes deterministic timing would need to account for the gradual rollout of cleanup. The changelog does not state whether disabled or deleted tokens can be recovered, nor does it describe logging or audit output for cleanup actions. It also does not indicate whether the feature is available on all Cloudflare plans or limited to particular tiers. Those gaps matter for anyone deciding between disablement and deletion, since the safer option depends on recovery behaviour the source material does not document. For this audience, the most defensible reading is that the feature is a housekeeping tool best paired with an inventory of which tokens are still referenced by policy rules. Because policy-referenced tokens are excluded, the cleanup will not catch every stale credential, and because execution is gradual, it will not produce an immediate tidy state. Treating it as one layer of credential hygiene rather than a complete solution matches what the documentation actually claims. The changelog entry is dated September 2026 and appears on Cloudflare's developer changelog, which is the company's own publication channel for product changes. The supplied excerpts do not include a named author, a version number or a plan-tier statement, so the announcement should be read as a feature description rather than a detailed technical specification. Configuration specifics beyond the inactivity range and the disable-or-delete choice are deferred to a separate documentation page. What remains unknown from the supplied material is substantial: recovery of deleted tokens, notification before cleanup, audit logging, plan availability, and whether the setting can be scoped to particular tokens or applied account-wide. The changelog also does not quantify how many tokens typically qualify for cleanup or describe any measured reduction in credential exposure. Those are open questions rather than established outcomes, and they should not be filled in from assumption. The reasonable conclusion for administrators is to decide deliberately between disabling and deleting, pick an inactivity window that reflects the least frequent legitimate use of any token in the account, and separately review policy rules for tokens that the cleanup will never touch. The feature reduces manual housekeeping for genuinely idle credentials, but its exclusions and gradual execution mean it complements, rather than replaces, periodic credential review. ## Key points - Cloudflare Access administrators can configure automatic disablement or deletion of service tokens that have not authenticated within a chosen inactivity period. - The inactivity period is selectable between 30 and 365 days, and the administrator chooses whether the outcome is disablement or deletion. - A token is only eligible if it is older than the configured period, has not successfully authenticated during that period, and is not directly referenced by an Access policy rule. - Cleanup runs gradually in the background, so eligible tokens may not be disabled or deleted immediately. ## Practical implications — editorial interpretation Freelancers and small teams managing client Cloudflare accounts should treat this as an opt-in housekeeping setting: pick an inactivity window longer than the least frequent legitimate use of any token, and separately audit policy rules, since tokens still referenced there are excluded from cleanup and will not be removed automatically. ## Limitations and unknowns The supplied changelog excerpts do not state whether disabled or deleted tokens can be recovered, whether administrators are notified before cleanup, whether cleanup actions are logged, which Cloudflare plans include the feature, or whether the setting can be scoped to individual tokens. No version number, author or measured outcome is provided, and configuration details are deferred to a separate documentation page not included in the evidence. ## Sources - [1] developers.cloudflare.com: Changelog https://developers.cloudflare.com/changelog/post/2026-09-22-service-token-inactivity-cleanup/ Retrieved: 2026-09-25T23:18:02.360Z ## Claim references - Cloudflare Access administrators can now automatically disable or delete inactive service tokens. [source 1] - Administrators can set an inactivity period from 30 to 365 days and choose what happens when a token reaches that limit. [source 1] - A token is eligible for cleanup only if it is older than the configured period, has not successfully authenticated during that period, and is not directly referenced by an Access policy rule. [source 1] - Cleanup runs gradually in the background, so eligible tokens may not be disabled or deleted immediately. [source 1] - Configuration instructions are available on a page about managing inactive service tokens. [source 1]