Continuous risk signals replace static access decisions

Security teams often find themselves in a reactive loop: credentials get phished, a malicious file slips through, and the next few hours are spent in incident response. Cloudflare One, the company’s SASE platform, aims to break that pattern by embedding continuous user risk assessment directly into zero trust access policies.

Previously, Access and Gateway policies could answer “who is this user?” and “is their device healthy?” at the moment of a request. With the introduction of User Risk Scores, those same policies can now also consider how a user has been behaving recently — and adjust access in real time when that behavior changes.

How the risk engine works

Identity is not static. A legitimate account can turn into a liability if it is compromised, or if the user begins exhibiting insider-threat patterns such as impossible travel, repeated failed logins, or data loss prevention (DLP) triggers from moving sensitive data. Cloudflare One now maintains a continuously updated risk score for every user in an organization.

Administrators define which behaviors matter to them in the Team & Resources > Users > Risk Score section of the dashboard. For instance, impossible travel could be assigned a “high” risk level, while a device pending an update might be flagged as “medium.”

The risk engine evaluates telemetry from across the SASE platform. Internal signals come from Cloudflare Access logs (successful and failed logins, geographic context) and Cloudflare Gateway logs (malware detections, risky browsing categories, sensitive data triggers). For external context, Cloudflare has built service-to-service integrations with partners including CrowdStrike and SentinelOne, ingesting telemetry such as CrowdStrike device posture attributes and mapping them to user profiles.

The scoring calculation follows a deterministic process:

  1. Selection: Admins choose which risk behaviors (impossible travel, DLP violations, etc.) to enable for their organization.
  2. Aggregation: The engine collects all risk events tied to a given user.
  3. Scoring: A user’s score reflects the highest risk level (low, medium, or high) among enabled behaviors triggered during the evaluation period.
  4. Reset: If an admin investigates and clears an incident, they can manually reset the user’s score — preserving history while restoring access decisions based on forward-looking data.

Putting risk scores into access policies

Knowing a user is risky is only useful if the system reacts automatically. Previously, responding to a suspicious user meant manually revoking sessions or moving them to a restricted group in the identity provider — a process slow enough for an attacker to exploit.

Cloudflare One now includes a User Risk Score selector in Access policy creation and editing. This enables rules such as: a high-risk user cannot reach the Finance Portal, or a medium-risk user must authenticate with a physical security key. These conditions can be applied globally or per application, allowing security controls to tighten without interrupting normal operations for users who haven’t triggered any risk behaviors.

Risk-based enforcement is also dynamic. When an investigator reviews and clears an incident, the user’s score drops and their access is restored automatically according to policy. Access can currently be revoked mid-session if the risk score rises; support for step-up MFA prompted mid-session on risk changes is planned for the future.

For organizations using Okta, Cloudflare can share risk signals back to the identity provider using the Shared Signals Framework. That way, a user flagged on the network is also restricted at the SSO front door, keeping security consistent across platforms.

Existing Cloudflare customers can begin exploring risk signals in the dashboard immediately. Free access for up to 50 users is available, and larger organizations can engage Cloudflare for guided ZTNA pilots incorporating third-party signals.