Device trust

The device counts, not only the password.

A successful login says who someone is. It says nothing about the laptop they are on, whether its disk is encrypted, or whether it was revoked yesterday. Trustwelt gives each device its own identity, reads its state, decides on the server, and helps it back to trusted when it falls short.

The model

Identity, device and context feed one decision.

  • IdentityWho is asking, verified with strong authentication in the Portal or your identity provider.
  • DeviceWhich enrolled device they are on, proved with its own key on every request.
  • ContextThe device's current posture, how fresh that evidence is, and what policy says about it.
Identity, device and context feed one decision.Three inputs, identity, device and context, go into a server-side policy decision, which produces one of three outcomes: allow, remediate or restrict.Identitystrong sign-in, verifiedDeviceits own certificate and keyContextposture, evidence age, requestPolicyon the serverAllowaccess continues✓Remediatethe person is shown the fix!Restrictuntil the evidence changes✕
The decision is taken on the server and taken again whenever the evidence changes.

Device identity

Every device proves who it is, on every request.

Enrolment gives each device a certificate and a key of its own. The agent signs every call it makes with that key, and Trustwelt verifies the certificate and the signature before anything reads the request.

  • Enrolment tokens are single-use, scoped to one organisation and valid for a short time.
  • Each request carries a signature over its method, path, body and time. A replayed or stale request is refused before anything reads it.
  • Device headers set by a browser or a proxy are ignored; only the device's own key counts.
  • A revoked device loses access at its next request, and its enrolment identity with it.
Every device request is signed, and checked before it is read.The device signs each request with its own key over the method, the path, a digest of the body, the time and a nonce, and sends it with its certificate. Trustwelt checks the certificate and the signature, refuses stale times and repeated nonces, and only then reads the request.Your enrolled computerits own certificateits own Ed25519 keyCanonical requestmethod ‖ path‖ SHA-256(body)‖ time ‖ nonce→ Ed25519 signatureTrustwelt checks✓certificate valid✓signature verifies✓time within window✓nonce never seen→ ACCEPTEDReplayed or alteredrefused, and recorded✕
A replayed, altered or stale request is refused before it is read. A stolen password alone never looks like your laptop.

Device posture

Know the state of the device, not just its name.

The agent reports structured signals on Windows, macOS and Linux: disk encryption, firewall and secure boot. Policy compares values instead of parsing text.

  • A signal the agent cannot read is recorded as unknown, never as compliant.
  • Evidence carries its age. Stale evidence counts less than fresh evidence, exactly as policy says.
  • Posture is about the device's security state. It is not employee monitoring: no keystrokes, no screens, no browsing history.
Typed posture signals for one device.An enrolled laptop reports disk encryption on, firewall off and secure boot unknown, with the age of the evidence. Unknown is never treated as compliant; policy asks for remediation.Laptop · enrolledcertificate issued at enrolmentsigns every report it sendsPosture report✓Disk encryptionon!Firewalloff?Secure bootunknown✓Evidence age4 minutesdecision: remediate
A signal the agent cannot read stays unknown. Unknown is never compliant.

Trust decisions and policy

A decision, not a one-time gate.

Policy names the outcome for a device in a group: allow, remediate or restrict. The decision is taken on the server, and taken again when the evidence changes, when posture drifts or when a device is revoked.

  • Device groups carry policy: which posture is required, and what happens when it is missing.
  • Policy travels to the agent as a signed envelope, verified against a key pinned in the agent. Production refuses to start without a pinned policy signer.
  • A decision never runs anything on the device by itself; acting on it is a separate, signed step.
  • People write policy. The platform explains a decision; it does not make one on its own.

Access enforcement

Enforced where the authority is.

Every decision is taken on the server. The browser and the device can present evidence, but they cannot declare themselves trusted.

  • Your organisation is a boundary: what its admins see and change is scoped to it on the server, never by a field the client sends.
  • A person's Portal session and an admin's console session are different things. One never works as the other.
  • Every admin action needs its own permission. An auditor cannot revoke a device; a support operator cannot change trust.

Secure remediation

Remediation that is not a remote shell.

When a device falls short, Trustwelt shows the person what to fix, and can send a registered action to that one device.

  • Actions come from a fixed, typed list. There is no free-form command.
  • Each action is signed and bound to its destination device. It cannot be redirected.
  • The agent refuses anything that is not on its allowlist, and that rule is covered by tests.
Remediation is a list, not a terminal.Access is requested, a posture gap is found, the person is shown the fix, the device is checked again and policy decides. The only thing the platform can send is a typed, signed action bound to that one device.01Access requested02Gap found03Fix shownto the person04Device checkedagain05DecisionRegistered actiontyped · signed · allowlisted · one deviceno remote shell, no free-form command
The only thing the platform can send is a typed, signed action, bound to one device.

Incident response

Contain first, keep the evidence.

Incidents are records in their own right, scoped to one organisation, with every change kept. Quarantine a device or end its sessions without touching its data.

  • Move an incident through its states with a note at each step; nothing is silently overwritten.
  • Audit records are separate from operational metrics, written append-only and chained.
  • No view lists incidents across organisations, and nobody at Trustwelt can change your audit.

Fleet lifecycle

Enrol, update and retire at scale.

Devices move through one lifecycle: enrolled, active, quarantined, retired. The agent keeps itself current through its own signed update path.

  • The agent updates through a lifecycle of its own, separate from interactive administration, and verifies each package's signature.
  • A minimum version is enforced: an agent cannot be downgraded below it.
  • Retiring a device revokes its identity. Organisations see only their own fleet.

The agent

What the agent does, and what it never does.

Runs on
Windows, macOS and Linux.
Reports
Typed posture signals, the state of its own enrolment, and, with the person's consent, the sites and usernames the browser has saved.
Receives
Signed policy and signed commands from its own allowlist, each bound to this device.
Never
Reads keystrokes, screens or browsing history. Never receives a password from the vault, and never opens a shell.
Talks to
The device control plane only, with its certificate and a signature on every request.

Posture signals today

  • Disk encryption
  • Firewall
  • Secure boot
  • Agent version
  • Enrolment state
  • Evidence age

Why it holds

Four rules that do not bend.

  • Unknown ≠ trusted

    Missing evidence never counts as compliant. A signal that cannot be read is unknown, and policy treats it that way.

  • MFA ≠ device trust

    A second factor proves the person, not the laptop. The device proves itself with its own key.

  • No remote shell

    Control actions are typed, signed and allowlisted. There is no channel for arbitrary commands, and there will not be one.

  • One tenant, one boundary

    Tenant scope comes from the server. Isolation is enforced in the APIs, the storage and the audit, and tested across all three.

See it on your own fleet.