JA3 builds a client fingerprint from a TLS ClientHello by hashing version, ciphers, extensions, and elliptic curve details. JA4 keeps the same basic idea but adds more context, such as ALPN, SNI, and transport protocol, which helps it stay more stable in modern environments. JA4 was designed to handle TLS 1.3 and QUIC more consistently than older fingerprinting formats.
How JA3 and JA4 differ as TLS client fingerprints
JA3 is the older and simpler fingerprinting approach. It extracts a small set of values from the TLS ClientHello and turns them into a hash that security tools can compare. That made it useful for spotting recurring client behaviour, but it also meant the fingerprint could change easily when clients, libraries, or network paths changed.
JA4 keeps the same core purpose, which is identifying a TLS-speaking client by observable handshake traits, but it broadens the input set and normalises some of the fields so the result is more resilient. The practical difference is not just “more fields”, it is better stability and better coverage across modern transport variants.
For analysts, that means JA3 is often best thought of as a lightweight legacy signal, while JA4 is better suited to environments where TLS 1.3, QUIC, proxies, and browser churn make older fingerprints noisier. Neither is a proof of identity on its own; both are heuristic identifiers that help group traffic, triage anomalies, and enrich detections.
Why JA4 is usually more useful in modern traffic analysis
JA4 was designed to reduce the brittleness that made JA3 drift over time. Modern clients often negotiate different cipher ordering, extension sets, or transport behaviour for reasons that have nothing to do with malicious activity. By adding context such as ALPN, SNI, and transport protocol, JA4 can distinguish meaningful client differences while avoiding some of the accidental fragmentation that weakens older hashes.
That extra context matters when the same software stack can appear different because of browser updates, library changes, or middleboxes. A detection built only on JA3 can over-split one client into many fingerprints, which makes baselining and allowlisting harder. JA4 is intended to give defenders a more durable grouping key for those same traffic patterns.
In practice, the better question is not whether JA4 replaces JA3 everywhere, but whether your telemetry pipeline needs a fingerprint that tolerates modern handshake variation. If the answer is yes, JA4 is usually the stronger default; if you are comparing against older tooling or historical datasets, JA3 may still be present as a compatibility reference.
What practitioners should watch when using TLS fingerprints
Both JA3 and JA4 should be treated as correlation features, not as stand-alone attribution. A fingerprint can cluster sessions from the same client family, but it can also be shared by benign software, embedded libraries, or attacker tooling that reuses common stacks. That is why the fingerprint only becomes useful when it is combined with destination, timing, process, certificate, DNS, and proxy context.
JA4 is especially helpful when your detections depend on stable client grouping across heterogeneous environments. It can improve hunting for repeated beaconing, unusual egress, and protocol tunnelling patterns, but only if you track false positives and normal variation carefully. If you do not baseline expected clients, a richer fingerprint can still produce noisy results.
Risk and Threat Considerations
TLS client fingerprints are valuable because they help defenders spot repeatable client behaviour, but they can also be fragile when the environment changes or when an adversary deliberately blends in with common tooling. Over-reliance on a single fingerprint can create blind spots, especially when modern clients shift transport behaviour, extension order, or protocol negotiation in ways that break older baselines.
Failure mechanism: A defender assumes a fingerprint uniquely identifies a client or threat family, but the same hash can be shared, mutated, or invalidated by software updates, proxying, or deliberate mimicry. That can lead to missed detections, noisy allowlists, or false confidence in a match.
Impact: Detection quality drops, triage slows, and analysts may either chase benign variation or miss real abuse hidden behind familiar-looking TLS behaviour. The practical consequence is weaker hunting coverage unless the fingerprint is paired with broader network and host evidence.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1071 — Application Layer Protocol | TLS fingerprinting helps detect application-layer protocol abuse and beaconing patterns. |
| T1572 — Protocol Tunneling | JA3 and JA4 are often used to spot protocol tunnelling hidden in TLS traffic. | |
| Recommendation — Map recurring TLS fingerprints to T1071-like traffic and hunt for suspicious application-layer beacons. Correlate TLS fingerprints with tunnelling indicators and investigate evasive transport behaviour. | ||
| CIS Controls v8 | CIS-13 — Network Monitoring and Defense | TLS fingerprints support network monitoring, detection, and triage of anomalous client behaviour. |
| Recommendation — Centralise TLS telemetry and tune detections around stable client fingerprint baselines. | ||
| NIST CSF 2.0 | DE.CM-01 — The network is monitored to detect potential cybersecurity events | JA3 and JA4 are monitoring signals used to detect abnormal network activity. |
| DE.AE-02 — Potentially adverse events are analyzed to help determine whether they are cybersecurity incidents | Fingerprint matches need analysis and context before they become incident evidence. | |
| Recommendation — Ingest JA4 telemetry into continuous network monitoring and alert on anomalous client shifts. Analyze fingerprint hits with destination and process context before escalating to incident handling. | ||
Practitioner Guidance
What to verify: Confirm that your tooling computes JA4 consistently across proxies, sensors, and inspection points, and check whether your environment normalises TLS 1.3 and QUIC traffic the same way everywhere. If those paths produce different outputs, treat the fingerprint as a segmented signal rather than a global one.
What good looks like: Use JA4 as a stable clustering key for client families, then validate it against timing, destination, and process context before making response decisions. For hunting workflows, the strongest use case is not “this hash equals that threat”, but “this fingerprint repeatedly appears with the same suspicious network pattern”.
Practitioner takeaway: Prefer JA4 when you need a more durable TLS client signal for modern networks, but keep JA3 for legacy comparison and never treat either fingerprint as sufficient evidence on its own.
Related resources from NHI Mgmt Group
- Guide: Beaconing and C2 Detection Guide
- Identification
- Why does JA3 fingerprinting create risk when defenders depend on it for client identification?
- When should organisations use self-signed TLS client authentication instead of CA-signed mTLS?
- What breaks when public TLS certificates stop supporting client authentication?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 31, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org