In a typical “device trust” setup, an identity provider checks a database to see whether the signing-in user has enrolled at least one managed device. If they have, the sign-in is allowed; if not, it’s blocked. That’s the policy in most enterprise identity products today, and it’s been good enough for a decade.
It’s also wrong.
The question most platforms answer wrong
A user who enrolled their laptop on Monday can sign in from a stranger’s desktop on Tuesday — and the device-trust check will pass, because the user has a trusted device somewhere. The actual device making the request was never inspected. The policy answered the wrong question.
How Trustaige binds a sign-in to a device
Trustaige asks the right question by binding a sign-in to a specific device through a small agent. When the device is enrolled, it generates a private key in tamper-resistant hardware and exchanges it for a certificate signed by your Trustaige tenant. From that point forward, every sign-in includes a cryptographic handshake — the agent presents the certificate, the server verifies it against your tenant’s trust anchor, and only then is the sign-in allowed to proceed.
What this changes in practice
A stolen credential cannot be used from an untrusted device. Even if an attacker phished the user, captured a session cookie, or somehow acquired the private key for the passkey, they would still need to be running the Trustaige agent with a certificate your tenant signed. They aren’t, and they can’t easily become.
The trust binds to a device, not a user. When a user gets a new laptop, the new laptop enrols and gets its own certificate. The old laptop is revoked. There’s no concept of “this user is trusted forever” — each device is trusted on its own terms, and only as long as it remains compliant.
Posture is reported in real time. The agent reports the device’s state — disk encryption, OS version, screen lock, presence on the domain — back to the platform. If posture drifts out of policy (encryption disabled, OS out of date), the certificate is revoked and access is removed without waiting for the next sign-in.
Why this is harder to ship — and why it matters
For organizations that take zero-trust seriously, this is the layer of the architecture that most identity platforms skip. It’s harder to ship, requires an agent, and depends on hardware-bound key generation. But for the kind of organization that has to assume a credential will eventually be stolen — every regulated enterprise, in other words — it’s the difference between an attacker who steals an account and an attacker who can’t use it.
The rest of the platform is built on the same principle: prove what matters, every time, rather than trusting an enrolment from months past. Federation, audit, lifecycle — each layer assumes the previous one might have been compromised, and verifies fresh.