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.
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, 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.
Fine-grained permissions for Access policies and Access service tokens are available. These new resource-scoped roles expand the existing RBAC model, enabling administrators to grant permissions scoped to individual resources.
- Cloudflare Access policy admin: Can edit a specific Access policy in an account.
- Cloudflare Access service token admin: Can edit a specific Access service token in an account.
These roles complement the existing resource-scoped roles for Access applications, identity providers, and infrastructure targets.
For more information:
You can now require Cloudflare Access protection for all hostnames in your account. When enabled, traffic to any hostname that does not have a matching Access application is automatically blocked.
This deny-by-default approach prevents accidental exposure of internal resources to the public Internet. If a developer deploys a new application or creates a DNS record without configuring an Access application, the traffic is blocked rather than exposed.
- Blocked by default: Traffic to all hostnames in the account is blocked unless an Access application exists for that hostname.
- Explicit access required: To allow traffic, create an Access application with an Allow or Bypass policy.
- Hostname exemptions: You can exempt specific hostnames from this requirement.
To turn on this feature, refer to Require Access protection.
Three new API token permissions are available for Cloudflare Access, giving you finer-grained control when building automations and integrations:
- Access: Organizations Revoke — Grants the ability to revoke user sessions in a Zero Trust organization. Use this permission when you need a token that can terminate active sessions without broader write access to organization settings.
- Access: Population Read — Grants read access to the SCIM users and groups synced from an identity provider to Cloudflare Access. Use this permission for tokens that only need to read synced user and group data.
- Access: Population Write — Grants write access to the SCIM users and groups synced from an identity provider to Cloudflare Access. Use this permission for tokens that need to create or modify synced user and group data.
These permissions are scoped at the account level and can be combined with existing Access permissions.
For a full list of available permissions, refer to API token permissions.
Cloudflare admin activity logs now capture each time a DNS over HTTP (DoH) user is created.
These logs can be viewed from the Cloudflare One dashboard ↗, pulled via the Cloudflare API, and exported through Logpush.
SSH with Cloudflare Access for Infrastructure allows you to use short-lived SSH certificates to eliminate SSH key management and reduce security risks associated with lost or stolen keys.
Previously, users had to generate this certificate by using the Cloudflare API ↗ directly. With this update, you can now create and manage this certificate in the Cloudflare One dashboard ↗ from the Access controls > Service credentials page.
For more details, refer to Generate a Cloudflare SSH CA.
Cloudflare Access for private hostname applications can now secure traffic on all ports and protocols.
Previously, applying Zero Trust policies to private applications required the application to use HTTPS on port
443and support Server Name Indicator (SNI).This update removes that limitation. As long as the application is reachable via a Cloudflare off-ramp, you can now enforce your critical security controls — like single sign-on (SSO), MFA, device posture, and variable session lengths — to any private application. This allows you to extend Zero Trust security to services like SSH, RDP, internal databases, and other non-HTTPS applications.
For example, you can now create a self-hosted application in Access for
ssh.testapp.localrunning on port22. You can then build a policy that only allows engineers in your organization to connect after they pass an SSO/MFA check and are using a corporate device.This feature is generally available across all plans.
Fine-grained permissions for Access Applications, Identity Providers (IdPs), and Targets is now available in Public Beta. This expands our RBAC model beyond account & zone-scoped roles, enabling administrators to grant permissions scoped to individual resources.
- Access Applications ↗: Grant admin permissions to specific Access Applications.
- Identity Providers ↗: Grant admin permissions to individual Identity Providers.
- Targets ↗: Grant admin rights to specific Targets
For more info:
Browser-based RDP with Cloudflare Access is now generally available for all Cloudflare customers. It enables secure, remote Windows server access without VPNs or RDP clients.
Since we announced our open beta, we've made a few improvements:
- Support for targets with IPv6.
- Support for Magic WAN and WARP Connector as on-ramps.
- More robust error messaging on the login page to help you if you encounter an issue.
- Worldwide keyboard support. Whether your day-to-day is in Portuguese, Chinese, or something in between, your browser-based RDP experience will look and feel exactly like you are using a desktop RDP client.
- Cleaned up some other miscellaneous issues, including but not limited to enhanced support for Entra ID accounts and support for usernames with spaces, quotes, and special characters.
As a refresher, here are some benefits browser-based RDP provides:
- Control how users authenticate to internal RDP resources with single sign-on (SSO), multi-factor authentication (MFA), and granular access policies.
- Record who is accessing which servers and when to support regulatory compliance requirements and to gain greater visibility in the event of a security event.
- Eliminate the need to install and manage software on user devices. You will only need a web browser.
- Reduce your attack surface by keeping your RDP servers off the public Internet and protecting them from common threats like credential stuffing or brute-force attacks.
To get started, refer to Connect to RDP in a browser.
You can now control who within your organization has access to internal MCP servers, by putting internal MCP servers behind Cloudflare Access.
Self-hosted applications in Cloudflare Access now support OAuth for MCP server authentication. This allows Cloudflare to delegate access from any self-hosted application to an MCP server via OAuth. The OAuth access token authorizes the MCP server to make requests to your self-hosted applications on behalf of the authorized user, using that user's specific permissions and scopes.
For example, if you have an MCP server designed for internal use within your organization, you can configure Access policies to ensure that only authorized users can access it, regardless of which MCP client they use. Support for internal, self-hosted MCP servers also works with MCP server portals, allowing you to provide a single MCP endpoint for multiple MCP servers. For more on MCP server portals, read the blog post ↗ on the Cloudflare Blog.
An MCP server portal centralizes multiple Model Context Protocol (MCP) servers onto a single HTTP endpoint. Key benefits include:
- Streamlined access to multiple MCP servers: MCP server portals support both unauthenticated MCP servers as well as MCP servers secured using any third-party or custom OAuth provider. Users log in to the portal URL through Cloudflare Access and are prompted to authenticate separately to each server that requires OAuth.
- Customized tools per portal: Admins can tailor an MCP portal to a particular use case by choosing the specific tools and prompt templates that they want to make available to users through the portal. This allows users to access a curated set of tools and prompts — the less external context exposed to the AI model, the better the AI responses tend to be.
- Observability: Once the user's AI agent is connected to the portal, Cloudflare Access logs the individual requests made using the tools in the portal.
This is available in an open beta for all customers across all plans! For more information check out our blog ↗ for this release.
SSH with Cloudflare Access for Infrastructure now supports SFTP. It is compatible with SFTP clients, such as Cyberduck.
Cloudflare Access logs now support the Customer Metadata Boundary (CMB). If you have configured the CMB for your account, all Access logging will respect that configuration.