Use case · Workforce device trust

Proof of which laptop the engineer signed in from.

A valid SSO token from a stolen laptop is still a valid token. Root Herald supplies hardware-attested device proof your existing access path can check. So 'only managed devices reach production' becomes a verdict, not a fragile MDM integration.

The boundary

We are the device half, not your IdP.

Where Root Herald sits

Root Herald doesn't replace your IdP (your login system) or SSO (single sign-on). It answers one question: "is this a real, IT-provisioned, healthy device?" It returns that as a hardware-rooted verdict directly from a server→server rh.verify() call. You feed that into the access controls, conditional-access engine, or MDM (a device-management tool like Intune or Jamf) signals you already run.

The problem

Your login proves the user, not the device.

Most workforce SSO proves the user (WebAuthn / Push / TOTP), the IdP issues an id token, and the app authorizes. What's missing is the device. A valid token from a session-token-stealing extension on an unmanaged personal laptop looks identical to one from the engineer's corporate machine.

The defense today is wiring Intune / Jamf into your IdP's conditional-access engine and keeping it synced: fragile, expensive, MDM-vendor-specific, and only as strong as the MDM's ability to monitor the device at the moment of token issuance.

The shape

Pre-register the fleet. Gate on the verdict.

Set the project's acceptance policy to rootherald:builtin:enterprise-managed-onlyand pre-register your fleet's hardware keys (from your Intune / Jamf inventory export). Now only IT-provisioned devices can pass at all.

At sign-in, the device's collector produces a sealed hardware proof (answering a one-time challenge code your backend minted) and your backend verifies it server-to-server with rh.verify(). The verdict carries the device's attestationType, assurance level (acr), and earStatus. Feed it into your conditional-access engine and gate production behind "managed device + high assurance," the same way you gate behind MFA.

The device verdict your backend gets

Read it, then gate on it.

Keep your user authentication exactly as it is. This is the device half, sitting alongside it.

AttestationVerdictjson

{
  "acr": "urn:rootherald:device:high",   // how strong the proof is (assurance level)
  "device": {
    "ueid": "2f9c4a1c8b…",               // stable per-tenant device id (no PII)
    "verdict": "pass",                   // pass | warn | fail
    "earStatus": "affirming",            // overall device health: affirming | warning | contraindicated
    "attestationType": "tpm20",          // proven by a TPM 2.0 security chip
    "hardwareModel": "hardware-discrete-infineon",
    "secureBootVerified": true,
    "trustworthinessVector": { "hardware": 2, "configuration": 2 }  // per-category health scores (higher = better)
  }
}

server handler · @rootherald/nodets

import { RootHerald } from "@rootherald/node";

const rh = new RootHerald({ secretKey: process.env.RH_SECRET_KEY }); // rh_sk_…

// Your IdP already authenticated the user. Now layer the device requirement.
// Earlier: rh.issueChallenge() -> send the one-time challenge code to the device's
// collector, which posts back the sealed hardware proof. Verify it server-to-server:
const verdict = await rh.verify(evidence, {
  challengeId,
  policy: "rootherald:builtin:enterprise-managed-only",  // only your pre-registered IT-issued devices can pass
});

// Require a passing, high-assurance, affirming hardware verdict for prod.
if (verdict.device.verdict !== "pass" ||
    verdict.acr !== "urn:rootherald:device:high" ||
    verdict.device.earStatus !== "affirming") {
  return res.status(403).json({ error: "device_not_high_assurance" });
}

What this replaces

The fragile device-posture half.

Not your IdP. Keep Auth0, Okta, Entra ID, or whatever you run. What it replaces is the device-posture glue you maintain: the Intune / Jamf → Conditional Access integration you keep synced, the Beyond Identity bolt-on for the device signal, the separate MDM feed wired into your authorization layer, and the custom code stitching live posture into the login path.

It doesn't replace your MDM. Intune still does fleet inventory and patch management. It does mean your auth path stops needing the MDM on-line and freshly synced at every login: the hardware attestation is the proof.

Make 'only managed devices reach production' a verdict.

Free up to 10K device checks a month, no card.

Start free Shield quickstart →