Bot detection now reads the journey between clicks. Observe before you enforce.

The following customer journey is illustrative.

Two legitimate customers arrive at the same specialty retailer within minutes of each other. Both have accounts. Both want the same product. Both intend to complete a high-value purchase.

The first customer logs in with a mouse. The pointer curves toward the account icon, pauses over the navigation, and clicks into a category.

The customer scrolls, changes a filter, opens a product, and moves between form fields with the pointer.

The second customer uses a keyboard interface. Focus moves from the email field to the password field, then across the navigation.

The customer uses Tab, arrow keys, and an alternate keyboard to reach the same product and enter the same checkout details.

One journey leaves a trail of pointer movement. The other is dominated by keyboard activity and focus changes. Their paths converge on the same account action, but their rhythms do not.

The illustration stops before any security decision. Its purpose is to show what changed with Cloudflare Precursor, published July 13, 2026.

The protected moment is no longer only the login or checkout request. The security system can evaluate the journey that led there.

That gives the operator more context and a harder decision. The rollout has to pursue less abuse, less customer friction, and equal access to the account action.

The checkpoint has become a session

A conventional challenge evaluates a moment. A visitor reaches login, signup, checkout, or another protected path, and the site decides whether to verify that request.

Precursor adds activity between those moments. Cloudflare describes it as a client-side, session-based verification system. When enabled, Cloudflare dynamically injects JavaScript into HTML responses as they pass through its network.

The script listens for pointer movement, keyboard activity, focus changes, and page visibility. Cloudflare says keyboard activity is captured as timing and rhythm rather than the actual keys pressed.

Those events are serialized, buffered in memory, and sent at intervals for evaluation at Cloudflare's edge. Evaluators can cross-reference signals instead of reading each event alone.

Cloudflare gives two examples: whether pointer activity corresponds with how long a page was visible, and whether keyboard events occur while a text field has focus.

The distinction matters. A clean request at /checkout no longer has to carry the whole case for trust. Activity from login, navigation, product selection, and form entry can accumulate through the session.

According to Cloudflare, that session context feeds bot scores, challenge decisions, security rules, and session analytics.

The Precursor documentation says state is stored in the cf_clearance cookie.

Effective clearance may later be reduced or invalidated. A visitor can face another Challenge or re-verification during the same session.

Precursor supersedes JavaScript Detections, which used one-time execution rather than continuous session verification. Cloudflare advises customers to disable JavaScript Detections when they enable Precursor.

This is separate from the practical question of what happens when a browser agent reaches a challenge. We covered that fallback boundary in our browser automation article.

A different rhythm can still be legitimate

A longer observation window may improve detection. It also makes variation across legitimate journeys operationally important.

The W3C explanation of keyboard access describes why many people rely on a keyboard interface.

That includes blind users, people with low vision, and people with hand tremors who find a mouse difficult to use. It also includes alternate keyboards and keyboard emulators.

W3C names speech input, sip-and-puff software, on-screen keyboards, scanning software, and other assistive technologies as examples. These are legitimate ways to operate a website, and they do not all produce the same interaction pattern.

The W3C source establishes that legitimate input varies. It does not establish anything about Precursor's classifications, product quality, or WCAG conformance.

Still, the variance belongs in rollout design because Precursor observes pointer, keyboard, focus, and visibility signals across time.

The public response surfaced the same question quickly.

A Hacker News thread had 199 points when collected and substantial discussion about privacy, false positives, accessibility, and the anti-bot arms race.

One commenter asked, "how does this interact with keyboard navigation & accessibility tools?"

That is a question, not defect evidence. The cited Cloudflare launch post and Precursor documentation do not provide false-positive, accessibility, conversion, bypass-rate, or outcome data, and the Hacker News discussion does not supply independent outcome evidence.

Cloudflare claims that the added session context improves precision and reduces unnecessary interruptions. The claim is plausible enough to test and too consequential to accept without your own evidence at the endpoint you plan to enforce.

The operator sees effects, not the raw behavioral picture

Cloudflare says Precursor evaluates behavioral signals as aggregate patterns. It also says those signals are consumed internally and are not exposed in customer dashboards.

Cloudflare says they are not tied to user accounts, login identities, or persistent profiles.

Those are Cloudflare's statements about the product's privacy design. They are not independent proof of privacy outcomes.

The dashboard boundary has another consequence: an operator cannot inspect the aggregate signal and explain exactly which pointer curve, keyboard rhythm, or focus sequence influenced a session decision.

Security Analytics can show session-based views, bot score distributions, and WAF rule-match counts that include Precursor detections.

Product analytics can show whether a customer completed login, reached checkout, encountered a challenge, or left.

Neither view answers the rollout question alone. Security needs to know whether abusive activity falls. Product and operations need to know whether legitimate customers finish.

Accessibility testing needs to cover valid input journeys before enforcement changes the path.

This differs from deciding which machine visitors may access public content.

Machine visitor terms govern declared or classified automated access. Precursor infers from behavior inside a session.

The inference can influence a person standing at a login, checkout, or support portal. That is why observation has to come before a stricter rule.

Start where the system is least certain

Cloudflare offers two modes. Minimize Friction is the default. It attempts to establish session state in the background and does not show an interstitial Challenge.

Cloudflare says the default mode cannot guarantee that every session is fully verified.

Maximize Security shows a lightweight interstitial Challenge when no valid session exists. The docs say this ensures verification before the visitor proceeds and may add friction.

Rules can vary by path. A company could run Minimize Friction across the site and Maximize Security on /checkout.

That configuration is technically simple. The decision to use it should come after observing the path that real customers take.

Begin with the current funnel as the baseline. For each labeled test journey, record the share of eligible sessions that encounter a challenge, the share of challenged sessions that complete it, the share of eligible sessions that complete the account action, and confirmed fraud or abuse events per completed action within a fixed outcome window.

Then enable Precursor in Minimize Friction and watch the same path before moving its high-value endpoint to Maximize Security.

The accessibility comparison should use deliberate, legitimate test journeys: conventional pointer input, touch, keyboard-only navigation, and assistive technologies selected from user research, support evidence, or the accessibility test plan.

Label those sessions through the test plan or a consenting research cohort. Do not ask behavioral inference to guess who uses assistive technology or why a person's input differs.

Follow each journey through the whole sequence. Did login complete? Could the person navigate to the intended item or account area? Did focus reach every form control? Did a challenge appear? Did the person complete it or leave?

Run the same observation on the device and browser combinations that matter to the business.

A checkout team may care about mobile touch and desktop keyboard flows. A support portal may need employee-managed assistive technology in its test coverage.

Compare a controlled rollout, or equivalent windows if a control is unavailable, at the session level. If the confirmed abuse rate falls while account-action completion stays within a predeclared tolerance for every tested journey, stronger enforcement has evidence behind it.

If challenge exposure, challenge completion, or account-action completion moves outside that tolerance for any labeled input journey, keep observing and investigate before increasing friction.

If the data is sparse or ambiguous, that is also an answer. The evidence supports continued observation, not stronger enforcement.

Enforcement has to be earned at the endpoint

Precursor is rolling out now for Cloudflare Enterprise Bot Management customers and can be enabled from the dashboard. Cloudflare says it will be free until general availability later in 2026. It is not GA today.

Session inference can give defenders context that a single request misses. It also moves security judgment into the spaces between clicks, taps, keystrokes, focus changes, and page visits.

For the two customers in the opening journey, the business goal is the same: let a legitimate person complete the purchase while stopping abuse. Their routes through the interface are different evidence, not different entitlements.

Before increasing enforcement at login, signup, checkout, or support, examine the complete endpoint journey with pointer, touch, keyboard-only, and the assistive technologies identified in that test plan.

When the fixed-window comparison shows a lower confirmed abuse rate while challenge exposure and account-action completion stay within the predeclared tolerance for every tested journey, tighten the rule. When it shows only that Precursor can observe more, stay in observation.

BaristaLabs can help connect security events, product analytics, accessibility testing, and support signals around one high-value journey.

Start with the endpoint you are already considering for stronger enforcement, and make that one decision from evidence.