Most people think of login security in terms of strong passwords and two-factor authentication inside the app. Both are great, but they share the same problem: the login page itself is still publicly accessible. Any bot on the internet can reach it, hammer it with thousands of login attempts, and probe it for vulnerabilities. Your defenses only kick in once they are already at the door.
Cloudflare Access takes a completely different approach. It puts a gate in front of the login page at the network level, before the request ever reaches your server. When someone visits your login URL, they see a Cloudflare-hosted screen asking for their email. They receive a one-time code. If their email is on your approved list, they get through to the real login. If not, they are denied. Bots never see your actual login form at all.
What makes this especially useful is that it works for any login page on any web application routed through Cloudflare. This includes your CMS, database tools, e-commerce admin, and even physical systems like HVAC controllers or IP cameras that have a web interface.
Before You Start
What You Can Protect
Content Management Systems
Most TargetedCMS login pages are the most attacked URLs on the internet. WordPress alone powers over 40% of all websites, so bots specifically scan for these paths around the clock. Putting Access in front of them removes the attack surface entirely.
WordPress
Protect /wp-login.php to gate the main login page. You can add a second application for /wp-admin to cover the dashboard directly. If you lock down /wp-admin, be aware that /wp-admin/admin-ajax.php needs to stay open for front-end AJAX calls. You may need to add a bypass rule for that path.
Joomla
Joomla's administrator panel lives at /administrator. This is the only path you need to protect. The public front end of the site is completely separate and continues working normally for all visitors. If you have configured a custom administrator directory name, use that path instead.
Magento 2
Magento's admin defaults to /admin but most production installs use a custom admin URL for security. Check app/etc/env.php under the backend/frontName key for your actual path. Protect that full path in Access.
Drupal
Drupal's login page is at /user/login. The admin dashboard is at /admin. Protecting /user/login is the right choice in most cases since that is where credential attacks happen and it covers both admin and regular user logins.
Craft CMS
The default admin panel path is /admin but Craft lets you configure this in config/general.php under the cpTrigger setting. Use whatever your installation is set to.
PrestaShop / OpenCart
OpenCart defaults to /admin. PrestaShop generates a randomized admin folder on install like /admin1234xyz. Use whatever folder name your install generated. Both work exactly the same way in Access.
Database and Server Management Tools
High Risk if ExposedDatabase management tools should never be exposed to the public internet without a gate in front of them. If you have phpMyAdmin or any similar interface at a public URL, this is one of the highest-value things you can do with Access.
phpMyAdmin
The path varies by hosting setup. Common paths include /phpmyadmin, /phpMyAdmin, or /pma. Some hosts put it at a subdomain like phpmyadmin.yourdomain.com. In that case, set up the Access application for the full subdomain and use / as the path to protect everything under it.
Adminer
Adminer is a single-file PHP database tool developers often drop into a web directory for quick access. Because it is frequently left in place and forgotten, it is a significant risk. Protect whatever path it lives at. On client sites, also consider simply removing it when not in active use.
cPanel, WHM, and Plesk
These control panels run on non-standard ports (2082, 2083, 2086, 2087 for cPanel, 8443 for Plesk). Cloudflare does not proxy non-standard ports on most plans, so Access cannot intercept them directly. The better options here are IP-based firewall rules at the server level combined with the built-in two-factor authentication each panel provides. Do not rely on Access for port-based interfaces.
HVAC, Cameras, NAS, and Physical Systems
Underrated Use CaseThis is the use case most people never think about, and it may be the most important one for businesses. HVAC controllers, building management systems, IP cameras, NAS devices, and network equipment often have web interfaces. These devices frequently ship with weak default credentials, rarely get security updates, and were never designed with internet exposure in mind. If they are reachable from the public internet without any gate, they are a target.
How it works for local devices
Create a DNS record for a subdomain in Cloudflare pointing to the local IP of the device. For example, hvac.yourdomain.com pointing to 192.168.1.50. Make sure the record is proxied (orange cloud). Then create a Cloudflare Access application for that subdomain with / as the path. Anyone hitting that URL must authenticate through Access before reaching the device interface.
What you can protect this way
HVAC and building automation systems, IP cameras and NVR/DVR systems, NAS devices (Synology, QNAP, TrueNAS web UI), network switches and routers with web-based management, smart UPS management cards, industrial control panels with HTTP interfaces, and any other device with a browser-based interface on your network.
Why this matters for businesses
A commercial HVAC system with a publicly accessible web interface and default credentials is not just an inconvenience if compromised. It is a physical security issue. Someone with access to your building's climate control can cause real damage to equipment, server rooms, or temperature-sensitive inventory. Cloudflare Access is a lightweight way to add strong authentication to systems that were never built for the open internet.
HTTP-only devices and SSL
Many local devices only support plain HTTP on their management interface. When you proxy through Cloudflare, Cloudflare handles HTTPS to the visitor but connects to your device using whatever protocol your internal DNS points to. Set your Cloudflare SSL/TLS mode to Flexible for this subdomain via a Configuration Rule. This lets Cloudflare serve HTTPS to visitors while connecting to the device over HTTP internally. Not ideal for every situation, but it works for device management interfaces on private networks.
Step-by-Step Setup
Open Zero Trust
Start HereLog into your Cloudflare dashboard and click Zero Trust in the left sidebar, or go directly to one.dash.cloudflare.com. If this is your first time, Cloudflare will walk you through a quick setup and ask you to pick a team name for your organization.
Once inside Zero Trust, navigate to Access → Applications.
Zero Trust is free for up to 50 users
You do not need a paid Cloudflare plan. The free tier handles up to 50 seats, which covers most agencies protecting their own tools and client sites. Paid plans add features like device posture checks, SAML/SSO integration, and detailed access logs. For email-based login protection, the free tier does everything you need.
Add a Self-Hosted Application
SetupClick Add an application and choose Self-hosted. This option covers any URL or path on your own domain. This is what we are doing whether the target is a CMS, a database tool, or a physical device's web interface.
Application name
Give it a descriptive name. If you are protecting multiple applications, be specific. Something like Client A WordPress Login or Office HVAC Panel makes it much easier to manage when you have a growing list of applications in the dashboard.
Session Duration
This controls how long a user stays authenticated through Access before being asked to re-verify via email code. For a site accessed daily, 24 hours is comfortable. For a system accessed infrequently, 7 or 30 days reduces friction. Set it based on how often legitimate users actually need in.
Set the Domain and Path
SetupEnter the domain and the specific path you want to protect. This is the most important part of the configuration. Get this right and everything else follows.
Domain
Enter the full domain: example.com or hvac.example.com for a subdomain. Match it exactly to how the URL appears in the browser. Include www if your site uses it.
Path
Enter the path to your login page. Use / to protect the entire domain or subdomain. This is useful for device subdomains where the whole interface should be gated. Leave it blank to protect the root only.
WordPress
Path: /wp-login.php. Add a second app for /wp-admin if needed.
Joomla
Path: /administrator. Use your custom admin directory name if you changed it.
Magento 2
Path: /admin. Check app/etc/env.php under backend/frontName for your actual path.
Drupal
Path: /user/login. Use /admin instead to cover the dashboard directly.
Craft CMS
Path: /admin. Check cpTrigger in config/general.php for custom paths.
phpMyAdmin
Path: /phpmyadmin. Or use a subdomain and protect / to gate everything under it.
PrestaShop
Path: your randomized admin folder like /admin1234xyz. Use whatever name your install generated.
HVAC / Cameras / NAS
Path: /. Point a subdomain at the device and protect the entire subdomain.
Create the Access Policy
SetupAfter configuring the application, you will be prompted to add a policy. This is where you define who is allowed through. Click Add a policy.
Action: Allow
Set the action to Allow. This policy defines who gets in. Anyone not matching the policy is denied automatically. No extra configuration needed for the deny side.
Selector: Emails
Under Configure rules, set the selector to Emails and list each approved email address. Only people whose email is on this list will receive a login code when they try to authenticate.
Using Email Domain instead of individual emails
If everyone who needs access shares a company domain, use the Email domain selector and enter the domain (like youragency.com). Anyone with an email at that domain can authenticate. Great for your own team, but use carefully on client sites. Only do this if you control the email domain.
Do not lock yourself out
Confirm your own email is in the policy before saving. If it is not listed, you will be denied when you try to visit the page and will have to go back into the Cloudflare dashboard to fix the policy. Save, then test in a private/incognito window immediately.
Test It
DoneSave the application. Cloudflare deploys it within seconds. Open a private or incognito browser window and navigate to the login URL you just protected.
Instead of your application's login page, you should see the Cloudflare Access screen with your team name and a field asking for your email address. Enter your approved email, receive the one-time code in your inbox, enter it, and you will be taken through to the actual application login.
What success looks like
The Cloudflare Access email gate appears before your login page. After entering your email and the code from your inbox, you reach your application's normal login as expected. Everything works exactly as before from that point on.
Troubleshooting
If the Access screen does not appear, confirm the DNS record is orange-clouded (proxied) in Cloudflare. If Access says your email is not authorized, check the policy for typos. If you get a Cloudflare error page, verify the domain and path in the application configuration exactly match the URL you are visiting.
Staying logged in on repeat visits
After your first successful authentication, Cloudflare sets a session cookie for the duration you configured. On subsequent visits within that window, you go straight through to the application login without re-verifying. Use a private window to test the full flow again anytime you want to confirm it is still working.
Common Questions
Will this break my site's front end?
No. Access only intercepts the specific path you configure. Your homepage, product pages, blog, and everything else continues working normally for all visitors without any authentication required.
Will it break WooCommerce customer logins?
WooCommerce uses its own /my-account/ login form by default and does not send customers through /wp-login.php directly. Most stores are fine protecting /wp-login.php. Test your checkout and account login after setup. If customers are affected, protect /wp-admin only instead.
Does this replace two-factor authentication?
It complements it. Access acts before the login page, so attackers never reach the username and password form. You can still run 2FA inside the application on top of this. Both together means an attacker needs to pass the email gate and then defeat 2FA inside the app.
What about automated processes hitting the login path?
Scheduled tasks or server-to-server requests that hit a protected path will be blocked. If you have automation that needs to reach a gated URL, create a Service Token in Cloudflare Access and configure the automated process to present that token. Or restructure the automation to use a path that does not require the login page.
Can I use this on client sites?
Yes. Each Access application is configured per domain. Add the client's email addresses to the policy for their logins. Your own agency email can appear across multiple policies on different client applications if you manage them from the same Zero Trust account.
How do I remove Access later?
Delete the application from Zero Trust under Access → Applications. The gate is removed immediately and the login page goes back to being publicly accessible. No changes are needed to the site or application itself.
Need help with the setup?
Configuring Cloudflare Access for your sites or devices is exactly the kind of thing we handle in a single session. Book a time and we will get it sorted.
Get Help Now