# JA4 TLS fingerprints and Private Access Tokens in Verify

> The edge now computes the JA4 fingerprint of each TLS connection; tls_mismatch checks each browser's TLS stack with it. Private Access Tokens are ready as a score-lowering signal, not enabled yet.

The edge now computes the [JA4](https://github.com/FoxIO-LLC/ja4) fingerprint of every TLS connection it terminates, from the ClientHello, and drops the raw bytes. Security events and AI agent events store it in `tls_fingerprint` (it used to be an internal 16-character hash), and the [trap](https://developers.openwaf.dev/ai-crawl-control/trap-and-tarpit/#marks) marks clients by it. It is empty when another proxy terminated TLS in front of the edge, or on plain HTTP.

The [risk signal](https://developers.openwaf.dev/waf/verify-risk/#signals) `tls_mismatch` now checks that a recent Chromium, Firefox or Safari comes from that browser's TLS stack, by stable traits rather than exact fingerprints: BoringSSL for Chromium, NSS for Firefox, Apple's network stack for Safari and every iOS browser. An automated Chromium whose User-Agent claims Safari or Firefox now fires it. See [TLS stacks](https://developers.openwaf.dev/waf/verify-risk/#tls).

A new signal, `pat_valid` (−20), lowers the score of a challenge when the device presents a valid [Private Access Token](https://developers.openwaf.dev/waf/verify-risk/#pat). It is not enabled yet: no token issuer is configured, because the issuers that Apple devices accept need an agreement with OpenWAF first. Until then nothing changes for visitors.