Skip to content

Changelog

New updates and improvements at Cloudflare.

You can now enable Access on a Worker or all Workers at once

You now have two new ways to protect your Workers with Cloudflare Access.

Protect an application across all its domains at once

Until now, if a Worker was reachable on a route, a Custom Domain, and a workers.dev URL, you had to manually add each one to an Access application and keep the list in sync whenever routes or domains changed.

Now, Access attaches the policy to the Worker itself, so every associated domain and preview URL stays protected even when its routes or domains change.

Access setting for protecting a single Worker

Protect all new and existing Workers by default

Make all Workers private by default, so every existing and newly created Worker requires sign-in before anyone can reach it.

Account-wide Access setting that protects all Workers

If a specific Worker should remain publicly accessible, add a Worker-level bypass to exempt it.

Make a Worker public when all Workers are protected

Whether you protect a single application or all Workers at once, you can choose whether to protect preview deployments only or both previews and production, and control who can sign in by Cloudflare account membership, email address, or email domain.

For more advanced policy options, edit the policy in Zero Trust.

Access policy configuration for controlling who can sign in

View all of your Worker Access policies

You can view and manage all of your Access policies in the Access tab of the Workers & Pages section in the dashboard.

Access tab showing all configured Access policies

See who is accessing your Worker

When Access is enabled on your Worker, every authenticated request includes ctx.access. Call ctx.access.getIdentity() to get the user's email, name, and groups — no manual JWT validation required.

export default {
  async fetch(request, env, ctx) {
    if (!ctx.access) {
      return new Response("Access did not run", { status: 401 });
    }

    const identity = await ctx.access.getIdentity();
    return Response.json({ aud: ctx.access.aud, email: identity?.email });
  },
};

Test Access locally

You can now test Cloudflare Access locally with wrangler dev. Add a dev block to your wrangler.jsonc:

{
  "access": {
    "dev": {
      "aud": "my-app",
      "identity": { "email": "admin@example.com" }
    }
  }
}

Your Worker will receive this identity through ctx.access and ctx.access.getIdentity(), letting you test authenticated and unauthenticated flows without deploying. Remove the dev block to simulate unauthenticated requests.

API and programmatic access

You can also set up these policies through the Workers API instead of the dashboard.

Independent MFA supports FIDO2 for infrastructure applications

Infrastructure applications support independent multi-factor authentication (MFA) with FIDO2 keys. You can allow ssh_fido2_key, piv_key, or both in application-level and policy-level MFA settings.

Users enroll FIDO2 keys through the App Launcher and connect with the generated SSH identity. FIDO2 keys for SSH are separate from browser-based WebAuthn security keys and Personal Identity Verification (PIV) keys.

For setup instructions, refer to Enroll a FIDO2 key for infrastructure apps and Configure MFA for infrastructure applications.

Identity-aware controls are now available in AI Gateway

AI Gateway now integrates with Cloudflare Access, giving you two new capabilities:

  • Protect your gateway endpoint. Put your AI Gateway behind Access so you can set policies that control who is allowed to call a specific gateway's endpoint.
  • Identity-aware controls. When traffic reaches AI Gateway through an Access-protected custom domain, AI Gateway can use the authenticated user's Access identity in logs, analytics, routing, and spend controls.

With identity-aware controls, you can set spend limits by authenticated user, control which gateways different users can access, filter logs by user, and build policies without passing user IDs from the client application. AI Gateway adds the verified Access user ID to request metadata as cf.user_id.

For setup instructions, refer to Cloudflare Access.

Control authorization cookies for multi-domain Access applications

Cloudflare Access administrators can now control whether a self-hosted application preemptively sets authorization cookies across its public hostnames.

Previously, Access automatically used eager redirects for applications with five or fewer hostnames. Applications with more than five hostnames received cookies as users visited each hostname. Administrators can now choose either behavior, regardless of the number of hostnames.

The new Eager redirect cookie setting is turned on by default for new applications. After a user signs in, Access redirects the browser through each hostname and sets a CF_Authorization cookie. This supports applications that need to make requests across hostnames before the user visits each one.

For applications with many hostnames, the redirect chain can cause sign-in loops in some browsers. Turn off the setting to issue the cookie only when a user visits each hostname.

To configure the setting, refer to Authorization cookie.

Static OAuth client credentials for MCP server portals

MCP server portals can now connect to upstream MCP servers that require a pre-registered OAuth client. This supports OAuth providers that do not offer Dynamic Client Registration or have disabled it. This unlocks portal connections to major SaaS providers such as Slack and GitHub, whose MCP servers do not yet support DCR.

When adding an MCP server, administrators can enter the client ID and client secret from an OAuth application registered with the upstream provider. The configuration also supports custom OAuth endpoints, scopes, and the client_secret_post and client_secret_basic token endpoint authentication methods.

Cloudflare stores the client secret encrypted. Users still authenticate to the upstream server with their own accounts when they connect through a portal.

For setup instructions, refer to Configure manual OAuth credentials.

Admins can turn on Code Mode by default for MCP portal users

MCP server portals now support four Code Mode policies: Off, Opt-in, On by default, and Enforced. Admins can choose whether Code Mode is unavailable, optional, enabled by default, or required for every session.

Existing portals retain their current behavior. Portals that previously allowed Code Mode use Opt-in, while portals that did not allow Code Mode use Off. New portals also use Opt-in by default.

Clients turn on Code Mode for an Opt-in portal with ?codemode=search_and_execute. The On by default policy lets clients opt out with ?codemode=off, which avoids nested code execution when a client runs its own Code Mode implementation. The Off and Enforced policies ignore client overrides.

The Cloudflare API exposes these policies through the code_mode field:

{
	"code_mode": "default_on"
}

The supported values are off, opt_in, default_on, and enforced. The previous allow_code_mode boolean is deprecated.

For configuration details and client behavior, refer to Code Mode policies.

Browser-based login for plaintext HTTP private applications

Cloudflare Access now uses the standard browser-based login flow for private applications served over plaintext HTTP on port 80.

Previously, plaintext HTTP private apps fell back to the same session flow used for SSH, RDP, and other non-HTTP protocols: users got an Authentication required pop-up from the Cloudflare One Client, then had to select the notification to open a browser and log in. Now, users hitting an HTTP private app see the Access login page directly in the browser and receive a standard Access application token on success.

This brings the HTTP experience in line with HTTPS apps (with Gateway TLS decryption turned on). No configuration change is required. The Cloudflare One Client is still required to route traffic to the private network, but it no longer manages the Access session for HTTP apps.

Other non-HTTP protocols (SSH, RDP, arbitrary TCP/UDP) continue to use the Cloudflare One Client notification flow.

Bulk print PDFs for browser-based RDP

Users in browser-based RDP sessions can now print multiple PDF files as a single print job. Copy the files to your clipboard on the remote machine, then select Print all PDFs in the clipboard panel. The files are combined into one PDF and sent to your local printer.

The clipboard panel showing the Print all PDFs option for multiple selected PDF files.

Bulk print is available in Chromium-based browsers and Firefox. For more information, refer to Print PDFs for browser-based RDP.

File transfer controls for browser-based RDP (beta)

You can now configure file transfer controls for browser-based RDP with Cloudflare Access, allowing you to restrict whether users can upload or download files between their local machine and the remote Windows server.

File transfer connection settings in the Access policy configuration.

This feature is useful for organizations that support bring-your-own-device (BYOD) policies or third-party contractors using unmanaged devices. By restricting file transfers, you can prevent sensitive data from being moved out of the remote session to a user's personal device.

Configuration options

File transfer controls are configured per policy within your Access application, alongside existing text clipboard controls. For each policy, you can select one of the following options:

  • Client to remote RDP session allowed — Users can upload files from their local machine into the browser-based RDP session.
  • Remote RDP session to client allowed — Users can download files from the browser-based RDP session to their local machine.
  • Both directions allowed — Users can upload and download files between their local machine and the browser-based RDP session.
  • Disable copying/pasting — Users are not allowed to transfer files between their local machine and the browser-based RDP session.

By default, file transfer is denied for new policies. For existing Access applications created before this feature was available, file transfer remains denied.

How it works

To upload, drag files into the browser window or select the settings gear icon on the left side of the RDP session. To download, copy a file in the remote session and select the settings gear to download it, download multiple files as a zip, or print PDFs to a local printer.

The clipboard side panel showing files available for transfer.A remote document ready for download or local printing.

This feature is in beta and available on all Zero Trust plans. For more information, refer to File transfer for browser-based RDP.

Fix redirect URL fragment encoding for single-page applications

Access now correctly preserves URL fragment characters (/, ?, =, &, ;) when redirecting users back to an application after login. Previously, these characters were encoded with encodeURIComponent, which mangled fragment-based routes used by single-page applications (SPAs).

For example, an SPA URL like https://app.example.com/#/dashboard?tab=settings&view=advanced would previously redirect to a broken URL after login. This is now handled correctly.

If your SPA users were experiencing broken navigation after authenticating through Access, this fix resolves the issue without any configuration changes.

Independent MFA for infrastructure applications

Access for Infrastructure now supports independent multi-factor authentication (MFA) for SSH connections using YubiKey PIV keys. This adds a hardware-backed second factor to SSH access, ensuring that a compromised device session alone is not sufficient to reach your servers.

With per-application and per-policy configuration, you can enforce PIV key authentication for sensitive usernames (for example, root) while applying different requirements for other usernames. You can also set an MFA session duration to control how often users must re-authenticate.

Enrollment

Users enroll their YubiKey PIV key through the App Launcher. For enrollment instructions and SSH client setup, refer to Enroll a PIV key for infrastructure apps.

Configuration

For setup instructions, refer to Enforce MFA for infrastructure applications.

Service token support for MCP server portals

You can now connect autonomous agents and bots to an MCP server portal using an Access service token. Service token sessions can reach upstream MCP servers through the portal without a browser-based OAuth flow.

To set this up:

  • Add a Service Auth policy that matches your service token to the portal's Access application.
  • Add a Service Auth policy that matches the same token to each linked MCP server's Access application.
  • Turn Require user auth off (on_behalf: false) for each linked server so the portal uses the admin credential instead of a per-user OAuth grant.

The bot connects with CF-Access-Client-Id and CF-Access-Client-Secret headers and sees the tools from every linked server it is authorized for. Servers that still require per-user OAuth are excluded from service token sessions because a service token cannot complete a per-user OAuth grant.

For step-by-step setup, refer to Connect with a service token.

Cloudflare identity provider is now the default for new accounts

When you create a new Zero Trust organization, Cloudflare now adds the Cloudflare identity provider as your default login method. Previously, new organizations started with one-time PIN (OTP).

With the Cloudflare identity provider, your users authenticate using their existing Cloudflare account credentials, and authentication is restricted to members of your account. You can still add OTP or connect any third-party identity provider whenever you need to.

This change only applies to newly created accounts. Existing organizations keep the login methods they already have configured. If you would like to use the Cloudflare Identity Provider in an existing account, you must enable it.

Share identity providers across accounts with IdP federation

Cloudflare Access now supports IdP federation, which allows organizations to share a single identity provider across multiple Cloudflare accounts.

Instead of configuring the same IdP (for example, Okta or Entra ID) separately in every account, you configure it once in a source account and share it with the other accounts in your organization. Each recipient account gets a read-only IdP connection that routes authentication back to the source account through a bridge — a hidden application in the source account that brokers the cross-account login. End users sign in with their existing IdP credentials, and each account's Access policies evaluate the resulting identity just like any other IdP login.

Key capabilities:

  • One IdP, many accounts — Configure your IdP once and share it with all accounts in your organization.
  • Lifecycle management — As accounts join or leave your Cloudflare organization, their IdP connections are provisioned and removed automatically — no manual cleanup required.
  • Immutable recipient connections — IdP connections in recipient accounts cannot be accidentally modified or deleted.

To get started, refer to IdP federation.

SAML assertion encryption for identity providers

Cloudflare Access now supports SAML assertion encryption for identity provider integrations. When turned on, your identity provider encrypts SAML assertions using a Cloudflare-managed certificate before sending them through the user's browser. Only Access can decrypt these assertions, protecting sensitive identity data even after TLS termination.

Without encryption, SAML assertions are transmitted in plaintext and could be visible to browser extensions or client-side malware.

SAML encryption toggle in the identity provider configuration

SAML encryption includes built-in certificate lifecycle management:

  • Automatic certificate generation: Access generates an encryption certificate when you turn on SAML encryption for an identity provider.
  • Certificate rotation: Rotate certificates without downtime. The previous certificate remains valid until expiration, giving you time to update your IdP.
  • PEM export: Copy the certificate in PEM format for manual upload to your IdP, or point your IdP to the SAML metadata endpoint for automatic retrieval.

To get started, refer to Encrypt SAML assertions.

Tool and prompt aliases for MCP server portals

When you connect third-party MCP servers through MCP server portals, you have no control over how the server author named tools or wrote descriptions. Unclear names make it harder for AI agents to select the right tool and harder for users to understand what is available.

You can now rename tools and prompts and rewrite their descriptions directly on the portal, without modifying the upstream server. For example, a tool named super_cool_tool can become search_customer_records with a description tailored to your organization.

Edit tool modal showing name and description fields for an MCP server tool

Modified tools display a Modified label in the tools list so administrators can see which tools have been customized at a glance.

Tools authorized list showing a modified label on a renamed tool

Aliases override the metadata that MCP clients receive. You can set them at two levels:

  • Per portal: Applies only within a specific portal. Takes precedence over server-level aliases.
  • Per server: Applies across all portals that use the server.

You can reset an alias at any time to restore the original upstream name.

For more information, refer to Tool and prompt aliases.

Cloudflare as identity provider and account membership selector

Cloudflare Access now supports using Cloudflare itself as an identity provider. If you publish an Access application and select Cloudflare as the login method, users can sign in with their existing Cloudflare account — no one-time PINs, no third-party IdP configuration, and no shared email inboxes. Authentication is backed by Cloudflare's own account security (including multi-factor authentication), making it both simpler to set up and more secure than OTP-based login for most use cases.

Cloudflare is now the default identity provider for all newly created Zero Trust accounts, replacing One-time PIN.

This also enables two new capabilities:

  • Cloudflare Account Member selector — A new policy selector that matches users based on their membership in a Cloudflare account. You can target the current account or specify a different account ID for cross-account access scenarios.
  • Restrict to account members — An identity provider configuration option that limits authentication to users who are members of your Cloudflare account.

To get started, add Cloudflare as an identity provider in your Zero Trust settings.

Refreshed Access login page

The Access login page and one-time password (OTP) page now feature a refreshed design that improves visual consistency, user trust, and mobile responsiveness.

Before:

Screenshot of the previous Access login page

After:

Screenshot of the updated Access login page

The updated login experience includes:

  • Unified authentication card - All sign-in options (identity provider buttons, email input, OTP) now appear in a single card with consistent styling, replacing the previous multi-section layout.
  • Consistent button styling - Identity provider buttons use a uniform size and layout for easier scanning and selection.
  • Better mobile experience - Responsive layout improvements ensure the login page renders correctly on phones and tablets.
  • Dark mode support - The login page now supports dark mode.

AAGUID restrictions and AMR matching for Access independent MFA

Independent MFA in Cloudflare Access now supports two additional organization-level controls:

  • Restrict authenticators by AAGUID — Limit enrollment to a specific set of WebAuthn authenticators using their AAGUID. This is useful for organizations that require FIPS-validated security keys or company-issued hardware. AAGUIDs are managed through a new List type.
  • AMR matching — Skip the independent MFA prompt when the identity provider has already performed an equivalent MFA. Access reads the amr claim defined in RFC 8176 and matches supported values such as hwk, otp, and fpt to the authenticator types allowed on the application or policy. This prevents users from having to complete MFA twice when their identity provider already enforces it.

To get started, refer to Independent MFA.

Homepage and sign-out for MCP server portals

MCP server portals display a homepage when users visit the portal domain in a browser.

MCP server portal homepage showing connection status and setup instructions

The homepage shows:

  • The portal name and organization branding
  • The MCP endpoint URL with a copy button
  • Per-client connection instructions for Claude Desktop, Workers AI Playground, OpenCode, Windsurf, and other MCP clients

Authenticated users see their email address and a Sign out button. Selecting Sign out revokes all portal-level OAuth grants, deletes upstream server OAuth states, and redirects through Cloudflare Access logout. A confirmation page shows a summary of the revoked sessions.

For more information, refer to MCP server portals.

Independent MFA for Access applications

Cloudflare Access now supports independent multi-factor authentication (MFA), allowing you to enforce MFA requirements without relying on your identity provider (IdP). With per-application and per-policy configuration, you can enforce stricter authentication methods like hardware security keys on sensitive applications without requiring them across your entire organization. This reduces the risk of MFA fatigue for your broader user population while adding additional security where it matters most.

This feature also addresses common gaps in IdP-based MFA, such as inconsistent MFA policies across different identity providers or the need for additional security layers beyond what the IdP provides.

Independent MFA supports the following authenticator types:

  • Authenticator application — Time-based one-time passwords (TOTP) using apps like Google Authenticator, Microsoft Authenticator, or Authy.
  • Security key — Hardware security keys such as YubiKeys.
  • Biometrics — Built-in device authenticators including Apple Touch ID, Apple Face ID, and Windows Hello.

Configuration levels

You can configure MFA requirements at three levels:

Level Description
Organization Enforce MFA by default for all applications in your account.
Application Require or turn off MFA for a specific application.
Policy Require or turn off MFA for users who match a specific policy.

Settings at lower levels (policy) override settings at higher levels (organization), giving you granular control over MFA enforcement.

User enrollment

Users enroll their authenticators through the App Launcher. To help with onboarding, administrators can share a direct enrollment link: <your-team-name>.cloudflareaccess.com/AddMfaDevice.

To get started with Independent MFA, refer to Independent MFA.

Session management for MCP server portals

MCP server portals support in-session management of upstream MCP server connections. Users can return to the server selection page at any time to enable or disable servers, reauthenticate, or change which data a server has access to — all without leaving their MCP client.

To return to the server selection page, ask your AI agent with a prompt like "take me back to the server selection page." The portal responds with an authorization URL via MCP elicitation that you open in your browser:

https://<subdomain>.<domain>/authorize?elicitationId=<ELICITATION_ID>

From the server selection page you can:

  • Enable or disable servers — Toggle individual upstream MCP servers on or off. Disabling a server removes its tools from the active session, which reduces context window usage.
  • Log out and reauthenticate — Log out of a server and log back in to change which data the server has access to, or to reauthenticate with different permissions.

Users can also enable or disable a server inline by asking their AI agent directly, for example "enable the wiki server" or "disable my Jira server."

The portal also automatically prompts connected users to authorize new servers when an admin adds them to the portal. This requires the use of managed OAuth.

For more information, refer to Manage portal sessions.

Logs UI refresh

Access authentication logs and Gateway activity logs (DNS, Network, and HTTP) now feature a refreshed user interface that gives you more flexibility when viewing and analyzing your logs.

Screenshot of the new logs UI showing DNS query logs with customizable columns and filtering options

The updated UI includes:

  • Filter by field - Select any field value to add it as a filter and narrow down your results.
  • Customizable fields - Choose which fields to display in the log table. Querying for fewer fields improves log loading performance.
  • View details - Select a timestamp to view the full details of a log entry.
  • Switch to classic view - Return to the previous log viewer interface if needed.

For more information, refer to Access authentication logs and Gateway activity logs.

Code Mode for MCP server portals

MCP server portals support Code Mode MCP server patterns, a technique that reduces context window usage by replacing individual tool definitions with a single code execution tool. Code Mode is turned on by default on all portals.

To turn it off, edit the portal in Access controls > AI controls and turn off Code Mode under Basic information.

When Code Mode is active, the portal exposes a single code tool instead of listing every tool from every upstream MCP server. The connected AI agent writes JavaScript that calls typed codemode.* methods for each upstream tool. The generated code runs in an isolated Dynamic Worker environment, keeping authentication credentials and environment variables out of the model context.

To use Code Mode, append ?codemode=search_and_execute to your portal URL when connecting from an MCP client:

https://<subdomain>.<domain>/mcp?codemode=search_and_execute

For more information, refer to Code Mode.

Context optimization for MCP server portals

MCP server portals support two context optimization options that reduce how many tokens tool definitions consume in the model's context window. Both options are activated by appending the optimize_context query parameter to the portal URL.

minimize_tools

Strips tool descriptions and input schemas from all upstream tools, leaving only their names. The portal exposes a special query tool that agents use to retrieve full definitions on demand. This provides up to 5x savings in token usage.

https://<subdomain>.<domain>/mcp?optimize_context=minimize_tools

search_and_execute

Hides all upstream tools and exposes only two tools: query and execute. The query tool searches and retrieves tool definitions. The execute tool runs the upstream tools in an isolated Dynamic Worker environment. This reduces the initial token cost to a small constant, regardless of how many tools are available through the portal.

https://<subdomain>.<domain>/mcp?optimize_context=search_and_execute

For more information, refer to Optimize context.