Access Control
Every request verified. Nothing reachable by default.
Access Rules grant groups a resource, never a subnet. Trust Checks test the device before access and again as context changes. The same rules decide the agent path and the ZERA path, so there is no second policy to keep in sync.
Access Rules
Groups to resources, one rule at a time
- Sources are groupsRules name groups from your directory, not addresses. Move a person between groups and their reach follows.
- Destinations are resourcesA Protected Service, a device, a network or a Secure Session. Reach is granted per resource, never per subnet.
- Re-evaluated as context changesA failed Trust Check, a changed group or a disabled rule ends access the next time it is checked, not at the next sign-in.
- Explained in plain languageEvery rule dialog ends with a readout of what it does, and Access Diagnostics shows which rule decided any request.
Trust Checks
What a device must prove
Trust Checks attach to Access Rules. A device that fails one is denied the resources that rule grants, and the failing check is named in Access Diagnostics.
| Check | What it tests | Typical use |
|---|---|---|
| Operating system version | Minimum version per operating system | Keep unpatched devices off sensitive applications |
| Agent version | Minimum Inlinea Agent version | Retire old agents without blocking everyone at once |
| Country | Where the device connects from | Residency and travel policies |
| Network range | The address range the device connects from | Office-only or site-only access |
| Running process | A process that must be running | Require your endpoint protection or management client |
| Deep Trust Checks | Disk encryption, firewall, endpoint protection, management enrolment | Posture from the device itself and from Intune, CrowdStrike, SentinelOne and Jamf |
Agent Profiles
Govern the agent itself
One profile per device, resolved by group order and pushed with every login and network update, so an edit reaches connected devices at once.
- What people seeHide tabs and tray items a group should not touch, and keep the ones they need.
- Organisation-owned settingsSettings the organisation owns are refused on every interface: the app, the tray and the command line.
- Tamper protectionQuit, disconnect, sign out, stop and uninstall sit behind a support passcode, a device-bound support code or a temporary override.
- Reported backEach device reports the revision it applied, blocked actions, unlocks, wrong codes and lockouts.
Browser Security
The browser is part of the policy
- Attested browsersA resource marked extension required opens only for a browser holding a current, signed attestation, verified by the gateway on every request.
- In-page controlsClipboard, print, file transfer, screen capture, watermark and focus, with allow, warn or block on entry.
- EvidenceEvery blocked or observed control, warning and lifecycle event in the Browser Security Log.
Questions buyers ask
Do the same rules apply to the agent and to the browser?
Yes. One identity, one group model and one set of Access Rules decide both paths. There is no second policy engine for agentless access.
What happens when a Trust Check starts failing mid-session?
The device loses the resources that check protects the next time policy is evaluated. Access Diagnostics names the failing check so support can say exactly what to fix.
Can we limit access by country or by office network?
Yes. Country and network range are Trust Checks on the agent path, and Protected Services carry their own country and address allow and block lists on the ZERA path.
Can a device be admitted only with our endpoint protection running?
Yes. The running-process Trust Check requires a named process, and Endpoint Integrations bring posture from Intune, CrowdStrike, SentinelOne and Jamf into the same rules.