Block One Device From VPN Without Disabling the Whole Account

One employee, two laptops, and only one of them must lose access. Disabling the account is the obvious lever and it punishes the wrong scope, while deleting a saved profile on the endpoint is a suggestion rather than a control. The decision comes down to three conditions: whether a device identity exists that the VPN can verify, whether this particular connection actually evaluates it, and what you want to happen to the device instead of to the person. Answer them in that order and the enforcement usually picks itself.

First condition: is there device evidence the VPN can verify?

A source address is shared behind office NAT and changes on mobile networks. A hostname is whatever the device claims, a MAC address is trivially spoofed, and a registry value can be written by anything with local rights. None of those is an identity until something verifies it. A separately enrolled device credential, such as a certificate issued to that endpoint, is the one option that gives revocation a target narrower than the user account.

The credential only counts if the connection authenticates with it and validates the chain on every attempt. A file sitting in the machine's store proves nothing.

Second condition: does this connection evaluate it?

Endpoint attributes are not universal. On an ASA, Cisco's ASDM DAP guide separates user AAA information from endpoint assessment attributes, and which attributes are available depends on the remote-access protocol in use, the posture tooling deployed, and the license. A registry check needs the supported collection path, and even then it reports what the endpoint tool saw, not that the machine is the one you trust.

So the practical question is narrow: on this tunnel, with this client and this posture agent, which attribute arrives populated and trustworthy? If the answer is none, a policy written against it will match nothing or match everything, and both outcomes are worse than the account lock you were avoiding.

Third condition: rejection, remediation, or narrower access?

Three outcomes are available and they are not interchangeable. You can terminate the session, which removes access entirely; you can quarantine the device into a state where it can only reach remediation resources; or you can leave the session up and cut its resource ACL down to the few things that device still needs. DAP session actions and resource ACLs answer different questions, so the choice is about how much collateral damage the person should absorb.

For a lost or stolen laptop the answer is usually termination. For a machine that failed a posture check, remediation is kinder and just as effective.

Decide what happens when the evidence is missing

The default path matters more than the rule you wrote for the good case. If the expected attribute never arrives because the posture agent is broken, a policy that requires it may fall through to a default that admits the session. Read the default result and test the absent-evidence case deliberately, because that is the state an attacker who removes the agent will present.

Multiple DAP records that match are aggregated rather than resolved by simple first-match ordering, and their ACL priority is a separate mechanism from record selection. Read the guide's description of aggregation before assuming the stricter record wins.

Handle sessions that already exist, then test both devices

Changing an admission rule or revoking a credential does not describe what happens to a session that is already established and passing traffic. If immediate removal is the requirement, follow the implementation's supported session termination and re-evaluation procedure instead of waiting for the next reconnect. This is the step most often skipped during an incident, and it is the difference between a policy and an outcome.

Test with the same permitted user on both machines under an approved check. The blocked device should receive exactly the intended denial or remediation outcome, and the other should keep only its authorized resources. That verifies the device boundary without revoking the person's other approved access.

If you cannot make those two results differ, the problem is the evidence, not the policy, and no amount of rule tuning will fix it.