--- title: Access Changelog image: https://edgetunnel-b2h.pages.dev/cf-twitter-card.png --- > Documentation Index > Fetch the complete documentation index at: https://edgetunnel-b2h.pages.dev/changelog/llms.txt > Use this file to discover all available pages before exploring further. [Skip to content](#%5Ftop) # Changelog New updates and improvements at Cloudflare. [ Subscribe to RSS ](https://edgetunnel-b2h.pages.dev/changelog/rss/index.xml) [ View RSS feeds ](https://edgetunnel-b2h.pages.dev/fundamentals/new-features/available-rss-feeds/) Access ![hero image](https://edgetunnel-b2h.pages.dev/_astro/hero.CVYJHPAd_26AMqX.svg) Jul 20, 2026 1. ### [Browser-based login for plaintext HTTP private applications](https://edgetunnel-b2h.pages.dev/changelog/post/2026-07-20-http-private-apps-l7-auth/) [ Access ](https://edgetunnel-b2h.pages.dev/cloudflare-one/access-controls/policies/) Cloudflare Access now uses the standard browser-based login flow for [private applications](https://edgetunnel-b2h.pages.dev/cloudflare-one/access-controls/applications/non-http/self-hosted-private-app/) 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](https://edgetunnel-b2h.pages.dev/cloudflare-one/access-controls/applications/http-apps/authorization-cookie/application-token/) on success. This brings the HTTP experience in line with HTTPS apps (with [Gateway TLS decryption](https://edgetunnel-b2h.pages.dev/cloudflare-one/traffic-policies/http-policies/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. Jul 16, 2026 1. ### [Bulk print PDFs for browser-based RDP](https://edgetunnel-b2h.pages.dev/changelog/post/2026-07-16-rdp-bulk-print/) [ Access ](https://edgetunnel-b2h.pages.dev/cloudflare-one/access-controls/policies/)[ Cloudflare One ](https://edgetunnel-b2h.pages.dev/cloudflare-one/) 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.](https://edgetunnel-b2h.pages.dev/_astro/rdp-bulk-print.DT4sCcI-_Z1XuBEQ.webp) Bulk print is available in Chromium-based browsers and Firefox. For more information, refer to [Print PDFs for browser-based RDP](https://edgetunnel-b2h.pages.dev/cloudflare-one/networks/connectors/cloudflare-tunnel/use-cases/rdp/rdp-browser/#print-pdfs). Jul 07, 2026 1. ### [File transfer controls for browser-based RDP (beta)](https://edgetunnel-b2h.pages.dev/changelog/post/2026-07-07-rdp-file-transfer-beta/) [ Access ](https://edgetunnel-b2h.pages.dev/cloudflare-one/access-controls/policies/)[ Cloudflare One ](https://edgetunnel-b2h.pages.dev/cloudflare-one/) 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.](https://edgetunnel-b2h.pages.dev/_astro/file-transfer-policy-control.CiSEa5rr_Z1oqxAg.webp) 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](https://edgetunnel-b2h.pages.dev/cloudflare-one/networks/connectors/cloudflare-tunnel/use-cases/rdp/rdp-browser/#connection-settings). 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.](https://edgetunnel-b2h.pages.dev/_astro/clipboard-side-panel.Us2RfXfs_Z1hkXRl.webp) ![A remote document ready for download or local printing.](https://edgetunnel-b2h.pages.dev/_astro/remote-doc-ready-for-download-or-print-local.Dcm5hrGD_kMExI.webp) This feature is in beta and available on all Zero Trust plans. For more information, refer to [File transfer for browser-based RDP](https://edgetunnel-b2h.pages.dev/cloudflare-one/networks/connectors/cloudflare-tunnel/use-cases/rdp/rdp-browser/#transfer-files). Jul 01, 2026 1. ### [Fix redirect URL fragment encoding for single-page applications](https://edgetunnel-b2h.pages.dev/changelog/post/2026-07-01-spa-redirect-fragment-fix/) [ Access ](https://edgetunnel-b2h.pages.dev/cloudflare-one/access-controls/policies/) 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. Jul 01, 2026 1. ### [Independent MFA for infrastructure applications](https://edgetunnel-b2h.pages.dev/changelog/post/2026-07-01-ssh-mfa-piv-keys/) [ Access ](https://edgetunnel-b2h.pages.dev/cloudflare-one/access-controls/policies/) [Access for Infrastructure](https://edgetunnel-b2h.pages.dev/cloudflare-one/access-controls/applications/non-http/infrastructure-apps/) 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](https://edgetunnel-b2h.pages.dev/cloudflare-one/access-controls/access-settings/app-launcher/). For enrollment instructions and SSH client setup, refer to [Enroll a PIV key for infrastructure apps](https://edgetunnel-b2h.pages.dev/cloudflare-one/access-controls/access-settings/independent-mfa/#enroll-a-piv-key-for-infrastructure-apps). #### Configuration For setup instructions, refer to [Enforce MFA for infrastructure applications](https://edgetunnel-b2h.pages.dev/cloudflare-one/access-controls/policies/mfa-requirements/#infrastructure-applications). Jun 26, 2026 1. ### [Service token support for MCP server portals](https://edgetunnel-b2h.pages.dev/changelog/post/2026-06-26-mcp-portal-service-tokens/) [ Cloudflare One ](https://edgetunnel-b2h.pages.dev/cloudflare-one/)[ Access ](https://edgetunnel-b2h.pages.dev/cloudflare-one/access-controls/policies/) You can now connect autonomous agents and bots to an [MCP server portal](https://edgetunnel-b2h.pages.dev/cloudflare-one/access-controls/ai-controls/mcp-portals/) using an [Access service token](https://edgetunnel-b2h.pages.dev/cloudflare-one/access-controls/service-credentials/service-tokens/). 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](https://edgetunnel-b2h.pages.dev/cloudflare-one/access-controls/policies/#service-auth) 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](https://edgetunnel-b2h.pages.dev/cloudflare-one/access-controls/ai-controls/mcp-portals/#connect-with-a-service-token). Jun 18, 2026 1. ### [Cloudflare identity provider is now the default for new accounts](https://edgetunnel-b2h.pages.dev/changelog/post/2026-06-18-cloudflare-idp-default/) [ Cloudflare One ](https://edgetunnel-b2h.pages.dev/cloudflare-one/)[ Access ](https://edgetunnel-b2h.pages.dev/cloudflare-one/access-controls/policies/) When you create a new Zero Trust organization, Cloudflare now adds the [Cloudflare identity provider](https://edgetunnel-b2h.pages.dev/cloudflare-one/integrations/identity-providers/cloudflare/) as your default login method. Previously, new organizations started with [one-time PIN (OTP)](https://edgetunnel-b2h.pages.dev/cloudflare-one/integrations/identity-providers/one-time-pin/). 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](https://edgetunnel-b2h.pages.dev/cloudflare-one/integrations/identity-providers/) 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. Jun 04, 2026 1. ### [Share identity providers across accounts with IdP federation](https://edgetunnel-b2h.pages.dev/changelog/post/2026-06-04-idp-federation/) [ Access ](https://edgetunnel-b2h.pages.dev/cloudflare-one/access-controls/policies/) Cloudflare Access now supports [IdP federation](https://edgetunnel-b2h.pages.dev/cloudflare-one/integrations/identity-providers/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](https://edgetunnel-b2h.pages.dev/cloudflare-one/integrations/identity-providers/idp-federation/). Jun 03, 2026 1. ### [SAML assertion encryption for identity providers](https://edgetunnel-b2h.pages.dev/changelog/post/2026-06-03-saml-assertion-encryption/) [ Access ](https://edgetunnel-b2h.pages.dev/cloudflare-one/access-controls/policies/) 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](https://edgetunnel-b2h.pages.dev/_astro/saml-encryption.J5jmiYv8_ZkhXFT.webp) 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](https://edgetunnel-b2h.pages.dev/cloudflare-one/integrations/identity-providers/generic-saml/#encrypt-saml-assertions). May 28, 2026 1. ### [Tool and prompt aliases for MCP server portals](https://edgetunnel-b2h.pages.dev/changelog/post/2026-05-28-mcp-portal-tool-prompt-aliases/) [ Access ](https://edgetunnel-b2h.pages.dev/cloudflare-one/access-controls/policies/) When you connect third-party MCP servers through [MCP server portals](https://edgetunnel-b2h.pages.dev/cloudflare-one/access-controls/ai-controls/mcp-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](https://edgetunnel-b2h.pages.dev/cloudflare-one/access-controls/ai-controls/mcp-portals/#rename-tools-and-prompts-with-aliases) 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](https://edgetunnel-b2h.pages.dev/_astro/portal-edit-tool-modal.DrxORhBl_Z1NtRnj.webp) 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](https://edgetunnel-b2h.pages.dev/_astro/portal-tools-authorized-modified.B674Xvip_12xxcK.webp) 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](https://edgetunnel-b2h.pages.dev/cloudflare-one/access-controls/ai-controls/mcp-portals/#rename-tools-and-prompts-with-aliases). May 19, 2026 1. ### [Cloudflare as identity provider and account membership selector](https://edgetunnel-b2h.pages.dev/changelog/post/2026-05-19-cloudflare-as-identity-provider/) [ Access ](https://edgetunnel-b2h.pages.dev/cloudflare-one/access-controls/policies/) Cloudflare Access now supports using Cloudflare itself as an [identity provider](https://edgetunnel-b2h.pages.dev/cloudflare-one/integrations/identity-providers/cloudflare/). 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](https://edgetunnel-b2h.pages.dev/cloudflare-one/access-controls/policies/#cloudflare-access-selectors) 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](https://edgetunnel-b2h.pages.dev/cloudflare-one/integrations/identity-providers/cloudflare/) in your Zero Trust settings. May 12, 2026 1. ### [Refreshed Access login page](https://edgetunnel-b2h.pages.dev/changelog/post/2026-05-12-access-login-page-refresh/) [ Cloudflare One ](https://edgetunnel-b2h.pages.dev/cloudflare-one/)[ Access ](https://edgetunnel-b2h.pages.dev/cloudflare-one/access-controls/policies/) The [Access login page](https://edgetunnel-b2h.pages.dev/cloudflare-one/reusable-components/custom-pages/access-login-page/) and [one-time password (OTP)](https://edgetunnel-b2h.pages.dev/cloudflare-one/integrations/identity-providers/one-time-pin/) page now feature a refreshed design that improves visual consistency, user trust, and mobile responsiveness. **Before:** ![Screenshot of the previous Access login page](https://edgetunnel-b2h.pages.dev/_astro/access-login-old.CwNVkCQH_Z187ARH.webp) **After:** ![Screenshot of the updated Access login page](https://edgetunnel-b2h.pages.dev/_astro/access-login-new.Y7WUfg9G_1QeY33.webp) 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. Apr 23, 2026 1. ### [AAGUID restrictions and AMR matching for Access independent MFA](https://edgetunnel-b2h.pages.dev/changelog/post/2026-04-23-independent-mfa-aaguid-amr/) [ Access ](https://edgetunnel-b2h.pages.dev/cloudflare-one/access-controls/policies/) [Independent MFA](https://edgetunnel-b2h.pages.dev/cloudflare-one/access-controls/access-settings/independent-mfa/) in Cloudflare Access now supports two additional organization-level controls: * **[Restrict authenticators by AAGUID](https://edgetunnel-b2h.pages.dev/cloudflare-one/access-controls/access-settings/independent-mfa/#restrict-authenticators-by-aaguid)** — Limit enrollment to a specific set of WebAuthn authenticators using their [AAGUID ↗](https://fidoalliance.org/specs/fido-v2.0-id-20180227/fido-registry-v2.0-id-20180227.html#authenticator-attestation-guid). This is useful for organizations that require FIPS-validated security keys or company-issued hardware. AAGUIDs are managed through a new [List](https://edgetunnel-b2h.pages.dev/cloudflare-one/reusable-components/lists/) type. * **[AMR matching](https://edgetunnel-b2h.pages.dev/cloudflare-one/access-controls/access-settings/independent-mfa/#use-identity-provider-mfa)** — Skip the independent MFA prompt when the identity provider has already performed an equivalent MFA. Access reads the `amr` claim defined in [RFC 8176 ↗](https://datatracker.ietf.org/doc/html/rfc8176) 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](https://edgetunnel-b2h.pages.dev/cloudflare-one/access-controls/access-settings/independent-mfa/). Apr 17, 2026 1. ### [Homepage and sign-out for MCP server portals](https://edgetunnel-b2h.pages.dev/changelog/post/2026-04-17-mcp-portal-homepage-and-sign-out/) [ Access ](https://edgetunnel-b2h.pages.dev/cloudflare-one/access-controls/policies/) [MCP server portals](https://edgetunnel-b2h.pages.dev/cloudflare-one/access-controls/ai-controls/mcp-portals/) display a homepage when users visit the portal domain in a browser. ![MCP server portal homepage showing connection status and setup instructions](https://edgetunnel-b2h.pages.dev/_astro/portals-homepage-disconnected.BHbOwayQ_Z1G37WD.webp) 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](https://edgetunnel-b2h.pages.dev/cloudflare-one/access-controls/ai-controls/mcp-portals/#portal-homepage). Apr 15, 2026 1. ### [Independent MFA for Access applications](https://edgetunnel-b2h.pages.dev/changelog/post/2026-04-15-independent-mfa/) [ Access ](https://edgetunnel-b2h.pages.dev/cloudflare-one/access-controls/policies/) 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. Note Infrastructure applications do not yet support independent MFA. #### 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](https://edgetunnel-b2h.pages.dev/cloudflare-one/access-controls/access-settings/app-launcher/). To help with onboarding, administrators can share a direct enrollment link: `.cloudflareaccess.com/AddMfaDevice`. To get started with Independent MFA, refer to [Independent MFA](https://edgetunnel-b2h.pages.dev/cloudflare-one/access-controls/access-settings/independent-mfa/). Apr 02, 2026 1. ### [Session management for MCP server portals](https://edgetunnel-b2h.pages.dev/changelog/post/2026-04-02-mcp-portal-session-management/) [ Access ](https://edgetunnel-b2h.pages.dev/cloudflare-one/access-controls/policies/) [MCP server portals](https://edgetunnel-b2h.pages.dev/cloudflare-one/access-controls/ai-controls/mcp-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 ↗](https://modelcontextprotocol.io/specification/2025-03-26/server/elicitation) that you open in your browser: ```txt https://./authorize?elicitationId= ``` 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](https://edgetunnel-b2h.pages.dev/cloudflare-one/access-controls/applications/http-apps/managed-oauth/#enable-managed-oauth-on-an-mcp-server-portal). For more information, refer to [Manage portal sessions](https://edgetunnel-b2h.pages.dev/cloudflare-one/access-controls/ai-controls/mcp-portals/#manage-portal-sessions). Apr 01, 2026 1. ### [Logs UI refresh](https://edgetunnel-b2h.pages.dev/changelog/post/2026-04-01-logs-ui-refresh/) [ Cloudflare One ](https://edgetunnel-b2h.pages.dev/cloudflare-one/)[ Access ](https://edgetunnel-b2h.pages.dev/cloudflare-one/access-controls/policies/)[ Gateway ](https://edgetunnel-b2h.pages.dev/cloudflare-one/traffic-policies/) 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](https://edgetunnel-b2h.pages.dev/_astro/cf1-new-logs-ui.DxF4x0l-_mRSyH.webp) 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](https://edgetunnel-b2h.pages.dev/cloudflare-one/insights/logs/dashboard-logs/access-authentication-logs/) and [Gateway activity logs](https://edgetunnel-b2h.pages.dev/cloudflare-one/insights/logs/dashboard-logs/gateway-logs/). Mar 26, 2026 1. ### [Code Mode for MCP server portals](https://edgetunnel-b2h.pages.dev/changelog/post/2026-03-26-mcp-portal-code-mode/) [ Access ](https://edgetunnel-b2h.pages.dev/cloudflare-one/access-controls/policies/) [MCP server portals](https://edgetunnel-b2h.pages.dev/cloudflare-one/access-controls/ai-controls/mcp-portals/) support [Code Mode MCP server patterns](https://edgetunnel-b2h.pages.dev/agents/model-context-protocol/codemode/), 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](https://edgetunnel-b2h.pages.dev/workers/runtime-apis/bindings/worker-loader/) 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: ```txt https://./mcp?codemode=search_and_execute ``` For more information, refer to [Code Mode](https://edgetunnel-b2h.pages.dev/cloudflare-one/access-controls/ai-controls/mcp-portals/#code-mode). Mar 26, 2026 1. ### [Context optimization for MCP server portals](https://edgetunnel-b2h.pages.dev/changelog/post/2026-03-26-mcp-portal-context-optimization/) [ Access ](https://edgetunnel-b2h.pages.dev/cloudflare-one/access-controls/policies/) [MCP server portals](https://edgetunnel-b2h.pages.dev/cloudflare-one/access-controls/ai-controls/mcp-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. ```txt https://./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](https://edgetunnel-b2h.pages.dev/workers/runtime-apis/bindings/worker-loader/) environment. This reduces the initial token cost to a small constant, regardless of how many tools are available through the portal. ```txt https://./mcp?optimize_context=search_and_execute ``` For more information, refer to [Optimize context](https://edgetunnel-b2h.pages.dev/cloudflare-one/access-controls/ai-controls/mcp-portals/#optimize-context). Mar 20, 2026 1. ### [Managed OAuth for Cloudflare Access](https://edgetunnel-b2h.pages.dev/changelog/post/2026-03-20-managed-oauth/) [ Access ](https://edgetunnel-b2h.pages.dev/cloudflare-one/access-controls/policies/) Cloudflare Access supports managed OAuth, which allows non-browser clients — such as CLIs, AI agents, SDKs, and scripts — to authenticate with Access-protected applications using a standard OAuth 2.0 authorization code flow. Previously, non-browser clients that attempted to access a protected application received a `302` redirect to a login page they could not complete. The established workaround was `cloudflared access curl`, which required installing additional tooling. With managed OAuth, clients instead receive a `401` response with a `WWW-Authenticate` header that points to Access's OAuth discovery endpoints ([RFC 8414 ↗](https://datatracker.ietf.org/doc/html/rfc8414) and [RFC 9728 ↗](https://datatracker.ietf.org/doc/html/rfc9728)). The client opens the end user's browser to the Access login page. The end user authenticates with their identity provider, and the client receives an OAuth access token for subsequent requests. Access enforces the same policies as a browser login; the OAuth layer is a new transport mechanism, not a separate authentication path. Managed OAuth can be enabled on any self-hosted Access application or [MCP server portal](https://edgetunnel-b2h.pages.dev/cloudflare-one/access-controls/ai-controls/mcp-portals/). It is opt-in for existing applications to avoid interfering with those that run their own OAuth servers and rely on their own `WWW-Authenticate` headers. Note For MCP server portals, managed OAuth is enabled by default on new portals. It remains opt-in for self-hosted applications. To enable managed OAuth, go to **Zero Trust** \> **Access controls** \> **Applications**, edit the application, and turn on **Managed OAuth** under **Advanced settings**. You can also enable it via the API by setting `oauth_configuration.enabled` to `true` on the [Access applications endpoint](https://edgetunnel-b2h.pages.dev/api/resources/zero%5Ftrust/subresources/access/subresources/applications/methods/update/). ![Managed OAuth settings in the Cloudflare dashboard](https://edgetunnel-b2h.pages.dev/_astro/managed-oauth.BirLnBpy_Zjg97R.webp) For setup instructions, refer to [Enable managed OAuth](https://edgetunnel-b2h.pages.dev/cloudflare-one/access-controls/applications/http-apps/managed-oauth/). Mar 20, 2026 1. ### [Route MCP server portal traffic through Cloudflare Gateway](https://edgetunnel-b2h.pages.dev/changelog/post/2026-03-20-mcp-portal-gateway-routing/) [ Access ](https://edgetunnel-b2h.pages.dev/cloudflare-one/access-controls/policies/) [MCP server portals](https://edgetunnel-b2h.pages.dev/cloudflare-one/access-controls/ai-controls/mcp-portals/) can now route traffic through [Cloudflare Gateway](https://edgetunnel-b2h.pages.dev/cloudflare-one/traffic-policies/) for richer HTTP request logging and data loss prevention (DLP) scanning. When Gateway routing is turned on, portal traffic appears in your [Gateway HTTP logs](https://edgetunnel-b2h.pages.dev/cloudflare-one/insights/logs/dashboard-logs/gateway-logs/). You can create [Gateway HTTP policies](https://edgetunnel-b2h.pages.dev/cloudflare-one/traffic-policies/) with [DLP profiles](https://edgetunnel-b2h.pages.dev/cloudflare-one/data-loss-prevention/dlp-profiles/) to detect and block sensitive data sent to upstream MCP servers. Note DLP [AI prompt profiles](https://edgetunnel-b2h.pages.dev/cloudflare-one/data-loss-prevention/dlp-profiles/predefined-profiles/#ai-prompt) do not apply to MCP server portal traffic. To enable Gateway routing, go to **Access controls** \> **AI controls**, edit the portal, and turn on **Route traffic through Cloudflare Gateway** under **Basic information**. ![Route MCP server portal traffic through Cloudflare Gateway](https://edgetunnel-b2h.pages.dev/_astro/portal-route-through-gateway.0KMUAXBm_Z1B5rry.webp) For more details, refer to [Route traffic through Gateway](https://edgetunnel-b2h.pages.dev/cloudflare-one/access-controls/ai-controls/mcp-portals/#route-portal-traffic-through-gateway). Mar 04, 2026 1. ### [User risk score selector in Access policies](https://edgetunnel-b2h.pages.dev/changelog/post/2026-03-04-user-risk-score-access-policies/) [ Cloudflare One ](https://edgetunnel-b2h.pages.dev/cloudflare-one/)[ Access ](https://edgetunnel-b2h.pages.dev/cloudflare-one/access-controls/policies/) You can now use [user risk scores](https://edgetunnel-b2h.pages.dev/cloudflare-one/team-and-resources/users/risk-score/) in your [Access policies](https://edgetunnel-b2h.pages.dev/cloudflare-one/access-controls/policies/). The new **User Risk Score** selector allows you to create Access policies that respond to user behavior patterns detected by Cloudflare's risk scoring system, including impossible travel, high DLP policy matches, and more. For more information, refer to [Use risk scores in Access policies](https://edgetunnel-b2h.pages.dev/cloudflare-one/team-and-resources/users/risk-score/#use-risk-scores-in-access-policies). Mar 01, 2026 1. ### [Clipboard controls for browser-based RDP](https://edgetunnel-b2h.pages.dev/changelog/post/2026-03-01-rdp-clipboard-controls/) [ Access ](https://edgetunnel-b2h.pages.dev/cloudflare-one/access-controls/policies/) You can now configure clipboard controls for browser-based RDP with Cloudflare Access. Clipboard controls allow administrators to restrict whether users can copy or paste text between their local machine and the remote Windows server. ![Enable users to copy and paste content from their local machine to remote RDP sessions in the Cloudflare One dashboard](https://edgetunnel-b2h.pages.dev/_astro/rdp-clipboard-controls.B0ZmliDb_Z1Ne5yg.webp) This feature is useful for organizations that support bring-your-own-device (BYOD) policies or third-party contractors using unmanaged devices. By restricting clipboard access, you can prevent sensitive data from being transferred out of the remote session to a user's personal device. #### Configuration options Clipboard controls are configured per policy within your Access application. For each policy, you can independently allow or deny: * **Copy from local client to remote RDP session** — Users can copy/paste text from their local machine into the browser-based RDP session. * **Copy from remote RDP session to local client** — Users can copy/paste text from the browser-based RDP session to their local machine. By default, both directions are denied for new policies. For existing Access applications created before this feature was available, clipboard access remains enabled to preserve backwards compatibility. When a user attempts a restricted clipboard action, the clipboard content is replaced with an error message informing them that the action is not allowed. For more information, refer to [Clipboard controls for browser-based RDP](https://edgetunnel-b2h.pages.dev/cloudflare-one/networks/connectors/cloudflare-tunnel/use-cases/rdp/rdp-browser/#clipboard-controls). Feb 27, 2026 1. ### [Export MCP server portal logs with Logpush](https://edgetunnel-b2h.pages.dev/changelog/post/2026-02-27-mcp-portal-logpush/) [ Access ](https://edgetunnel-b2h.pages.dev/cloudflare-one/access-controls/policies/) Availability Only available on Enterprise plans. [MCP server portals](https://edgetunnel-b2h.pages.dev/cloudflare-one/access-controls/ai-controls/mcp-portals/) now supports [Logpush](https://edgetunnel-b2h.pages.dev/logs/logpush/) integration. You can automatically export MCP server portal activity logs to third-party storage destinations or security information and event management (SIEM) tools for analysis and auditing. #### Available log fields The MCP server portal logs dataset includes fields such as: * `Datetime` — Timestamp of the request * `PortalID` / `PortalAUD` — Portal identifiers * `ServerID` / `ServerURL` — Upstream MCP server details * `Method` — JSON-RPC method (for example, `tools/call`, `prompts/get`, `resources/read`) * `ToolCallName` / `PromptGetName` / `ResourceReadURI` — Method-specific identifiers * `UserID` / `UserEmail` — Authenticated user information * `Success` / `Error` — Request outcome * `ServerResponseDurationMs` — Response time from upstream server For the complete field reference, refer to [MCP portal logs](https://edgetunnel-b2h.pages.dev/logs/logpush/logpush-job/datasets/account/mcp%5Fportal%5Flogs/). #### Set up Logpush To configure Logpush for MCP server portal logs, refer to [Logpush integration](https://edgetunnel-b2h.pages.dev/cloudflare-one/insights/logs/logpush/). Note MCP server portals is currently in beta. Feb 17, 2026 1. ### [Streamlined clientless browser isolation for private applications](https://edgetunnel-b2h.pages.dev/changelog/post/2026-02-17-clientless-access-for-private-apps/) [ Access ](https://edgetunnel-b2h.pages.dev/cloudflare-one/access-controls/policies/) A new **Allow clientless access** setting makes it easier to connect users without a device client to internal applications, without using public DNS. ![Allow clientless access setting in the Cloudflare One dashboard](https://edgetunnel-b2h.pages.dev/_astro/allow-clientless-access.BHKwQuVt_1mLRiX.webp) Previously, to provide clientless access to a private hostname or IP without a [published application](https://edgetunnel-b2h.pages.dev/cloudflare-one/networks/routes/add-routes/#add-a-published-application-route), you had to create a separate [bookmark application](https://edgetunnel-b2h.pages.dev/cloudflare-one/access-controls/applications/bookmarks/) pointing to a prefixed [Clientless Web Isolation](https://edgetunnel-b2h.pages.dev/cloudflare-one/remote-browser-isolation/setup/clientless-browser-isolation/) URL (for example, `https://.cloudflareaccess.com/browser/https://10.0.0.1/`). This bookmark was visible to all users in the App Launcher, regardless of whether they had access to the underlying application. Now, you can manage clientless access directly within your [private self-hosted application](https://edgetunnel-b2h.pages.dev/cloudflare-one/access-controls/applications/non-http/self-hosted-private-app/). When **Allow clientless access** is turned on, users who pass your Access application policies will see a tile in their App Launcher pointing to the prefixed URL. Users must have [remote browser permissions](https://edgetunnel-b2h.pages.dev/cloudflare-one/remote-browser-isolation/setup/clientless-browser-isolation/) to open the link. ```json {"@context":"https://schema.org","@type":"BlogPosting","@id":"https://edgetunnel-b2h.pages.dev/changelog/product/access/#page","headline":"Access Changelog | Cloudflare Docs","url":"https://edgetunnel-b2h.pages.dev/changelog/product/access/","inLanguage":"en","image":"https://edgetunnel-b2h.pages.dev/cf-twitter-card.png","publisher":{"@type":"Organization","name":"Cloudflare","url":"https://www.cloudflare.com/"},"isPartOf":{"@type":"WebSite","@id":"https://edgetunnel-b2h.pages.dev/#website","name":"Cloudflare Docs","url":"https://edgetunnel-b2h.pages.dev/"}} ```