Cisco Secure Client Always-On: Predeploy the Profile First

Appliance-side settings cannot make an unenrolled laptop behave like a managed endpoint, and most Always-On rollouts stall in that gap. Cisco Secure Client enforces the policy through the profile that sits on the machine, so delivery of that profile is part of the enforcement plan rather than a detail of it. Work through the five steps below in order, and stop at the first one that does not hold, because a later step cannot compensate for an earlier gap.

Step one: decide whether the rule starts before login

Always-On establishes the tunnel after the user logs on, and the vendor documentation says plainly that it does not establish a connection when nobody logs on. If your requirement is a tunnel that exists before the Windows logon screen, this is the wrong feature and no amount of profile tuning changes that. Predeploying the profile does not convert post-login behaviour into pre-login behaviour.

Write the requirement down as one of four distinct behaviours, then test each one separately. A single successful connection demonstrates only the ordinary case, and the other three are where support tickets come from. Mark which row your requirement actually needs, because a team that only needs post-logon behaviour can skip the pre-logon argument. The table is an acceptance list, not a wish list.

If the requirement is only the second row, the rest of this page still applies, but the acceptance test is cheaper.

Step two: confirm the profile is already on the endpoint

Enforcement reads a local profile, so the first question is whether that file exists before the user ever connects. A profile downloaded during the first successful connection is delivered too late for a machine that must be protected from its first logon. Ship it with the installer or with endpoint management, and treat the file's presence as a build check rather than a hope.

Get-Service vpnagent | Select-Object Status, StartType
Get-ChildItem 'C:\ProgramData\Cisco\Cisco Secure Client\VPN\Profile'
Get-Content 'C:\ProgramData\Cisco\Cisco Secure Client\VPN\Profile\profile.xml' | Select-String -Pattern AlwaysOn

Older AnyConnect installations keep the same file under a differently named folder, so confirm the path for the client version you deploy instead of copying a path from an old runbook. The service must be running and set to start automatically, because a stopped agent is an unenforced endpoint no matter what the profile says.

If the profile is missing, stop here. Fixing the failure policy or the trusted network list for a machine that has no profile is work on a path that never executes.

Step three: choose the failure behaviour deliberately

What happens when the tunnel cannot come up is a separate decision from whether the tunnel starts automatically. The connect failure policy decides whether the endpoint may use the internet while establishment keeps failing, and the two settings are frequently confused because both live near the Always-On options. Pick one on purpose and write down the reason.

Blocking all connectivity sounds strict and produces its own incident class: a user on a network where the gateway is unreachable cannot download the fix that would restore service. Allowing internet access keeps the machine usable and weakens the guarantee that traffic is protected. Either answer can be right, but neither is a default you should discover during an outage.

Retry behaviour belongs to the same decision. A client that retries forever hides a broken gateway from monitoring, while a client that gives up after one attempt looks broken to the user. Decide how long the endpoint should keep trying before the failure policy takes over, and test that timing rather than assuming it.

Step four: define what counts as trusted

Trusted network detection uses the criteria in the client profile, such as configured DNS domains or trusted DNS servers, to decide that the endpoint is already on a network where the tunnel is unnecessary. That list is the whole policy, so an empty or inherited list makes the feature either inert or unpredictable.

Do not substitute an assumption about the Windows firewall's network category. A machine can be on a domain-tagged network and still be somewhere you do not trust, and a machine on a public profile can be inside your own building. The detection criteria should describe your networks directly, not a proxy for them.

Test the transition in both directions, including the case where the endpoint moves from a trusted network to an untrusted one while a session is open. The disconnect and the reconnect are separate events, and a policy that only handles the first one leaves a window where the tunnel is absent.

Step five: make the endpoint policy hard to undo

Enforcement on the endpoint is only as strong as the endpoint's own controls. Local administrator rights let a user stop the agent service, replace the profile or uninstall the client, and a profile directory that ordinary users can write is a policy that anyone can edit. Both are endpoint-management problems that the VPN headend cannot solve for you. Ask the desktop team which of those two conditions applies before you promise enforcement, and write the answer into the rollout plan.

Decide the lockdown level with the recovery path in view. A profile that blocks the user from reaching the internet and also prevents them from repairing the client turns a support call into a site visit, so keep a documented recovery route that does not depend on the tunnel being up.

Keep the gateway certificate validation on, and distribute the profile only through a channel you trust. A locked-down client that accepts a profile from an unexpected source has moved the trust boundary rather than enforced it.