Identity-bound private access
A remote device is bound to a person at your own identity provider, granted named applications rather than networks, re-checked on a deadline, and judged on what your own management system says about the machine it runs on.
Walk through a single flow
- 1Enrolment can require a sign-in at your own OpenID Connect provider before a key exists, and refuse a token that carries no multi-factor claim.
- 2The device keeps that identity afterwards, so the hub can name the person behind a packet rather than an address.
- 3An access group maps the person's directory groups to named applications — an address and the ports the service answers on — and the hub writes one firewall rule per application, then blocks the rest.
- 4A re-authentication deadline moves the device into renewal, sends one reminder, and switches the device off at the hub when the deadline passes; signing in again switches it back on.
- 5Device posture is read from the management system you already run — Microsoft Intune or CrowdStrike Falcon — on an interval you set, and immediately when that system calls the console's event endpoint.
Technical notes
A device the management system has never seen, or has not seen recently, reads as unknown rather than non-compliant, and keeps its access unless the operator asks for the strict reading. The day a connector breaks must not be the day nobody can work. A device already switched off is different: it comes back only on a reading that says the machine is healthy, never on the absence of one.
There is no reverse proxy and no browser-only access: every person connects with a standard WireGuard client, and a grant is an application rather than a URL path. Nothing scores behaviour. No agent of ours is installed on the endpoint — posture is what your management system reports, not what we measure.