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.
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.
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.
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.
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.