For a CISO, that question is maybe a bit of a nightmare in itself. It does not have one single answer; it has dozens. It’s the constant tension between enabling a globally distributed workforce to do their best work, and ensuring that "best work" does not inadvertently open the door to a catastrophic breach.

We often talk about the "zero trust journey," but the reality is that the journey is almost certainly paved with friction. If security is too cumbersome, users find creative (and dangerous) ways around it. If it’s seamless at the cost of effectiveness, it might not be secure enough to stop a determined adversary.

Today, we are excited to announce two new tools in Cloudflare’s SASE toolbox designed to modernize remote access by eliminating the "dark corners" of your network security without adding friction to the user experience: mandatory authentication and Cloudflare’s own multi-factor authentication (MFA). 

When you deploy the Cloudflare One Client, you gain incredible visibility and control. You can apply policies for permitted destinations, define the Internet traffic that routes through Cloudflare, and set up traffic inspection at both the application and network layer. But there has always been a visibility challenge from when there is no user actually authenticated.

This gap occurs in two primary scenarios:

1. A new device: Cloudflare One Client is installed via mobile device management (MDM), but the user has not authenticated yet.

2. Re-authentication grey zone: The session expires, and the user, either out of forgetfulness or a desire to bypass restrictions, does not log back in.

In either case, the device is now unknown. This is dangerous. You lose visibility, and your security posture reverts to whatever the local machine allows.

To close this loop, we are introducing mandatory authentication. When enabled via your MDM configuration, the Cloudflare One Client becomes the gatekeeper of Internet access from the moment the machine boots up.

If a user is not actively authenticated, the Cloudflare One client will:

• Block all Internet traffic by default using the system firewall.

• Allow traffic from the device client’s authentication flow using a process-specific exception.

• Prompt users to authenticate, guiding them through the process, so they don’t have to hunt for the right buttons.

By making authentication a prerequisite for connectivity, you ensure that every managed device is accounted for, all the time.

Note: mandatory authentication will become available in our Cloudflare One client on Windows initially, with support for other platforms to follow. 

Most organizations have moved toward single sign-on (SSO) as their primary security anchor. If you use Okta, Entra ID, or Google, you likely require MFA at the initial login. That’s a great start, but in a modern threat landscape, it is no longer the finish line.

The hard truth is that identity providers (IdPs) are high-value targets. If an attacker successfully compromises a user’s SSO session, perhaps through a sophisticated session hijacking or social engineering, they effectively hold the keys to every application behind that SSO.

This is where Cloudflare’s MFA can help. Think of this as a "step-up MFA" that lives at the network edge, independent of your IdP.

By remaining separate from your IdP, this introduces another authority that has to “sign off” on any user trying to access a protected resource. That means even if your primary IdP credentials are compromised or spoofed, an attacker will hit a wall when trying to access something like your production database—because they do not have access to the second factor.

Cloudflare Access will offer a few different means of providing MFA:

• Biometrics (i.e., Windows Hello, Apple Touch ID, and Apple Face ID)

• Security key (WebAuthn and FIDO2 as well as PIV for SSH with Access for Infrastructure)

• Time-based one-time password (TOTP) through authenticator apps

Administrators will have the flexibility to define how users must authenticate and how often. This can be configured not only at a global level (i.e., establish mandatory MFA for all Access applications), but also with more granular controls for specific applications or policies. For example, your organization may decide to allow lower assurance MFA methods for chat apps, but require a security key for access to source code.

Or, you could enforce strong MFA to sensitive resources for third-parties like contractors, who otherwise may use a personal email or social identity like LinkedIn. You can also easily add modern MFA methods to legacy apps that don’t otherwise support it natively, without touching a line of code.

End users will be able to enroll an MFA device easily through their App Launcher.

^{Example of what customizing MFA settings for an Access policy may look like. Note: This is a mockup and may change.}

Cloudflare’s independent MFA is in closed beta with new customers being onboarded each week. You can request access here to try out this new feature!

Security is often a game of "closing the loop." By ensuring that devices are registered and authenticated before they can touch the open Internet and by requiring an independent second layer of verification for your most precious assets, we are making the "blast radius" of a potential attack significantly smaller.

These features don't just add security; they add certainty. Certainty that your policies are being enforced and certainty that a single compromised password won't lead to a total breach.

We are moving beyond simple access control and into a world of continuous, automated posture enforcement. And we’re just getting started.

Ready to lock down your fleet? You can get started today with Cloudflare One for free for up to 50 users. 

We’re excited to see how you use these tools to harden your perimeter and simplify your users’ day-to-day workflows. As always, we’d love to hear your feedback! Join us in the Cloudflare Community or reach out to your account team to share your thoughts.

Sometimes you are dealing with a company acquisition, managing virtual desktops, or working in a highly regulated environment where you simply cannot install software on an endpoint. You still need to protect that traffic, even when you don’t fully manage the device.

Closing this gap requires moving the identity challenge from the device to the network itself. By combining the browser’s native proxy capabilities with our global network, we can verify users and enforce granular policies on any device that can reach the Internet. We’ve built the Gateway Authorization Proxy and Proxy Auto-Configuration (PAC) File Hosting to automate this authentication and simplify how unmanaged devices connect to Cloudflare.

Back in 2022, we released proxy endpoints that allowed you to route traffic through Cloudflare to apply filtering rules. It solved the immediate need for access, but it had a significant "identity crisis."

Because that system relied on static IP addresses to identify users, it was a bit like a security guard who only recognizes cars, not the people inside them. If a car (a specific IP) showed up, it was let in. But if the driver switched cars or worked from a different location, the guard got confused. This created a few major headaches:

• Anonymous Logs: We knew the IP address, but we didn’t know the person.

• Brittle Policies: If a user moved to a new home or office, the endpoint broke or required an update.

• Manual Maintenance: You had to host your own PAC file (the "GPS" that tells your browser where the proxy is) — one more thing for your team to manage.

Authorization proxy Access policy setup page

The new Gateway Authorization Proxy adds a "badge reader" at the entrance. Instead of just looking at where the traffic is coming from, we now use a Cloudflare Access-style login to verify who the user is, before enforcing Gateway filtering.

Think of this as moving from a guest list based on license plates, to a system where everyone has their own badge. This brings several massive benefits:

• True identity integration: Your logs related to proxy endpoints now show exactly which user is accessing which site. You can write specific rules like "only the Finance team can access this accounting tool," even without a client installed on the device.

• Multiple identity providers: This is a superpower for large companies or those undergoing M&A. You can choose which identity providers to show your users. You can display one or multiple login methods (like Okta and Azure AD) at the same time. This is a level of flexibility that competitors don't currently offer.

• Simplified billing: Each user simply occupies a "seat," exactly like they do with the Cloudflare One Client. There are no complicated new metrics to track.

To make this possible, we had to overcome the technical hurdle of associating a user’s identity with every request, and without a device client. Read on to see how it works.

The Authorization Proxy uses signed JWT cookies to maintain identity, but there's a catch: when you first visit a new domain through the proxy, there's no cookie yet. Think of it like showing your badge at each new building you enter.

The flowchart above illustrates exactly how this authentication process works:

• First visit to a domain: When you navigate to a new domain, the Gateway Authorization Proxy checks if a domain identity cookie is present. If not, you're redirected to Cloudflare Access, which then checks for an existing Cloudflare Access identity cookie. If you're already authenticated with Cloudflare Access, we generate a secure token specifically for that domain. If you're not, we redirect you to login with your identity provider(s).

• Invisible to users: This entire process happens in milliseconds thanks to Cloudflare's global edge network. The redirect is so fast that users don't notice it — they simply see their page load normally.

• Repeat visits are instant: Once the cookie is set, all subsequent requests to that domain (and its subdomains) are immediately authorized. No more redirects needed.

Because of this approach, we can log and filter traffic per person across all domains they access, and revoke access in an instant when needed — all without requiring any software installation on the user's device.

We are also taking the "homework" out of the setup process. You can now host your PAC files directly on Cloudflare, using Proxy Auto-Configuration (PAC) File Hosting.

PAC file configuration page

To make it easy, we have included starter templates to get you up and running in minutes. We have also integrated our AI assistant, Cloudy, to provide summaries that help you understand exactly what your PAC file is doing, without having to read through lines of code.

While we still recommend the Cloudflare One Client for greater control and the best user experience, the Auth Proxy is the perfect fit for specific scenarios:

• Virtual desktops (VDI): Environments where users log into a virtual machine and use a browser to reach the Internet.

• Mergers and acquisitions: When you need to bring two different companies under one security umbrella quickly.

• Compliance constraints: When you are legally or technically prohibited from installing software on an endpoint.

This expands our clientless security options to connect to Cloudflare One, and we are already working on expanding our supported identity methods related to Authorization Endpoints. Look out for Kerberos, mTLS, and traditional username/password authentication to give you even more flexibility in how you authenticate your users.

The Gateway Authorization Proxy and PAC File Hosting are available in open beta today for all account types. You can get started by going to the "Resolvers and Proxies" section of your Cloudflare dashboard.