Cloudflare changed the shape of this problem in two steps. On November 25, 2025, API Shield started applying a zombie risk label to saved endpoints that had seen no traffic for 32 days. On March 9, 2026, Cloudflare launched the Web and API Vulnerability Scanner beta. Put those together and stale API surface area stops looking like a vague documentation problem. It becomes something teams can see, review, validate, retire, or block.
That is why zombie endpoints are turning into paid cleanup work. Not because Cloudflare charges for every forgotten route, but because once the platform points to a specific endpoint and suggests it is inactive, someone still has to decide what happens next. Is it truly dead? Should it still sit in Endpoint Management? Does the schema still describe it? Should traffic to it still be allowed? The tools now create enough signal that "we assume it is fine" is no longer much of a position.
What Cloudflare actually surfaces now
Cloudflare's November 25, 2025 changelog says API Shield applies the cf-risk-zombie label to saved endpoints that have not received traffic for 32 days, and it reevaluates that daily. Cloudflare also recommends reviewing those endpoints, removing ones that are no longer used from Endpoint Management, and considering a fallthrough rule to prevent communication with endpoints removed from Endpoint Management.
That matters because the label is attached to saved endpoints, not to a vague application or hostname. In practice, your Endpoint Management inventory becomes part of the security backlog. If you save everything and never clean it up, that backlog grows quietly. If you delete too quickly, you can lose visibility you still need. Cloudflare's Endpoint Management documentation says deleting an endpoint immediately stops performance and analytics tracking, and historical metrics cannot be restored if you later save that endpoint again.
Discovery is useful, but absence is not proof
API Discovery is helpful because it groups similar request paths and consolidates similar subdomains, which usually produces a more usable inventory than raw logs alone. That is especially useful when path parameters or IDs make one logical route look like hundreds of different URLs. Discovery first places endpoints in an inbox-style view, where teams can save them to Endpoint Management or ignore them.
But Discovery has clear limits, and those limits matter during cleanup. Cloudflare says an endpoint must return a 2xx response from the edge, must not come directly from Cloudflare Workers, and must receive at least 500 requests within a 10-day period. So if an endpoint does not appear in Discovery, that is not proof it no longer exists. It may be low-volume, failing, internal, or routed in a way the feature does not count. If you use Discovery as a delete list, you will make avoidable mistakes. A serious review compares live traffic, saved endpoints, and OpenAPI definitions instead of trusting one inbox screen as the full truth.
Cloudflare also says its machine learning-based discovery can identify API traffic whether or not your API uses a session identifier. That is useful in patchy environments, but it is another reason to treat discovery as an investigative signal rather than an automatic answer.
Endpoint Management is where cleanup becomes judgment
Endpoint Management is not just a place to park routes. It is where Cloudflare starts collecting endpoint-level performance data, and it is the inventory other controls depend on. Endpoints can be added from API Discovery, from schema validation, or manually by method, path, and host. Cloudflare also supports variable placeholders in paths and hostnames, which matters when an endpoint family should be managed as one normalized pattern instead of dozens or hundreds of literal values.
This is usually where the real work starts. Saving endpoints is easy. Deciding which discovered routes belong in the managed inventory is not. Teams have to separate documented endpoints from undocumented ones, decide which old routes should be retired, and deal with test paths or copied endpoints that quietly became permanent. If the managed inventory is wrong, everything downstream gets weaker with it.
Schema validation is where inventory cleanup starts to enforce something
Cloudflare's schema validation only protects endpoints that are already in Endpoint Management. If you upload a schema in the dashboard, Cloudflare can add those endpoints automatically. If you use the API or Terraform path, Cloudflare says you need to parse the schema and add the endpoints manually. That is an important operational detail for teams that want repeatable automation. The schema file by itself is not enough if the endpoint inventory is drifting.
Schema validation can be based on uploaded schemas or learned schemas, and Cloudflare says the resulting rules decide which traffic is allowed, logged, or blocked. Learned schemas also do not overwrite customer-uploaded schemas, so messy environments still need deliberate reconciliation. Cloudflare exposes both a global default action and per-endpoint actions, which gives teams a practical way to move from logging to blocking in stages instead of forcing a risky all-at-once rollout.
Cloudflare also documents a useful protection pattern here: a fallthrough rule that catches requests which do not match endpoints in Endpoint Management. Cloudflare explicitly says this can help protect against legacy or zombie endpoints your team may not know about. That is the point where cleanup stops being reporting and starts reducing reachable surface area.
Active scanning raises the cost of stale OpenAPI files
The March 9, 2026 release matters because Cloudflare moved beyond passive mapping and into active API testing. The Vulnerability Scanner beta is described as a stateful DAST platform focused initially on Broken Object Level Authorization. Cloudflare says it builds API call graphs to simulate attacker and owner contexts and tests those contexts with real HTTP requests. The documentation shows the scanner being configured through the API with a target environment, separate owner and attacker credential sets, an OpenAPI schema, status polling, and report retrieval.
That has a direct operational consequence. If your OpenAPI file is stale, too broad, or inconsistent, scan quality drops and automation gets harder. Cloudflare's schema validation documentation says it accepts OpenAPI 3.0.x in YAML or JSON, not OpenAPI 3.1 or 2.0. The vulnerability scanner documentation adds another beta-stage constraint: large OpenAPI specs may need to be split into smaller files, and Cloudflare suggests splitting by semantic use case to improve coverage. So the cleanup job is no longer just deleting routes. It also includes getting the API description into a shape the platform can actually use.
There is also a plan question to settle early. Cloudflare documents Endpoint Management and Schema validation as available on all plans, while API Discovery is documented as Enterprise-only and the current Vulnerability Scanner documentation says Enterprise API Shield customers. The March 9, 2026 changelog announced the beta for API Shield customers via the API, so it is worth confirming current entitlement before anyone plans a rollout around it.
What useful remediation work looks like
A sensible cleanup project usually follows a fairly plain sequence.
- Compare what API Discovery sees against what is saved in Endpoint Management and what your OpenAPI files say should exist.
- Review endpoints carrying the zombie risk label and decide whether each one should be documented, retired, or blocked.
- Preserve analytics before deleting endpoints you may want to study later, because Cloudflare removes historical metrics when endpoints are deleted from Endpoint Management.
- Normalize schemas so validation can be applied cleanly and active scans have usable, scoped OpenAPI inputs.
- Deploy fallthrough protection for traffic that misses known endpoints, then move schema validation from log to block where confidence is high.
- Wire scanner creation, polling, and report retrieval into CI, security dashboards, or lightweight operations scripts instead of relying on occasional manual checks.
That is the practical service opportunity behind the headline. Cloudflare now provides enough tooling to expose stale API surface area, attach controls to the documented parts, and actively test authorization behavior. What many teams still do not have is the time to reconcile live traffic, managed inventory, and OpenAPI files that drifted out of date months ago.
This is the sort of work Greg can help with: comparing live traffic to documented endpoints, cleaning up Endpoint Management, tightening schema validation, removing dead routes carefully, and turning Cloudflare's API-driven checks into something repeatable. Once zombie endpoints are visible, leaving them alone stops being a neutral choice.
Need help with this kind of work?
If Cloudflare is surfacing endpoints your team no longer trusts, Greg can turn that signal into a practical cleanup plan with controls you can keep running. Get in touch with Greg.