What Is Always-On Secure Access and Why It Matters for MSPs

The Risk Starts When the Gateway Disconnects

When a user disconnects from the gateway, your secure access policy doesn’t slow down. It stops. For MSPs managing multiple environments, this creates a gap in secure access that often goes unnoticed.

Why Users Disconnect and Create Security Gaps

Most endpoint security gaps don’t begin with an attack. They begin with something far more ordinary: a user closes the agent.

Maybe the reflex carried over from years of closing the VPN at the end of the day. Maybe they switched from the office to a coffee shop and the reconnect just never happened.

The reason almost never matters, because the result is always the same. The device is still on. The user is still working. But the gateway connection is gone.

And for an MSP, that moment is where the real problem begins.

What the Gateway Connection Controls in Security for MSPs

It’s easy to think of the gateway as just a tunnel, a secure path between the device and the network. But the gateway is more than a path. It’s where the secure access controls the MSP configures for a client actually run.

Think about what a typical client environment looks like. There are rules about which websites users can access. Policies about which applications can run and how. DNS settings that define where traffic goes and how it’s resolved. Firewall rules that determine what gets through and what doesn’t. Traffic inspection that makes threats visible before they land.

None of this lives on the device. It lives in the gateway. And when the device isn’t connected to the gateway, none of it is running. Which means the device is no longer operating under the MSP’s secure access policies.

The user doesn’t see this. From their perspective, nothing has changed — they’re online, they’re working, everything looks normal. Unless the configuration is set not to access company resources if they are not connected to gateway.

But from the MSP’s perspective, that device has stepped entirely outside the security architecture built for the client. It’s browsing freely, accessing resources without inspection, sending and receiving traffic that no policy is touching.

That’s not a gap in coverage. That’s the absence of it.

Why User-Dependent Security Does Not Scale for MSPs

The instinct is to address this through awareness — remind users to stay connected to secure access, explain why it matters, train them to treat the agent differently than they treated the VPN.

In practice, this doesn’t hold. Not because users are careless, but because security that depends on user behavior is security that will eventually fail. People switch networks, close laptops, restart devices, and work across environments in ways that don’t follow a policy manual. Expecting the gateway connection to survive all of that — on the strength of user habit alone — is an assumption that doesn’t scale.

For an MSP managing tens or hundreds of endpoints across multiple client environments, the math becomes even clearer. One disconnected device in one client environment, going unnoticed for hours, is a risk that no amount of user training fully eliminates.

The only reliable answer is removing the decision from the user entirely and enforcing secure access consistently at the gateway.

What Always-On Secure Access Changes for MSPs

Always-On secure access is exactly what the name suggests: the secure access gateway connection is established when the device boots and it stays active for the entire session. The user doesn’t initiate it. They don’t maintain it. And under the right configuration, they can’t break it.

The way this works in practice is straightforward. The agent is configured to launch automatically when the device starts. The moment it opens, it connects to the gateway. And with Always-On active, that connection holds — through network switches, through restarts, through whatever the user does during the day.

What this means for the MSP is that the controls configured for a client are no longer contingent on what a user remembers to do. A client whose environment includes strict web filtering and firewall policies has those controls running consistently — not just when users happen to be connected. The secure access architecture works because the foundation it depends on is always there.

Different Always-On Secure Access Models for MSPs

Enforcing always-on connectivity doesn’t mean enforcing it the same way for every client. Some environments call for absolute control. Others have legitimate reasons why a user might occasionally need to step outside the tunnel — a specific workflow, a particular network requirement, a client culture that requires more flexibility.

Timus gives MSPs three ways to approach this, all within the Always-On framework.

The strictest model leaves no room for disconnection at all. The agent stays connected, period. This works well for environments where the risk profile is high and the tolerance for policy exceptions is low.

Always on, no exceptions

The strictest option leaves no room for negotiation. Users are always connected, and there is no disconnect button to press. The connection runs continuously in the background, and the user has no way to interrupt it. For environments where uninterrupted connectivity is non-negotiable, this is the right choice.

Disconnect by permission

A more flexible option allows a user to request a disconnect, but they have to provide a reason first, and that request goes to the admin for approval. Until the admin responds, the connection stays active. If the request is approved, it’s a one-time exception. If it’s rejected, the user stays connected. Anything after that requires a new request. The MSP stays in control of every decision.

Flexibility with full visibility

The third option lets the user disconnect after providing a reason, without waiting for admin approval. What makes this more than just an open door is what happens next: the reason, the timestamp, the device, the user, all of it is logged in the Manager Portal. The MSP can see exactly when it happened, who made the decision, and why. And like the approval-based model, this is still a one-time disconnect. After reconnecting, a new submission is required.

What Always-On Secure Access Looks Like in Practice

Consider a client environment using always-on secure access where a finance team is working remotely across a mix of home offices and shared workspaces. The MSP has configured web filtering, application policies, and strict DNS controls for this client — the kind of setup that reflects a genuine security requirement, not just a checkbox.

Without Always-On secure access, the reliability of those controls depends on whether each device on that team happens to be connected to the gateway at any given moment. A user who closes the agent at lunch and forgets to reconnect spends the afternoon on an uncontrolled device. The MSP has no record of this, no alert, and no way to know what traffic passed during that window.

With Always-On Tunnel in place, that scenario doesn’t happen. The connection is there from boot. The controls are running. And if a disconnect does occur — because the MSP has configured a model that allows it under defined conditions — there’s a record of it.

That’s the operational difference. Not just tighter security, but a security posture the MSP can actually account for.