How do I get a list of all users who have access to a specific app?

Good question. I had this exact issue last month. The audit logs are where you can get the list of users who have *actually accessed* the app recently, but it won't show you everyone who *could* access it right now, which is what you usually need for a review.

You can generate a report directly from the Access policy. In the dashboard, go to Access > Applications, pick your app, and there's a "Policy Report" tab. It gives you a CSV of users and groups that match the current rules. It's not perfect if you have complex nested groups, but it's the most straightforward way for sharing with app owners.

That's a useful distinction about audit logs vs. the policy report. When you share the CSV with app owners, how do they typically handle the groups listed in it? Do they have to manually expand each group in their own directory to see the final user list, or is there a way to get Cloudflare to resolve that for them?

You've hit on the main operational friction with the Policy Report. The groups are not resolved by Cloudflare Access; app owners do have to expand them manually in their identity provider (like Okta or Azure AD) to get the final user list. This is because Access doesn't have a real-time sync of group membership - it just evaluates the group ID as a condition at login.

In my experience, this creates a verification gap. The app owner gets the CSV, but then has to request a separate export from the IT team for each listed group's membership to perform a true review. It becomes a two-step process that often slows things down. For a more direct view, some teams I've worked with use the Access audit logs as a supplement, because anyone who has logged in successfully is definitively in a matched group. It's not a full list of "could access," but it's a validated sample that can help spot-check the policy logic.

That verification gap is precisely why relying solely on the Policy Report for a compliance audit can be insufficient. It creates a control weakness where the review process is dependent on a separate, manual reconciliation that may not be formally tracked.

A better approach is to integrate this into your identity provider's access certification workflow. If you're using a tool like SailPoint or even native Azure AD access reviews, you can configure it to pull the Cloudflare Access application as a resource and directly compare it against the IdP's resolved group memberships. This closes the loop by making the review of "who can access" a single, authoritative process within the same system that manages the group membership.

The audit log as a sample check is a decent compensating control, but for frameworks like ISO27001, you need a reliable mechanism to demonstrate the complete set of authorized users, not just a sample of recent activity.

You've correctly identified the fundamental split here. The audit log shows historical activity, while the policy defines potential access. The built-in "Policy Report" CSV is the starting point, but its utility is inversely proportional to your group nesting complexity.

For a truly straightforward list for verification, you'll likely need to script it. The Cloudflare API can fetch the policy, but you then have to resolve groups via your IdP's API (SCIM or Graph) and perform a set union. It's annoying, but doing it once gives you a reproducible process. Sharing a script's output, rather than the raw policy CSV, forces a single source of truth and closes that verification gap others mentioned.

I usually add a timestamp and a note that it's a point-in-time resolution, because any group membership changes after the script runs will immediately desync the report from reality.