If a staging site, /wp-admin path, client preview URL, partner portal, or internal dashboard is reachable from the public internet, the problem usually is not discovery. The problem is operational drift. Someone needed outside access for a sprint, a QA cycle, or a vendor handoff, and the temporary exception survived longer than the project memory did.
For business owners and operations leads, that creates a simple management problem as much as a security one: nobody can say with confidence who can still reach what today. Exposed staging and admin surfaces sit outside normal onboarding, offboarding, and change control. Cloudflare Access is useful here because it lets you put identity and policy in front of those tools without rebuilding the whole network. The work, however, is not the login screen. The work is choosing the right application type, sequencing the rollout correctly, and fixing the machine and origin edge cases that get skipped.
Start with an inventory, not a tunnel
Before you protect anything, list the endpoints you actually have: staging hostnames, /wp-admin, preview environments, BI dashboards, vendor portals, and health-check URLs. For each one, note who owns it, whether access is human or machine, whether the origin is publicly routable, and whether the tool is hosted by you or by a third party.
Cloudflare's current application model makes that distinction important. If you control the hostname or routing, a self-hosted application is usually the right starting point. If the tool is a third-party SaaS product that supports SAML or OIDC, it belongs under SaaS applications. If it is only a link tile in App Launcher, it is just a bookmark, and Cloudflare is explicit that bookmarks do not protect the destination URL. That is where many teams end up with a tidy portal while the real entry point is still public.
If engineers or agency partners need command-line access to a protected endpoint, self-hosted applications also support cloudflared access login <hostname>. That is a practical way to support real workflows without falling back to shared admin accounts.
Roll out Cloudflare Access in the right order
For staging sites and admin panels you host yourself, the safest pattern is usually straightforward:
- Create the Access application for the exact hostname or path you want to protect.
- Add narrow
Allowpolicies, choose the identity providers, and set a sensible session duration. - Only then connect the origin with Cloudflare Tunnel, or lock down the direct origin if the app is already publicly routable.
- Validate the Access token at the origin so bypass traffic is rejected.
This order matters. Cloudflare's current guide recommends creating the Access application before setting up the tunnel route, because otherwise the published application is available to anyone on the internet. The same guide also reminds teams that Access applications are deny by default, so users only get through when they match an Allow policy. That makes cleanup much safer than the usual pattern of leaving a public hostname in place and promising to restrict it later.
If the application is already publicly routable, a tunnel is not strictly required. But that does not mean the origin can stay casually exposed. In practice, it means you still need to protect the origin IP with other controls and make sure only the intended Access path is trusted.
Do not stop at the edge login page
Cloudflare's guidance is clear here: validate the Access token at the origin. That is what turns Access from a front-door control into an actual gate. If traffic can still reach the origin directly through a forgotten DNS record, alternate hostname, or loose firewall rule, origin-side token validation lets you reject it.
There are two practical options. Let cloudflared handle validation with Protect with Access, or validate the application token in the application or reverse proxy yourself. For most small and mid-sized teams, the managed validation path is the faster cleanup. The operational point is simple: if the origin still trusts direct requests, you have added friction, not finished access control.
Replace bypasses and shared logins with service auth
This is where otherwise sensible rollouts usually get messy. A temporary Bypass rule gets added for a webhook. A vendor gets a shared human login because it is only for two weeks. An uptime checker needs access and nobody wants to break alerts. Six months later, the exception has become the real access model.
Cloudflare's policy documentation is blunt on this point. Bypass disables Access enforcement, requests are not logged, and Bypass plus Service Auth policies are evaluated before Block and Allow rules. In other words, one temporary exception can quietly override the clean security model everyone thinks is in place.
For CI jobs, health checks, webhooks, or vendor automations, use service tokens with a Service Auth policy instead. The standard request pattern is:
curl -H "CF-Access-Client-Id: <CLIENT_ID>" -H "CF-Access-Client-Secret: <CLIENT_SECRET>" https://app.example.comCloudflare can also read the credentials from a single header, which helps when a SaaS platform only supports one custom header. The practical details matter: the client secret is shown once, tokens can be renewed, deleting the token revokes access, and if an application only has Service Auth policies, the service token must be sent on every request instead of relying on a later JWT alone.
Use App Launcher as an index, not a security shortcut
App Launcher is helpful after the access model is cleaned up. It gives staff, contractors, and agencies one place to find the tools they are already allowed to use. That reduces URL confusion and cuts down on stale bookmarks during onboarding and offboarding.
But treat it as a directory, not the control itself. Cloudflare says App Launcher is disabled by default, needs its own policy, and its rules do not change permissions for the applications behind it. Bookmarks only control tile visibility. If the underlying tool is still public, the launcher has organized the problem, not solved it.
Why companies pay to clean this up
The reason this becomes a paid project is not that the technology is exotic. It is that the loose ends sit in different systems and usually belong to different people: DNS, Cloudflare, the IdP, vendor integrations, reverse proxies, WordPress, CI, and internal ownership. Someone has to inventory the exposed endpoints, choose the correct Access model for each one, narrow the policies, remove bypasses, protect the origin, convert automations to service auth, and leave behind an access model the team can actually maintain.
If your environment still has public staging URLs, exposed admin paths, or vendor workflows tied to shared credentials, this is the kind of Cloudflare Access hardening job that benefits from a short audit and a rollout plan that finishes the awkward edge cases instead of parking them for later. Talk to Greg if you want that cleanup scoped and implemented without breaking delivery.
Need help with this kind of work?
Talk to Greg about locking down exposed staging URLs and admin access without slowing delivery Get in touch with Greg.