What is an Access Rule?

An access rule is a policy object, configured at the system or tenant level in Versa Director, that matches traffic or access requests against criteria – such as username, role, device posture, or source location – and returns an allow or deny decision. Rules are evaluated top to bottom, so their order determines which match applies.

Key takeaways

• Access rules match traffic by user, group, role, device, or location.
• Rules are evaluated top to bottom; a Reorder control changes precedence.
• The core action is Allow or Deny, applied to the first matching rule.
• SASE deployments use both client-based and clientless access rule types.
• Concerto builds access rules as a step in its end-to-end SASE workflow.

On this page: Why it matters · How it works · Types · Access Rule & Versa · FAQ

Why are access rules important?

Access rules turn a broad security policy into per-user, per-device enforcement. Without them, an administrator has only blanket controls – a service is on or off for everyone behind a gateway. With them, access can depend on who is asking, what device they are asking from, and where, and each condition can be granted or revoked independently. That precision is the operational core of a Zero Trust posture: nothing is trusted by default just because a connection reached the network edge.

Rule order is just as important as rule content. Because access rules evaluate top to bottom and the first match wins, identical rules in a different sequence can produce opposite outcomes. A dedicated Reorder control – first, last, or a specific position – exists because sequencing correctly is as much a part of the design as writing the rules.

What is an access rule?

Structurally, an access rule pairs match criteria with an action. Match criteria commonly include the operating system, the users or user groups involved, endpoint posture – an Endpoint Information Profile, device compliance status, or entity risk band – and the source location or IP address. The action is Allow or Deny; an allowed request flows through further settings, such as which gateway group carries it, while a denied request is dropped outright.

Administrators build a rule through a step-by-step wizard covering each match-criteria and action category, then a Review & Configure step before saving. The saved rule joins an ordered list that Director or Concerto evaluates top to bottom, with Add, Clone, Reorder, and Delete operations available to manage the list afterward.

Types of access rules

Two rule families cover SASE secure access. Client-based access rules govern the installed Versa SASE client on end-user devices – Windows, macOS, iOS, Android, and Linux – matching by operating system, user or group, endpoint posture, and location, then directing allowed traffic to a Versa Cloud Gateway, straight to the internet, or blocking it. Clientless access rules apply the same allow/deny model to browser-based access, for users reaching protected applications without installing client software.

Within client-based rules, a further split exists at the traffic-action level: Breakout to Internet sends private traffic over the tunnel while internet-bound traffic exits locally (split tunnel), and Send Apps to Versa Cloud Gateway routes all traffic to the gateway with selected exclusions. Which options are available depends on the tenant’s subscription type.

Access Rule & Versa

Concerto builds access rules as a defined step in its SASE workflow, after users and groups, site-to-site tunnels, and secure client-based access profiles are already in place. Building one steps through match criteria (Operating System, Users/User Groups, Endpoint Posture using Endpoint Information Profiles, and Source Geo Location and IP Address), then actions (Traffic Action, Gateways, Client Configuration – including MFA and VPN type – and an Agent Profile from EIP), then Review & Configure.

The Concerto SASE end-to-end configuration guide walks through this full sequence, and configuring SASE secure client-based access rules documents each step in depth, including the Reorder mechanics that govern evaluation order.

Frequently asked questions

What is the difference between an access rule’s match criteria and its action?

Match criteria decide which traffic a rule applies to – operating system, user or group, endpoint posture, and source location or IP. The action decides what happens to matching traffic: Allow, with further routing choices, or Deny, which drops it outright.

Why does the order of access rules matter?

Access rules are evaluated top to bottom, and the first matching rule decides the outcome. Rules can be reordered – processed first, last, or at a specific position – so moving one changes which traffic it captures ahead of a broader, later rule.

What is the difference between client-based and clientless access rules?

Client-based access rules govern traffic from the installed Versa SASE client on a user’s device – matching by operating system, user, and endpoint posture. Clientless access rules apply the same allow-or-deny model to browser-based access, for users reaching protected applications without installing any client software.

Can an access rule match on device posture, not just user identity?

Yes. Endpoint posture match criteria let a rule reference an Endpoint Information Profile, a device compliance status, or an entity risk band, so access can depend on a device’s current security state in addition to who is requesting access and from where.

What happens to traffic when an access rule’s action is Deny?

The rule drops all traffic matching its criteria immediately, and later configuration steps such as gateway selection and client settings are skipped for that rule, since there is no allowed traffic left for them to act on. No further rules are evaluated for that request.

More on access rules

If you want to learn more, these are sources we trust.

Related terms

If you’re reading about access rules, these are worth looking at next.