A device on your network doesn't get to act just because a user logged in - here's what it actually has to prove
Your portal login and the monitoring agent running on an employee's laptop are two completely separate trust relationships. One doesn't inherit the other. Every single call the agent makes has to prove a device identity that was issued once, at enrollment, and can be pulled the moment that laptop shouldn't be trusted anymore.
It would be simpler to give every enrolled device a single shared API key and call it done. We didn't do that, on purpose: a shared key that leaks anywhere - a config file, a support ticket, a compromised machine - compromises every device in the fleet at once, silently, with no way to know which one leaked it. Instead, enrollment gives each device its own identity, and that identity is re-checked on every call it makes.
Enrollment issues an identity - not a copy of one
A 48-character random token, hashed with SHA-256 before it's stored - only the hash lives in our database, the same way we'd never store a plaintext password. It expires in 24 hours by default and can only be claimed once.
The agent presents the enrollment token exactly once. That claim registers the device record and immediately consumes the token - a second claim attempt with the same token fails.
The device gets a certificate thumbprint tied to its own key material, and a rotating bearer token. Neither is reusable on another device - the certificate is bound to that one device's identity at issuance.
Every agent call has to prove four things
Not just the token. Every request from an enrolled device carries a device ID, a certificate thumbprint, and a bearer token - and the server checks all of it, every time, not just at login:
- The device is actually enrolled. Unenrolled or unrecognized device IDs are rejected before anything else is checked.
- The organization isn't suspended. The same suspension check that invalidates a portal user's session on their next request applies to devices too - a suspended tenant's agents stop being able to report in, not just its people.
- The certificate is valid. Its thumbprint has to match a stored certificate for that exact device, unrevoked, unexpired.
- The token is valid. We store only its SHA-256 hash, never the plaintext - the same pattern as the enrollment token - and it has to be unrevoked and unexpired.
Any single one of those failing is a hard 401 (or 403, for a suspended org). There's no partial trust - a valid token with a stale certificate doesn't get through, and vice versa.
Tokens rotate; they don't just quietly expire
The bearer token is short-lived by default (an hour) rather than a long-lived credential you set once and forget. The agent calls a dedicated rotation endpoint to get a fresh one before its current token dies, so a token that does leak has a narrow, bounded window of usefulness rather than being valid indefinitely.
Replay protection and clock skew
Requests can optionally carry a nonce - a one-time value that can only be used once within a short window (five minutes by default). Reusing one gets a hard rejection, which is what stops a captured request from simply being replayed later to duplicate its effect.
The device also reports its own clock, and we don't take that at face value: the server computes the skew between what the device claims and its own clock, and carries that skew forward into how the event is processed, rather than trusting a device's self-reported timestamp outright.
Being direct about scope: the nonce header is optional on a given request - if a device doesn't send one, that specific call isn't checked for replay. It's a defense we apply where the agent provides the value to check, not a blanket guarantee on every single request regardless of what the client sends.
Revocation is one call, not a ticket queue
Pulling a device's access revokes its active tokens and its certificate in the same operation, and flips the device to unenrolled. The very next request from that device - even with a token that was valid seconds earlier - fails the certificate and token checks and gets rejected. There's no propagation delay to wait out and no separate step to remember.
Related reading
- Being logged in isn't enough to approve a DPIA or enable screenshots - the equivalent extra-proof pattern on the human side of the product.
- The exact four-part check Custelis runs before a file transfer gets logged, warned, or blocked
- How Custelis protects Aadhaar, PAN, and GST data specifically
See device enrollment for yourself
No credit card to start. Intrusive features stay off until your own DPIA is recorded.
Try for free