What Cloudflare Access is and why an admin panel needs it
Cloudflare Access places an identity check in front of the origin server: a user opens the panel address, sees a Cloudflare login form, and gets access only after confirming through email, a Google account, or corporate SSO. The request reaches the origin already carrying a "let in or not" decision.
For admin panels on a VDS, this closes a common hole: phpMyAdmin, a control panel, or a Git hook sitting on a public port gets found by scanners within the first day. Access removes the panel from the public zone, leaving identity checking in front of Cloudflare instead of on the server itself.
How Access differs from a VPN and a plain firewall
The difference lies in where the check happens and what is visible from outside before login.
| Criterion | VPN | Cloudflare Access |
|---|---|---|
| What is visible outside | An open VPN port on the server | A regular HTTPS domain with no extra ports |
| Client | A separate app and profile | A browser, no client install needed |
| Rule granularity | Access to the whole subnet at once | A separate policy per application |
How to connect an application in the Zero Trust dashboard
An application is created in the Zero Trust Dashboard under Access → Applications. There you specify the admin subdomain, for example admin.example.com, and the path to the origin server.
cloudflared tunnel login
cloudflared tunnel create admin-panel
cloudflared tunnel route dns admin-panel admin.example.comIf the server has no public IP address, it's worth setting up the application through Cloudflare Tunnel — then the admin port is never opened to the outside at all.
Access policies: who gets in and under what conditions
An Access policy is a set of conditions checked before a session is issued. Conditions can be combined in a single rule:
- email or mail domain — access limited to company employees
- membership in an identity provider group
- request country, based on Cloudflare's data
- device check through the WARP client and its device posture
- session duration limit, from one hour to one week
Setting up login through an identity provider
Access supports login through Google Workspace, GitHub, Azure AD, and a one-time PIN code sent by email without an external provider. For a small team, a One-time PIN is enough: an email with a code arrives at the given address on every login attempt.
For a team sharing a Google account, connect Google as the identity provider under Settings → Authentication and list the allowed mail domains.
Service Tokens for API and CI/CD
When it's not a human but a deploy script or a monitoring tool hitting the protected address, a login form doesn't work. Access provides Service Tokens for this — a Client ID and Client Secret pair passed as request headers.
curl -H "CF-Access-Client-Id: <client_id>" \
-H "CF-Access-Client-Secret: <client_secret>" \
https://admin.example.com/deploy-hookThe token is tied to a separate policy and can be revoked easily without touching the rules for other users.
Summary: checklist before enabling Access
Access gates entry to the panel by checking identity in front of the origin, with no VPN client and no separate port on the server.
- move the admin panel to a separate subdomain and set up an Access application
- hide the origin through Cloudflare Tunnel when a public IP address is not needed
- set up an identity provider or a One-time PIN for login
- describe the policy by email, group, and request country
- issue a Service Token to deploy scripts instead of a shared password
Frequently asked questions
What does a visitor see if they land on the admin subdomain without Access permission?
Instead of the control panel or the application's login form, they see a Cloudflare authentication page asking for an email address or an identity provider to pick. The origin server never even receives the request until identity is verified, so the admin panel's content and the very fact it exists stay hidden from an outside observer.
What happens if a deploy script never gets a Service Token after Access is enabled on a domain?
The script's request reaches the Cloudflare login form just like a browser's would, and gets a redirect instead of the expected API response — the deploy or hook fails with an authorization error. The fix is simple: issue a dedicated Service Token for that script and attach its headers to the request.
Does Cloudflare Access protect against attacks on the application itself, not just unwanted logins?
No, Access verifies identity before granting access to an address, but it does not inspect request content after login and does not replace protecting the application against flaws such as SQL injection. It is an entry barrier, not a WAF: a vulnerability inside the admin panel itself stays reachable by anyone who passed the identity check legitimately.
What's the option if a team doesn't use Google Workspace or another corporate identity provider?
A One-time PIN with no external provider works fine: Cloudflare sends a single-use code to the given email on every login attempt, which is enough for a small team. Connecting Google, GitHub, or Azure AD makes sense once group-based policy or single sign-on across several protected applications is actually needed.