Why “Trusted Devices” Are the Biggest Lie in Security — and What Replaces Them

Every zero-trust product on the market maintains a trusted device list. Every single one. They check your device every 15 minutes, assign it a trust score, and cache that score until the next check.

Here’s the problem: a device that was “trusted” at 9:00:00 AM can be compromised at 9:00:01 AM. The trust score doesn’t update until 9:15. For fifteen minutes, your security infrastructure is confidently telling every system in your organization that a compromised device is safe.

That’s not zero trust. That’s cached trust. And cached trust is a lie.

The interval attack

Every device trust system has an interval — the gap between verification checks. CrowdStrike checks every 15 minutes. Zscaler checks periodically. Okta checks at session start. Microsoft Defender checks on a schedule.

An attacker who compromises a device has the full interval to operate freely. Session hijacking, credential harvesting, lateral movement, data exfiltration — all happening while the security infrastructure reports “device: trusted.”

The industry calls this zero trust. But there’s nothing zero about it. There’s a very specific, very exploitable amount of trust cached for a very specific, very exploitable amount of time.

What if there was no interval?

We asked a simple question: what if you never cached trust at all? What if every connection started at zero — actually zero — and had to prove itself continuously, from scratch, for the entire duration of the session?

Not every 15 minutes. Every 200 milliseconds.

That’s what H33-ZK Proven does.

How ZK Proven works

When a device connects to any service protected by ZK Proven, the following happens:

1. Score starts at zero. Not “inherited from last session.” Not “based on device history.” Zero. Every time.
2. The device generates cryptographic proofs. Six independent proof streams attest to different security properties of the connection — key freshness, behavioral consistency, timing coherence, network topology, hardware integrity, and protocol authenticity.
3. The score builds as proofs arrive. Each proof adds to the score. Within 500 milliseconds, a legitimate device reaches operational threshold.
4. Proofs continue throughout the session. Every 200 milliseconds at full tier. The score is recalculated continuously. A compromised device, a hijacked session, a man-in-the-middle proxy — all detected within one proof interval.
5. Session ends, everything is destroyed. Keys zeroized. Score discarded. No history. No device list. The next connection starts at zero again.

The six proof streams

Every proof is a zero-knowledge STARK proof — it verifies a security property without revealing any identifying information about the device, user, network, or session content.

Ephemeral key proof

A fresh CRYSTALS-Dilithium keypair is generated for every session. The proof attests the key is new. At session end, the key is cryptographically destroyed. A captured credential is worthless the moment the session closes.

Behavioral entropy proof

The device’s hardware has unique timing characteristics — clock jitter, thermal variance, memory access patterns. The proof attests these characteristics are consistent with a real, physical device. No MAC address. No IP. No serial number. No fingerprint. Just a proof that the hardware is real.

Temporal coherence proof

Monotonic timestamp attestations at randomized intervals catch replay attacks, clock manipulation, and session freezing. The proof reveals nothing about content — only that time is moving forward correctly.

Network topology proof

The connection’s hop count and latency profile are verified against expected patterns for the declared network type. A man-in-the-middle proxy adds extra hops and latency variance — both detectable without revealing the actual routing path.

Hardware attestation proof

The device proves it has a genuine TPM, Secure Enclave, or equivalent hardware security element with unmodified firmware — without disclosing the device’s serial number, certificate chain, or manufacturer identity.

Canary signal proof

Cryptographic honeypot fields embedded in the handshake that only a genuine implementation handles correctly. Protocol scrapers and replay tools trip them silently. No alert to the attacker — just immediate, irrecoverable score collapse.

You just connected to airport WiFi

Let’s make this concrete. You’re at the airport. You see “Airport_Free_WiFi” in your WiFi list. You connect.

It’s not the airport’s WiFi. It’s an attacker with a $200 device running an evil twin access point.

Without ZK Proven: The attacker sees your traffic. Your email session. Your bank cookies. Your Slack messages. Your iCloud token. Your VPN credentials. Everything flows through their device for as long as you’re connected. Your “trusted device” score? Still green. CrowdStrike won’t check for another 12 minutes.

With ZK Proven: Your device connects. Score starts at zero. Within the first 200ms proof cycle, ZK Proven detects:

• The network has an unexpected extra hop (the attacker’s device)
• Latency distribution is bimodal (proxy processing time layered on top of network latency)
• The canary signal response doesn’t match the current epoch seed

Score collapses to zero. Connection terminated. No data flowed. The attacker got nothing because ZK Proven killed the connection before your first HTTP request left the device.

The WiFi looked real. ZK Proven didn’t care how it looked. It proved what it was.

Watch this happen live in our demo →

Non-monotonic scoring: the anti-false-positive engine

A scoring system that terminates sessions on any anomaly would be unusable. Coffee shop WiFi has packet loss. Cellular connections have jitter. Tunnels cause brief disconnects.

ZK Proven handles this with three mechanisms:

• Velocity limiting. The score can’t drop more than 15 points in a single interval. A single bad packet doesn’t kill your session.
• Consecutive-interval termination. The score must stay below threshold for multiple consecutive intervals before termination. Transient anomalies are absorbed.
• Environmental floor. Network problems can reduce your score ceiling but cannot collapse your floor below the step-up authentication threshold. Bad WiFi triggers re-verification. Only genuine compromise indicators — canary failures, behavioral discontinuities, hardware tampering — can collapse the score to zero.

The result: legitimate users on flaky networks experience a brief step-up prompt at worst. Actual attackers experience immediate termination.

Capability tiers: honest scores

Not every device has a TPM. Not every browser has access to hardware timing APIs. ZK Proven is honest about what it can verify:

• Full (native app with hardware security): All six proof streams. Maximum score ceiling: 100.
• Partial (iOS with background restrictions): Hardware attestation via Secure Enclave, reduced behavioral entropy. Ceiling: 85.
• Browser (WebAssembly): Canary signals, temporal coherence, ephemeral keys. No TPM. Ceiling: 70.

A session scoring 68 out of 70 possible is more trustworthy than a session scoring 85 out of 100 possible with a hidden ceiling. ZK Proven reports both the score and the ceiling, so the receiving party can make an informed decision.

Federated threat intelligence with zero metadata

When ZK Proven terminates a malicious connection, it generates a zero-knowledge proof of the attack pattern and broadcasts it to a federated gossip network. Other ZK Proven instances can query: “does my current connection match any known attack pattern?” and get a yes/no answer.

The proof reveals nothing about the session that was attacked, the user who was targeted, the network that was compromised, or the device that detected it. Pure signal. Zero metadata.

Compare this to traditional threat intelligence feeds that share IP addresses, device fingerprints, and user agent strings — all of which are personally identifiable information and all of which create secondary databases that are themselves attack targets.

Post-quantum by default

Every ZK Proven session uses post-quantum cryptography:

• CRYSTALS-Dilithium for ephemeral session signatures (NIST FIPS 204)
• CRYSTALS-Kyber for session key ratcheting at every proof interval (NIST FIPS 203)
• ZK-STARK proofs based on SHA3-256 — quantum-resistant by construction

Compromise of any single proof interval gives an attacker zero material for any other interval. Mathematical forward and backward secrecy, per interval, per session.

144 patent claims and counting

ZK Proven is covered by H33’s patent portfolio — 134 claims across the original application and continuation-in-part, including 20 claims specifically covering the CCRA architecture: stateless scoring, velocity limiting, capability tiers, calibration windows, canary rotation, gossip protocol, cross-session nullifiers, and the three-tier adaptive proof scheduler.

Try it

ZK Proven is free to start. 1,000 operations. No credit card. The SDK is a single Rust crate — or hit the REST API directly. Your first connection will score itself from zero within 500 milliseconds.