TriggerDevice powered on
AuthDevice certificate
BindingThis machine, approved
Posture25 of 25 checks pass
UserNot signed in yet
Always-on connectivity
Always protected. From the moment you boot.
The InstaSafe agent brings the secure tunnel up the moment the device boots, authenticating with the device certificate before anyone signs in. There is no connect button to press, so there is nothing to forget and no unprotected window between boot and login.
The tunnel is up before anyone types a password.
What is Always-On?
Always-on connectivity
Every connect-when-you-need-it tool shares one flaw: the human who forgets.
Always-On removes the human step. The InstaSafe agent establishes the secure tunnel the moment the device boots, authenticating silently with the device certificate and running its checks, binding, posture and geolocation, in the background. The user never sees a connect button, so there is nothing to forget and no unprotected window between boot and login.
- No protection gapPublic Wi-Fi work is inside the tunnel from second one. The minutes between powering on and signing in are covered like every other minute, instead of waiting on somebody to connect.
- No user dependenceSecurity posture stops varying with individual diligence. There is no connect button, so there is no habit to build, no training to run and nothing anyone can skip on a bad morning.
- Policy still rulesAlways-on is not always-allowed. The tunnel being up is connectivity, not permission: every application request still passes the Trust Engine before anything resolves.
- Fleet simplicityOne agent across Windows, Linux and macOS. Remote devices stay reachable for policy without extra hardware and without manually started sessions.
0connect buttons to press
0gap between boot and login
3operating systems covered
Five signals.
Read inside the tunnel.
These belong to the Trust Engine, not to the tunnel.
Always-On guarantees the connection is up from boot. What travels through it is decided separately: every application request is scored on these five, and when the picture stops adding up the request is refused while the tunnel stays exactly where it is. How the Trust Engine decides
endpointDevice healthDisk encryption, patch level, antivirus and firewall — re-checked continuously, not just at login.
geographyLocation & geo-velocityWhere the session is, and whether it just crossed a continent in the time it takes to refill a coffee.
patternBehaviourHow this person normally moves and works. A sudden break in that pattern raises the score.
networkNetwork & postureTrusted network or hostile one, and whether the machine still meets the policy it was let in under.
timeSession age & idleLong-lived and idle sessions are re-verified or quietly retired before they turn into someone's way in.
always-on is not always-allowed_
Take the laptop. Open anything you like.
The tunnel on this machine came up at boot and it is still up. That is not the same as allowed. The laptop is unlocked, signed in and in the wrong hands, so double-click the apps: the agent opens and tells you it is watching, the codebase and the database refuse, and in the browser only what the policy allows ever resolves. Every one of those answers comes from the Trust Engine, not from the tunnel.
Alen Josephalen.joseph@veno.co.in
Protected by InstaSafeWORKSTATION-07 · reported stolen 10:02
The tunnel is always up. That is not the same as always allowed.
Connect on demand vs always-on
Same laptop. Very different mornings.
Both of them get the person to work. What separates them is the minutes before anyone touches the keyboard, and who has to remember anything.
line by line _ two ways to bring a tunnel up_
- ▸Tunnel comes upAt boot, before loginWhen someone remembers
- ▸What the user doesNothing. No connect buttonOpens the client and connects
- ▸Boot to login windowAlready inside the tunnelUnprotected
- ▸Authenticated byDevice certificate, silentlyA person typing credentials
- Public Wi-Fi workCovered from second oneCovered once connected
- Posture across the fleetThe same on every deviceVaries with individual diligence
- ▸Being connected meansReachable, not allowedInside the network
- ▸Each application requestPasses the Trust EngineRides the tunnel unchecked
▸ marks the 6 rows where the architectures differ, not the wording
Always-on outcomes
It connects itself.It still askspermission.
The tunnel is up from boot with nobody deciding to bring it up, and everything that travels through it is still decided request by request.
No gap between boot and login
The tunnel is already up when the login screen appears, so the first minutes are covered like the rest.
Nothing left to the user
There is no connect button, so posture stops varying with who remembers and who does not.
Connected is not allowed
Every application request still passes the Trust Engine before anything on the far side resolves.
//Ready when you are//
Ditch the VPN. Keep your apps invisible.
Runs alongside the VPN you have, app by app, until there is nothing left to switch off. Nothing to rack, no network to re-architect.
Regulated, air-gapped, or on-premise? See deployment options