You can guess what operating system a remote device is running just by watching its TCP/IP packets. No probes, no requests sent — just observation of the traffic the device generates. This is passive OS fingerprinting, and it’s been a quiet underpinning of network security and analytics tools for decades.

This post explains how passive OS fingerprinting actually works, what signals get used, how reliable it is in 2026, and where it fits in the broader landscape of bot detection and fraud detection.

The Basic Idea

Every operating system implements TCP/IP slightly differently. The differences are subtle:

Default window size on initial SYN.
TTL on outgoing packets.
Which TCP options are sent and in what order.
Whether TCP timestamps are enabled.
Maximum Segment Size (MSS) defaults.
Window scaling factor.

These are stable across OS versions and platforms. By observing the TCP SYN of a new connection, you can often guess “Linux 6.x” or “Windows 11” or “iOS 17” without any application-layer information.

The classic tool is p0f, originally written by Michał Zalewski. Modern alternatives include Satori, ja3/ja4 fingerprinting, and various commercial OS-detection products.

What Gets Fingerprinted

Common signals from a TCP SYN packet:

TTL (Time To Live)

The starting TTL is OS-specific:

Linux: 64
Windows: 128
Older Solaris: 255
macOS: 64

By the time the packet reaches you, the TTL has been decremented at each hop. But you can often reason: “seen TTL is 58; probably started at 64; probably Linux.” Or “seen TTL is 119; probably started at 128; probably Windows.”

Window size

The initial TCP receive window:

Linux: 29200 or 65535 (varies by version)
Windows: 8192 or 65535
macOS: 65535
iOS: specific patterns

TCP options order

Which options appear in the SYN and in what order:

Linux: MSS, sackOK, TS, NOP, WS (window scale)
Windows: MSS, NOP, WS, NOP, NOP, sackOK
macOS: specific pattern

The order is OS-specific because of the kernel’s TCP implementation. Two devices with the same OS produce the same option order.

MSS (Maximum Segment Size)

Different OSes set different defaults. Often 1460 for Ethernet; 1452 for PPPoE; 1380 for some mobile carriers.

How Tools Like p0f Work

p0f maintains a database of fingerprint signatures:

4:64:0:64:mss*44,N,W7,N,N,T,S,N,N::Linux:6.x  (just an example pattern)

The format: TCP version : initial TTL : DF flag : MSS : option order : … : OS : version.

The tool watches packets, extracts the relevant fields, and matches against the database. If a signature matches uniquely, you get an OS guess. If multiple OSes could produce that signature, you get an ambiguous answer.

p0f also fingerprints HTTP — User-Agent inconsistencies vs the TCP-level fingerprint can reveal spoofing.

Why It Works in 2026

The fundamental reason: OS vendors don’t deliberately try to make their TCP stacks look alike. Each maintains its own implementation; the implementations have specific defaults; those defaults are stable.

In 2026:

Linux distributions generally fingerprint as Linux. Sometimes you can distinguish 5.x from 6.x kernel versions, but not always the distribution.
Windows fingerprint as Windows. Distinguishing Windows 10 from 11 is sometimes possible.
macOS fingerprints as macOS. Hard to tell Sonoma from Sequoia.
iOS fingerprints differently from macOS, despite shared kernel — different defaults.
Android fingerprints as Android (Linux kernel + Android-specific defaults).

The accuracy at “OS family” level is high (90%+ in clean conditions). The accuracy at “specific version” level is lower.

TLS Fingerprinting: JA3 and JA4

A more modern technique uses the TLS handshake:

JA3

Hashes the TLS ClientHello — the SSL version, cipher suites, extensions, elliptic curves, point formats — into a fingerprint.

Different TLS libraries produce different JA3 hashes. A request from Chrome’s Boringssl looks different from a request from Python’s requests library.

JA4

A 2023 successor to JA3. More robust, harder to spoof, includes more handshake fields.

For bot detection, JA3/JA4 are powerful: a bot using Python’s requests library is instantly distinguishable from a real browser, even if it spoofs the User-Agent.

See TLS handshake for the underlying protocol.

Limits in 2026

A few reasons passive fingerprinting is less perfect than it used to be:

Browser homogenization

A Chrome browser on Windows or Mac or Linux all use Chrome’s networking stack — the TLS fingerprint is similar. The OS fingerprint differs (TCP layer), but TLS doesn’t necessarily.

Privacy-conscious OSes

iOS, macOS, and recent Android randomize MAC addresses on each network. Some are also experimenting with TCP fingerprint normalization to reduce trackability.

Containers and VMs

A Linux container on a Windows host fingerprints as Linux at the OS layer (because the container has its own Linux kernel for networking). This is correct but confusing.

CGNAT and proxies

When traffic comes through CGNAT or a proxy, the fingerprint may be of the proxy, not the original device.

Tor Browser

Specifically engineered to homogenize fingerprints. Hard to distinguish individual Tor users.

Use Cases

Bot detection

A request with User-Agent “Mozilla/5.0 Chrome…” but a TCP fingerprint matching Python’s requests is almost certainly a bot. Many commercial bot-detection products use TCP+TLS fingerprinting.

Network analytics

Understanding what OSes connect to your service. Useful for capacity planning, feature support decisions.

Security incident investigation

“All the suspicious traffic shows a specific JA3 hash — let’s block it.”

Compliance / policy

“Only allow managed corporate Mac OS devices.” Combined with VPN-based access, you can use fingerprinting as one signal.

How to Use This in Application Code

For most applications, OS fingerprinting is a layer of analysis you don’t implement yourself; you use a security product that does it. Cloudflare, Imperva, Akamai, Datadome all include fingerprinting in their bot management.

If you want to implement it:

Server-side

Capture TLS handshake bytes during the request. Compute JA3/JA4 hash. Compare against known bot fingerprints.

Libraries: tls-fingerprint-python, node-tls-fingerprint. Many are wrapping the same JA3/JA4 algorithm.

As part of a broader signal

Don’t make decisions on fingerprinting alone. Combine with:

Privacy Considerations

Passive fingerprinting is happening to every user even if they don’t consent. From a user’s view:

Disabling JavaScript doesn’t stop it (it’s at the network layer).
VPNs don’t fully prevent it (fingerprint is from the originating OS).
Tor Browser is the most effective defense (homogenizes the fingerprint).

For GDPR-compliant deployments, OS fingerprinting falls under “device data” which has implications. Disclose in your privacy policy if you use it for tracking.

TL;DR

Passive OS fingerprinting infers OS from TCP/IP packet quirks without sending probes.
Signals: TTL, window size, TCP options order, MSS.
Tools: p0f (classic), JA3/JA4 (TLS-based), commercial products.
Accuracy: high at OS-family level; lower at specific version.
Modern limits: browser homogenization, privacy-conscious OS changes, containers.
For bot detection, fingerprinting catches bots that spoof User-Agents.
As one signal among many — not a single decision factor.

OS fingerprinting is one of those subtle network analytics layers that powers most modern bot/fraud detection without being visible to users. Understanding it helps interpret why some traffic gets flagged that “looks” legitimate from an application view. For the broader detection picture, see bot detection strategies and IP-based fraud detection.

Passive OS Fingerprinting: Inferring the OS from Network Traffic