The product
Root Herald checks that a request came from a real device.
Before a signup, a claim, a vote, or a free-tier grant, your app collects a small proof from the device and sends it to your server. Your server mints a challenge, then verifies the proof, and a plain answer comes back: did this come from a real, distinct, untampered machine? The proof is signed by the security chip (the TPM or Secure Enclave) built into virtually every modern laptop and phone. That's the whole product.
In the box
What you get on day one.
rh.verify()
The verify call returns the answer directly: a pass, warn, or fail; a stable, anonymous device ID; how strict a level the device met; and a confidence breakdown. Same contract in every language. No token to handle, no state to keep.
Libraries for every surface (rolling out)
Server libraries: @rootherald/node is available today; .NET, Go, Java, and Ruby are rolling out. The device-side piece that gathers the proof is rolling out too: native C/C++ in development, browser/React and iOS/Android coming soon. One contract behind all of them.
Developer portal
Usage, API keys, policy editor, event tail, billing. Every list shows the API call that does the same thing in code.
What's included
Everything out of the box. A couple of upgrades on paid tiers.
Full tier breakdown, overage rates, and what counts as a device check are on the pricing page. Out-of-band webhook event delivery is on the roadmap, not shipping yet.
Capability spotlight
Cohort prevalence — 'unusual for its kind', as an extra signal.
Your explicit checks stay the gate. Cohort prevalence adds one optional signal on top: how common a device's setup is among devices like it, counted by distinct real chips. It's a named signal plus a minimum you can set, never a rolled-up trust score.
It can only tighten
It runs after your explicit checks pass. It can add a reason to reject a device; it can never let one slip past a rule you set. It catches “unusual for its kind,” not tampering.
New setups are rare at first
A brand-new device setup is legitimately rare until lots of people adopt it, so the default is advisory, never a silent reject. Even checks that failed your rules but came from a genuine chip still count, so a new setup naturally becomes common as real devices adopt it.
Your fleet or the whole world
Hard-gate against your own managed devices (your known-good image) or read the global, advisory “how common is this” signal. Counted with methods that store no device identifiers.
Full claim shapes, policy fields, and cold-start behavior are in the cohort-prevalence reference.
How it ships
One product, many surfaces.
API gateway
A single HTTPS endpoint fronts our verifier microservices, policy engine, and trust-anchor store. You see one URL, one contract, one set of error codes.
Browser extension (coming soon)
A browser extension will bridge web flows to the device's security chip through a small local helper, so the page gathers the proof and your backend runs the check. No SDK in your front-end, no keys on the device. It's in development and not yet in the Chrome/Edge/Firefox stores; you can drive the full chain today on real hardware at /try.
A hardware fact under everything you build next.
Free up to 10,000 device checks a month, no card.