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.
Root Herald doesn't replace your IdP or SSO. 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 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 EK public keys (from Intune / Jamf inventory exports). Now only IT-provisioned devices can satisfy attestation at all.
At sign-in, the device's dumb collector produces an opaque evidence blob (over a nonce your backend minted) and your backend appraises it server→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.
{
"acr": "urn:rootherald:device:high", // assurance level the device satisfied
"device": {
"ueid": "2f9c4a1c8b…", // stable per-tenant device id (no PII)
"verdict": "pass", // pass | warn | fail
"earStatus": "affirming", // affirming | warning | contraindicated
"attestationType": "tpm20",
"hardwareModel": "hardware-discrete-infineon",
"secureBootVerified": true,
"trustworthinessVector": { "hardware": 2, "configuration": 2 }
}
}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() -> relay nonce to the device's collector, which
// posts back the opaque evidence. Appraise it server→server:
const verdict = await rh.verify(evidence, {
challengeId,
policy: "rootherald:builtin:enterprise-managed-only",
});
// 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 attestations a month, no card.