Inactive API Tokens: Cleanup Guide for Integrations
Audit inactive API tokens, map dependencies, disable safely, rotate secrets, reduce permissions and remove forgotten integration credentials without outages.
Cloudflare released automatic cleanup for inactive Access service tokens on 22 September 2026. Administrators can choose an inactivity window from 30 to 365 days and have eligible tokens disabled or deleted. It is a useful product feature, but the larger business lesson applies to every platform that uses API keys, service accounts, webhook secrets or machine credentials.
Websites and business applications accumulate credentials quietly. A CRM synchronisation, old staging deployment, reporting export, booking connector, ecommerce app or AI workflow may keep a token long after its original owner, supplier or project has moved on. If the credential still works, it remains another route into data and systems. If nobody knows what depends on it, deleting it can also cause an outage.
The right response is a controlled lifecycle: inventory the credential, identify its owner and dependency, observe real use, disable it reversibly, monitor the business outcome, then delete or replace it. Australian small and medium businesses do not need a large security team to do this well, but they do need evidence and ownership.
Machine credentials need an end date
Four signals make inactive-token cleanup a practical priority for connected businesses.
More connected systems
Websites now exchange data with CRM, payments, booking, fulfilment, analytics, cloud and AI services.
Long-lived secrets
Static API keys and client secrets can remain valid until someone deliberately rotates or revokes them.
Unclear ownership
Credentials created by former staff, agencies or experiments often survive without a current accountable owner.
Safer automation
Platforms are adding last-used evidence, temporary disablement and automated cleanup that make lifecycle control easier.
What counts as an API token or service credential?
The terms vary by platform, but the business problem is consistent: a non-human process needs permission to call another system. The credential might be an API key, OAuth client secret, cloud access key, service principal secret, deployment token, webhook signing secret, database password or certificate.
Cloudflare Access service tokens, for example, use a Client ID and Client Secret so an automated system can reach an application protected by Access. Other platforms may issue one key, a short-lived access token, or an identity that can obtain tokens without storing a reusable secret.
Do not limit the audit to credentials labelled “API token”. Include secrets stored in hosting settings, CI/CD variables, server configuration, integration platforms, password managers, scheduled scripts, mobile backends and vendor portals. Also include inbound webhook secrets: they may not grant broad API access, but they still determine whether your system trusts an incoming event.
Start with a credential register
A useful register connects technical facts to business ownership. Microsoft recommends documenting a service account's owner, purpose, permissions, linked resources and scripts, risk, review period and expected lifetime. That is a sound minimum for any integration credential.
| Field | Question to answer | Evidence |
|---|---|---|
| Credential | What platform, account and credential type is this? | Provider ID, name and environment |
| Owner | Who can approve rotation, disablement or replacement? | Named role and backup contact |
| Purpose | Which business process does it support? | CRM sync, deployment, payment, export or job |
| Dependency | Where is it stored and which workloads use it? | Vault path, app, script, vendor and repository |
| Access | What data and actions can it reach? | Scopes, roles, endpoints and environment |
| Usage | When did it last authenticate successfully? | Provider logs and application logs |
| Lifecycle | When is it reviewed, rotated and expired? | Review date, expiry and runbook |
| Recovery | How will the integration be restored? | Enable, rollback or replacement procedure |
One credential should represent one understandable purpose where possible. Reusing the same secret across unrelated applications makes impact analysis, rotation and incident response harder.
Why “last used” is evidence, not proof
An old last-used date is a strong review signal, but it does not prove that a credential is unnecessary. A quarterly finance export, annual certificate job, disaster-recovery process or low-frequency customer workflow may be legitimate even if it has been quiet for months. Some platforms also report use only for particular authentication paths.
Cloudflare applies three conditions before an Access service token becomes eligible for automatic cleanup: the token has not successfully authenticated during the configured period, it is older than that period, and it is not directly referenced by an Access policy rule. That is safer than age alone, but it still cannot understand your business calendar or undocumented downstream dependencies.
Before acting, compare provider activity with application logs, scheduler history, deployment records, integration-platform runs and business transaction evidence. Ask the process owner whether demand is seasonal. If the evidence conflicts, investigate rather than choosing the most convenient answer.
Move from discovery to verified removal
Classify each credential before changing it
The same inactivity period should not trigger the same action for every integration.
Keep and document
The credential is required, correctly scoped, owned and actively reviewed. Record the evidence and next review date.
Replace
The integration is needed, but the credential is shared, over-privileged, non-expiring or stored poorly.
Disable and observe
Usage appears inactive but dependency evidence is incomplete. Use a reversible step and an owned monitoring window.
Revoke and remove
The workload is retired, no dependency remains and rollback evidence is complete. Delete the secret and its copies.
Disable before delete when uncertainty remains
A reversible disablement is usually the safest first control for a credential that appears unused but lacks complete dependency records. Cloudflare's new policy can disable inactive service tokens while leaving them available to turn on again. Deletion is permanent.
Choose an observation window that covers the process frequency. A daily synchronisation may need several business days; a monthly close process needs a full month-end cycle; a seasonal integration may require an explicit owner decision rather than passive waiting. During that window, alert on failed authentication, missed schedules, queue backlogs, absent records and customer-facing errors.
Define the rollback before disabling: who can re-enable the token, what evidence justifies it, how quickly service must be restored and what happens next. Re-enabling without documenting the hidden dependency simply returns the organisation to the same risk.
Rotate active credentials without creating an outage
Rotation is not the same as cleanup. A credential can be active and still need replacement because it is old, exposed, shared or too powerful. OWASP treats creation, rotation, revocation and expiration as distinct parts of a secret lifecycle and recommends automating secret management where practical.
Use an overlap procedure when the platform supports it: create the replacement, store it in the approved secret manager, update one consumer at a time, verify successful authentication and business outcomes, then revoke the old secret. Cloudflare now supports a rotation grace period from one hour to 30 days for Access service-token secrets. The grace period is a migration window, not permission to leave both secrets active indefinitely.
Test the failure path as well as success. A deployment or sync succeeding once does not prove every worker, region, scheduled job or disaster-recovery environment received the replacement. Monitor use of the old credential and investigate any late caller before revocation.
Reduce privilege and prefer short-lived identity
Cleanup reduces the number of credentials; least privilege reduces what each remaining credential can do. Australian Cyber Security Centre guidance recommends specific service accounts with the minimum permissions required and says service accounts should not belong to built-in administrator groups. Microsoft similarly recommends granting only the permissions needed for the task.
Where the platform supports it, prefer workload identity, managed identity, federation or another method that issues short-lived credentials instead of storing a static key. AWS recommends temporary security credentials for many scenarios because they expire after a short period, and Google Cloud recommends attached service accounts or workload identity federation where practical.
For credentials that must remain static, constrain them by environment, resource, action, network path and expiry. A reporting process should not also change customer records. A deployment token for staging should not deploy production. A webhook validator should not have administrative API access.
Monitor the business process, not only authentication
Credential logs answer whether authentication succeeded or failed. They do not prove that the business process completed correctly. Pair identity evidence with application and outcome evidence.
| Integration | Technical signal | Business signal |
|---|---|---|
| Website to CRM | API response, retry count and queue age | Lead appears once with complete attribution |
| Ecommerce to fulfilment | Event delivery and consumer acknowledgement | Order reaches the correct warehouse state |
| Booking platform | Authentication and schedule execution | Availability and confirmation stay accurate |
| Payment reconciliation | Job completion and record count | Settlements match expected transactions |
| CMS deployment | Build, publish and cache status | Approved content is visible on intended URLs |
| AI automation | Tool-call authorisation and error rate | Action stays within approved data and workflow boundaries |
Retain enough audit evidence to investigate change, but do not write secrets into logs. Mask credential values and control access to the logs themselves.
Clean up credentials in four controlled weeks
Start with the highest-risk systems and build a repeatable review cycle.
Week 1: Inventory
Export credentials from priority platforms, search deployment and integration settings, and assign owners.
Week 2: Trace
Map workloads, scopes, storage locations, last-use evidence, schedules and customer-impacting outcomes.
Week 3: Act
Replace exposed or shared secrets, reduce excessive permissions and disable low-confidence inactive tokens.
Week 4: Verify
Monitor full business cycles, revoke confirmed-unused credentials and schedule the next owner review.
How to configure Cloudflare's new cleanup safely
For Cloudflare Access, automatic cleanup is configured at the Zero Trust account level and applies to all service tokens in that account. Choose an inactivity threshold between 30 and 365 days and select either disable or delete. Cloudflare says eligible cleanup runs gradually in the background, so action may not be immediate.
Begin with disable unless the account already has complete ownership, dependency and monitoring records. Select a threshold that covers legitimate low-frequency workloads. Review tokens that are directly referenced by policy rules separately, because Cloudflare excludes those from automatic inactivity cleanup even if they have not authenticated recently.
Before enabling the policy, export the token inventory, identify policy references, confirm owners and establish alerts for authentication failures and downstream business outcomes. After the first cleanup cycle, investigate every re-enable request. Once the process has proven reliable, decide whether a later policy can delete confirmed-unused credentials.
Questions to ask your developer or integration partner
- Which API keys, service accounts, certificates and webhook secrets exist across production, staging and development?
- Who owns each credential and which business process does it support?
- Where is each secret stored, and is it present in source code, logs, old backups or former supplier systems?
- Which permissions are actually required, and can write or administrator access be removed?
- Can the integration use managed identity, federation or short-lived credentials instead?
- What last-used evidence is available, and which low-frequency schedules could make it misleading?
- Can a token be disabled before deletion, and what is the tested rollback procedure?
- How will we prove that leads, orders, bookings, payments, content or reports still arrive correctly?
- How are rotation, expiry alerts, incident revocation and owner reviews documented?
- What happens to credentials when staff, vendors, applications or environments leave service?
Sources checked
- Cloudflare Access changelog
- Cloudflare documentation: Service tokens
- OWASP Secrets Management Cheat Sheet
- Australian Cyber Security Centre: Secure administration
- Microsoft Entra: Governing service accounts
- AWS IAM: Find unused credentials
- AWS IAM: Secure access keys
- Google Cloud: Authenticate service accounts securely
Sources were accessed on 23 September 2026. Product behaviour, plan availability and security controls can change; verify current provider documentation before applying an automatic cleanup policy.