On this page · 10 sections
Summary. On 19 August 2026 Cloudflare shipped a change so that members holding only resource-scoped Access roles can list resources in the dashboard and through the API, across four object types: Access applications, policies, service tokens and identity providers. Before that change, "the dashboard blocked these list pages and API list requests returned 403 responses". Two things sit awkwardly next to the announcement. First, the account roles page that defines these roles carries dateModified of 10 August 2026, nine days earlier, and still states "Resource-scoped roles is currently in Beta". Second, and more consequential for anyone running access reviews: a member with the Cloudflare Access App Admin role sees "policies attached directly to the selected application", while "reusable policies appear only when the member has the Cloudflare Access Policy Admin role for those policies". The list is filtered, and nothing in the product marks it as filtered. Cloudflare One pricing on 23 August 2026 is $0 for up to 50 users, $7 per user per month pay-as-you-go with no user limit, and custom annual pricing on contract, per Cloudflare's plans page.
What shipped
The changelog is one paragraph of mechanism and one paragraph of caveat. The mechanism: members with only resource-scoped Access roles can now open Access resource list pages and call list endpoints, without needing an additional account-scoped read-only role stapled on. The dashboard and API "return only resources included in the member's permission policy scopes", and that filtering covers Access applications, policies, service tokens and identity providers.
That is a real improvement. The old workaround, granting an account-scoped read-only role so a delegated admin could see the list page at all, handed that person visibility into every resource in the account. Removing it is exactly the right direction for least privilege.
The role scopes page, last updated 21 May 2026, sets out the model this fits into: account scope, specific domains, domain groups and specific resources, with the rule that "each policy has a limitation of a single scope, but you can assign multiple policies to a given user". Account-scoped policies can only carry account-scoped roles; domain group policies can only carry domain-scoped roles.
The Beta label nobody updated
The roles page is where an administrator goes to decide whether to depend on this. Its structured dateModified field reads 2026-08-10, and under the heading "Resource-scoped roles" it carries a note saying the capability "is currently in Beta".
The changelog, nine days later, describes behaviour that reads as generally available: a dashboard change, an API change, and a stated replacement for a documented previous behaviour. Neither page acknowledges the other. This is the same pattern that showed up in Cloudflare's Wrangler OAuth scope change, where the CLI reference page lagged the changelog, and it matters more here because Beta status is a procurement question. A security team that reads the roles page will tell you the feature cannot carry a production access-control boundary. A team that reads the changelog will tell you it already does.
Here is what the roles page actually lists as resource-scoped, as of its 10 August 2026 revision.
| Resource-scoped role | Scoped to | Covered by the 19 Aug list change |
|---|---|---|
| Cloudflare Access App Admin | A specific Access application | Yes, with the reusable-policy caveat below |
| Cloudflare Access Policy Admin | A specific Access policy | Yes |
| Cloudflare Access Identity Provider Admin | A specific Cloudflare One identity provider | Yes |
| Cloudflare Access Service Token Admin | A specific Access service token | Yes |
| Access for Infrastructure Target Admin | A specific infrastructure target | Not named in the changelog |
| Individual Cloudflare Tunnel instances | A specific Cloudflare Tunnel | Not named in the changelog |
| Individual Cloudflare Mesh nodes | A specific Cloudflare Mesh node | Not named in the changelog |
Seven entries in the table, four object types named in the changelog. Infrastructure targets, Tunnel instances and Mesh nodes are not mentioned in the announcement, and the changelog does not say whether their list pages behave the same way. If you delegate those, test rather than assume.
The partial list is the real problem
Read this sentence from the changelog slowly, because it describes a silent failure mode: "For members with the Cloudflare Access App Admin role, policy lists include policies attached directly to the selected application. Reusable policies appear only when the member has the Cloudflare Access Policy Admin role for those policies."
An Access App Admin delegated to one application opens that application's policy list to answer the standard access-review question, which is "who can reach this application". They see the directly attached policies. A reusable policy that also grants access to that application, but which they do not administer, is absent from the list. There is no count, no truncation notice, and no "some items are hidden" affordance described anywhere in the announcement.
The gap widens because the term itself is thin on the ground in the documentation. The Access policies page, last updated 7 July 2026, does not use the phrase "reusable policies" anywhere, and the path /cloudflare-one/reusable-components/policies/ returns a 404 rendered as a full styled HTML page rather than a documentation stub. Reusable lists and reusable posture checks are documented under reusable-components; reusable policies, the object type the changelog makes a permission depend on, is not.
For anyone building evidence for an audit, that is the crux. A screenshot of a filtered policy list looks identical to a screenshot of a complete one.
Who is affected
You are affected if you delegate Cloudflare Access administration to application owners, contractors or a managed service provider, and you use reusable policies to apply a shared rule across several applications. That combination is common because it is the sensible way to keep a device-posture or country rule in one place.
You are also affected if you have automation reading Access list endpoints under a resource-scoped identity. Those calls previously returned 403, so any script that treated a 403 as "no permission, escalate" now gets a 200 with a filtered array instead. A change from an error to a partial success is worse for automation than either extreme, because nothing raises.
Service token administration deserves its own check. The service tokens documentation, last updated 4 August 2026, shows a token duration of 8760h in its API and Terraform examples, which is one year, with an expires_at timestamp returned on creation. A delegated Service Token Admin who can now list tokens sees only the tokens in their scope, so a rotation report built from that view is scoped too. It will not tell you about the token expiring next month that belongs to a different team.
What to do this week
Ask Cloudflare support or your account team to confirm whether resource-scoped roles are Beta or generally available, and get the answer in writing. The two pages disagree, and it is a five-minute question with a documented answer somewhere inside Cloudflare.
Re-run one access review as a super administrator and compare it against the same review run by the delegated admin. The difference between the two policy lists is your exposure, and it is measurable today.
Stop treating a delegated policy list as complete evidence. Until Cloudflare marks a filtered list as filtered, an access review that must be defensible should be produced by an account-scoped identity, with the delegated view used for day-to-day work only.
Fix your automation's error handling. Any code path that branched on 403 from an Access list endpoint needs to branch on completeness instead, which in practice means comparing counts against a privileged call.
Check the audit logs rather than the list views when you need to reconstruct who changed what, since audit logging is not scoped by the same policy filter that shapes these lists.
India-specific considerations
Indian teams operating under the Digital Personal Data Protection Act 2023 have a specific reason to care about the partial-list behaviour. A data fiduciary has to be able to demonstrate which people and systems can reach a given application holding personal data. If the artefact backing that claim is a policy list produced by a delegated administrator, the artefact may be incomplete without anyone noticing, and the incompleteness is invisible after the fact. Firms outsourcing Cloudflare Access administration to a vendor should require access-review evidence to be generated by an account-scoped identity and retained with the run date. This belongs in the same control set as the rest of your DPDP engineering work, alongside the residency traps in Cloudflare Artifacts namespace jurisdictions.
What is still unknown
Cloudflare has not said whether the Beta label on resource-scoped roles is stale or accurate, whether Access for Infrastructure targets, Tunnel instances and Mesh nodes get the same list behaviour, or whether a future release will mark filtered lists as filtered. The changelog also does not say whether the API returns any pagination or count metadata that would let a caller detect filtering. Until that is documented, comparing against a privileged call is the only reliable detection method.
FAQ
How eCorpIT can help
Delegated access control fails quietly, which is why it usually surfaces during an audit rather than during operations. eCorpIT reviews Zero Trust and identity configurations for teams running Cloudflare Access alongside AWS IAM and Microsoft Entra ID, and produces access-review evidence that holds up when someone asks how it was generated. We are ISO 27001:2022 certified and design controls aligned with DPDP Act requirements. If you delegate Cloudflare Access administration to application owners or a vendor, book an access control review and we will compare the delegated view against the privileged one with your team.
References
Last updated: 23 August 2026.
