Your MFA proved who logged in. It never checked who stayed.
Adversary-in-the-middle attacks relay your user's password and MFA, then steal the session cookie issued afterwards. The origin's logs show a clean login. Proksimity is a passive, server-side engine that reads whether the session in front of your origin is still the claimed user's browser, or a proxy in the middle, and gates step-up. No client script, ever.
MFA passed. The logs said it was her. It wasn’t.
A finance manager gets an email from a system she uses every week. The login page is flawless: the right address, a valid padlock. She types her password, approves the push, and gets back to work.
The page was a clone in front of an adversary-in-the-middle proxy. Her password passed through it. Her MFA approval passed through it. And the session cookie the real system issued afterwards (the pass that says “this is her, let her do anything”) passed through it too. Days later a batch of payments is gone. Every log record says it was her: the password matched, the phone matched. Nothing in the stack looked at what was carrying the login.
- Credential-only auth is blind after login
- Password and MFA both succeed on an AiTM relay. Session hijacking, token theft and shared accounts all look legitimate.
- Regulation stops at the door
- NIS2 and DORA mandate stronger login. None of them watch a legitimately-authenticated session being proxied.
- It is now turnkey
- Phishing-as-a-service kits made AiTM a commodity, not an APT-grade operation.
A naive relay cannot hide its knock. A careful one can.
To relay the credentials, the attacker’s proxy has to open its own connection to your origin. It re-terminates TLS, so the origin receives the proxy’s ClientHello, its HTTP/2 frames and its header order. A relay with a stock TLS stack cannot make those match the victim’s browser, and our bench separates it from a real browser on the first connection. A relay that copies the browser’s cipher and extension order can make the static knock match, and our bench could not separate it. What no relay can remove is the extra hop the victim’s traffic takes. Whether that hop is measurable is the open question, and it is the next pre-registered gate.
A quiet sensor at the edge that profiles the knock.
Picture a quiet guard dog in the yard, outside the house and outside your identity systems. It installs nothing on anyone’s device. It profiles each connection’s knock, and it only reacts when the knock is wrong.
Server-side. Traffic-only. No client-side fingerprinting JavaScript, no OS or hardware API, ever.
What it reads
- TLS ClientHello / JA4 · JA3
- HTTP/2 & HTTP/3 SETTINGS, PRIORITY, WINDOW_UPDATE
- Header order and casing
- WebSocket frame size and timing
- Session-level behaviour
What it never touches
- Request or response bodies
- Query strings and form values
- Any client-side script or device identifier
Neighbours that depend on client attestation cannot truthfully copy “server-side, traffic-only.”
From a raw connection to a calibrated decision.
- 01
Collect
A stateless, TLS-terminating edge emits typed events for each connection. Raw payloads are never captured.
- 02
Featureize
Bounded vectors (69 features, schema v10, d=138) with an explicit missingness mask. Missing is marked, never imputed. One vector per session.
- 03
Link
An anonymous identity graph with calibrated link thresholds. Nodes are opaque; it never names a person. A link gates step-up; it never grants auth on its own.
- 04
Decide
A calibrated, risk-tiered score that fails toward step-up, never toward silent acceptance.
Decision policy
Tiered. A session whose score clears the calibrated threshold proceeds. Anything below it raises a WebAuthn / OTP step-up, and sensitive actions can be gated separately. The thresholds come from calibration on your own traffic once the model is trained; we do not publish numbers a model has not produced.
Design budget: one mid-range CPU core, ≤ 64 MB, p95 ≤ 250 ms.
The collector is physically incapable of reading a payload.
Privacy here is architecture, not policy. The engine only ever sees protocol metadata: headers kept in grammar-only form, first-party path prefixes only, no bodies and no query strings. Retention is bounded: features for 24 hours, raw edge metadata for 15 minutes. Per NIST SP 800-63B, traffic fingerprinting is not an authenticator; it is a continuity signal that gates step-up.
- No request or response bodies ever read, transmitted or stored
- Grammar-only headers; first-party path prefixes only
- Features ≤ 24 h · raw edge metadata ≤ 15 min
- Designed to be enforced by CI static scan, runtime audit and quarterly third-party review
What we measured, including where it broke.
Every number below traces to a dated gate record on a controlled bench: direct browser sessions against relayed ones, pre-registered floor of TPR ≥ 0.63 at 1% FPR with a 95% cluster-bootstrap lower bound. Nothing here is a production or customer result.
Gate 0 · naive relay vs. direct browser · 2026-09-18
PASS- Grammar
- AUC 1.000 · TPR@1% 1.000
- Grammar, production-carriable fields only
- AUC 0.500
- Timing
- AUC 0.950 · TPR@1% 0.817
- TLS handshake timing alone
- AUC 0.951
A relay with a stock TLS stack. The whole grammar signal sits in cipher and extension order, fields a production edge does not keep; the timing signal is the handshake span.
Adversarial round · competent parrot (C2-v2) · 2026-09-22
FAIL- Grammar
- AUC 0.529 · TPR@1% 0.017
- Timing
- AUC 0.624 · TPR@1% 0.017
- Grammar fields matching the browser
- all measured
- First connection (k=1)
- grammar 0.000 · timing 0.100
A relay that copies the browser’s cipher order and extension order. Neither family clears the floor. The passive feature set does not separate this relay from the browser.
Cross-stack · Firefox and WebKit held out · 2026-09-22
DOES NOT GENERALIZE- Firefox held out
- AUC 0.46–0.50 · TPR@1% ≤ 0.01
- WebKit held out
- AUC 0.49–0.52 · TPR@1% ≤ 0.05
A model trained on one browser engine does not carry to another. Per-engine calibration is required, not optional.
Read together: the naive relay is caught on the first connection; the careful one is not, today; and nothing transfers across engines yet. The next gate tests whether the relay’s extra hop can be measured. Full records on request.
Built and running today
- Collection edge
- Feature pipeline & store
- Identity-graph store
- Decision service (fails toward step-up)
- Live connection inspector
Targets, not yet results
- Cross-device precision / recall ≥ 0.95 / 0.90
- Re-auth FPR / FNR ≤ 0.5% / 5.0%
- Calibration error ≤ 0.03
Why now
In April 2026 Chrome 146 shipped Device Bound Session Credentials (DBSC) on Windows; Chrome 147 followed on macOS as a gradual, flag-gated rollout. A bound session cannot be replayed from a stolen cookie, and where it applies it is the right fix. It applies only where the origin has built DBSC’s registration and refresh endpoints and the browser on the other end supports it. Safari, Firefox, Edge, Linux, mobile, the macOS users still in the control arm, and every application that has not implemented DBSC stay unbound, and that long tail is where session theft moves. Mozilla has declined the standard; WebKit has not accepted it. ENISA’s 2025 Threat Landscape names phishing as the leading way in, about 60% of observed intrusions. A 2025 FIDO Alliance white paper says phishing-resistant login does not cover the session issued afterwards and names DBSC and DPoP as the complements.
- Google Security Blog: Protecting cookies with Device Bound Session Credentials (9 Apr 2026)
- Scott Helme: Device Bound Session Credentials lands in Chrome on macOS
- Mozilla standards position on DBSC: negative (issue #912)
- ENISA Threat Landscape 2025 (1 Oct 2025)
- FIDO Alliance: DBSC/DPoP as complementary technologies to FIDO authentication (20 May 2025)
The questions a security lead asks first.
- “Passkeys already solve this.”
- They harden the login. They do not observe the session issued afterwards, and they do not cover every app a user touches. Proksimity is a post-auth runtime control that complements them.
- “Cloudflare already computes JA4.”
- Same signal class, different job. Anti-bot uses it to stop scrapers and credential stuffing. Proksimity uses it for per-user session integrity and step-up gating, and it deploys anywhere your traffic terminates.
- “Fingerprints can be spoofed.”
- Yes, and our own bench shows it. On 2026-09-22 a relay that copied the browser’s cipher and extension order was not separable from a real browser by our passive features (AUC 0.53). A relay with a stock TLS stack was (AUC 1.000, 2026-09-18). Whether the relay’s extra hop is measurable is the next pre-registered gate. Until then the decision fails toward step-up: a wrong guess costs the attacker a challenge, not you an account.
- “Does it add latency or block real users?”
- It is passive and out-of-band. The response is a step-up challenge, never a hard block, and it never rejects on an IP change alone.
- “Isn’t this a GDPR problem?”
- It is the opposite of client-side fingerprinting. Only protocol metadata, no device code, no bodies, and bounded retention.
Book a pilot.
We are taking on a small number of design-partner pilots. The collector runs self-hosted at your edge; your traffic never leaves your network and we never receive a capture. You hold the data and choose what to share. The pilot is what turns the targets above into measured results on your own stack.
What the pilot needs
- A first-party edge where your traffic terminates, on which you run the collector
- One authenticated flow to observe
- Two to four weeks to collect and calibrate
What you get
- The collector binary and its feature pipeline, self-hosted, no phone-home
- A per-browser view of your sessions’ wire artifacts, produced and kept on your side
- A decision hook for your existing WebAuthn / OTP step-up
No price and no plan yet. This is an evaluation, not a purchase. Direct, technical conversation only.