Cookie notice.

Authenticated pilot sessions use an HttpOnly defencefile_session cookie so internal users can access the workspace. It is scoped to the application path, uses SameSite=Lax, and is marked Secure in production-style deployments.

Zero-login attestation and adviser-share pages do not require an internal session cookie. Their rate-limit state is stored server-side as hashed public-token attempt records rather than browser cookies.

If a public visitor lands with UTM parameters, DefenceFile stores the first touch in an HttpOnly defencefile_first_touch_utm cookie for 30 days. It is first-party, SameSite=Lax, not overwritten by later visits, and used only to attach source context to a pilot request.

Product analytics event recording is server-side and cookieless: public page, CTA, and pilot-request events store hashed source identifiers plus bounded event properties, while authenticated app-moment events are tenant-scoped records in the analytics event store.

The only analytics-adjacent browser storage in the current product code is the first-party `defencefile_first_touch_utm` cookie created when UTM parameters are present; it supports pilot-request source context rather than cross-site tracking.

No advertising, retargeting, or third-party marketing cookies are required by the current product code. If that changes, DefenceFile should add a consent flow before setting non-essential cookies.

Public trust, security, privacy, DPA, terms, and guide pages remain usable without third-party tracking cookies.

DUAA changes are phased in and may alter some cookie rules, but this public notice keeps the current product posture narrow: essential session cookies, first-party attribution, and no non-essential tracking cookies.

Any future analytics, support-cookie, or non-essential-cookie posture change should update this notice, the privacy summary, the DPA/subprocessor schedule, and the signed customer terms before deployment.