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.
Bulk print is available in Chromium-based browsers and Firefox. For more information, refer to Print PDFs for browser-based RDP.
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.
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.
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.
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.
This feature is in beta and available on all Zero Trust plans. For more information, refer to File transfer for browser-based RDP.
Access now correctly preserves URL fragment characters (
/,?,=,&,;) when redirecting users back to an application after login. Previously, these characters were encoded withencodeURIComponent, 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=advancedwould 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.
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.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.
For setup instructions, refer to Enforce MFA for infrastructure applications.
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-IdandCF-Access-Client-Secretheaders 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.
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.
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.
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 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.
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_toolcan becomesearch_customer_recordswith a description tailored to your organization.
Modified tools display a Modified label in the tools list so administrators can see which tools have been customized at a glance.
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 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.
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:
After:
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.
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
amrclaim defined in RFC 8176 ↗ and matches supported values such ashwk,otp, andfptto 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.
MCP server portals display a homepage when users visit the portal domain in a browser.
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.
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.
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.
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.
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.
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.
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.
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
codetool instead of listing every tool from every upstream MCP server. The connected AI agent writes JavaScript that calls typedcodemode.*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_executeto your portal URL when connecting from an MCP client:https://<subdomain>.<domain>/mcp?codemode=search_and_executeFor more information, refer to Code Mode.
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_contextquery parameter to the portal URL.Strips tool descriptions and input schemas from all upstream tools, leaving only their names. The portal exposes a special
querytool 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_toolsHides all upstream tools and exposes only two tools:
queryandexecute. Thequerytool searches and retrieves tool definitions. Theexecutetool 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_executeFor more information, refer to Optimize context.
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
302redirect to a login page they could not complete. The established workaround wascloudflared access curl, which required installing additional tooling.With managed OAuth, clients instead receive a
401response with aWWW-Authenticateheader that points to Access's OAuth discovery endpoints (RFC 8414 ↗ and RFC 9728 ↗). 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. It is opt-in for existing applications to avoid interfering with those that run their own OAuth servers and rely on their own
WWW-Authenticateheaders.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.enabledtotrueon the Access applications endpoint.
For setup instructions, refer to Enable managed OAuth.
MCP server portals can now route traffic through Cloudflare Gateway 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. You can create Gateway HTTP policies with DLP profiles to detect and block sensitive data sent to upstream MCP servers.
To enable Gateway routing, go to Access controls > AI controls, edit the portal, and turn on Route traffic through Cloudflare Gateway under Basic information.
For more details, refer to Route traffic through Gateway.
You can now use user risk scores in your Access 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.
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.
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.
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.
-
MCP server portals now supports 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.
The MCP server portal logs dataset includes fields such as:
Datetime— Timestamp of the requestPortalID/PortalAUD— Portal identifiersServerID/ServerURL— Upstream MCP server detailsMethod— JSON-RPC method (for example,tools/call,prompts/get,resources/read)ToolCallName/PromptGetName/ResourceReadURI— Method-specific identifiersUserID/UserEmail— Authenticated user informationSuccess/Error— Request outcomeServerResponseDurationMs— Response time from upstream server
For the complete field reference, refer to MCP portal logs.
To configure Logpush for MCP server portal logs, refer to Logpush integration.
A new Allow clientless access setting makes it easier to connect users without a device client to internal applications, without using public DNS.
Previously, to provide clientless access to a private hostname or IP without a published application, you had to create a separate bookmark application pointing to a prefixed Clientless Web Isolation URL (for example,
https://<your-teamname>.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. 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 to open the link.
You can now assign Access policies to bookmark applications. This lets you control which users see a bookmark in the App Launcher based on identity, device posture, and other policy rules.
Previously, bookmark applications were visible to all users in your organization. With policy support, you can now:
- Tailor the App Launcher to each user — Users only see the applications they have access to, reducing clutter and preventing accidental clicks on irrelevant resources.
- Restrict visibility of sensitive bookmarks — Limit who can view bookmarks to internal tools or partner resources based on group membership, identity provider, or device posture.
Bookmarks support all Access policy configurations except purpose justification, temporary authentication, and application isolation. If no policy is assigned, the bookmark remains visible to all users (maintaining backwards compatibility).
For more information, refer to Add bookmarks.