Skip to main content

Access policy

Every published app carries its own policy. You set it in the Policy part of the Publish resource drawer, and you can change it any time with Edit.

The checks run in this order, and any failure denies the request and writes a row in Recent access:

  1. Organization membership — the signed-in identity must belong to the org that owns the app.
  2. Allowed users or groups
  3. Require MFA
  4. Require managed device

Allowed users or groups​

A comma-separated list, e.g. alice@acme.com, Engineering, GDAP-Admins.

  • A value containing @ is matched against the user's email.
  • Anything else is matched against the groups that came from the user's login — Entra ID, Google or LDAP group names.
  • Leave it blank to allow any member of the organization. Blank is not "allow everyone on the internet" — the user still has to sign in and belong to your org — but it is wider than most teams want.

Deny reason in the audit trail: not_in_allowed_group.

tip

Entra ID can send group GUIDs instead of names in the SAML assertion. If a group match unexpectedly fails, check what the user's login actually delivered under Secure Access → Identity → Sources & Users (the groups: line on the user card) and paste that exact value.

Require MFA​

On by default. When enabled, a directory user who signs in is sent to a DashX MFA step-up before the app opens — they enter the code from their authenticator (or DashX Verify).

Two things worth knowing:

  • Admins are exempt. Someone signed into the DashX console already passed MFA there, so they are not challenged again.
  • A user with no MFA factor enrolled is denied with a message telling them to enrol. Enrol them first under Secure Access → MFA → Users & Factors, or let them self-enrol.

Require managed device​

Off by default. When enabled, the browser must present a DashX device certificate — one issued to a machine, not to a person — over mTLS.

The helper text in the drawer says it plainly: "Only devices enrolled with DashX Connect (holding a DashX device certificate) can open this app. The browser proves the device over mTLS — correct credentials from an unmanaged machine are denied."

This is the control that survives stolen credentials: the password and the MFA code are worthless from a laptop you do not manage.

How a device gets the certificate:

  1. DashX Connect is installed on the machine (the agent installs it automatically when the org has Private Access or RADIUS).
  2. The user signs in to Connect once. DashX issues a certificate bound to that device and Connect places it in the machine store (System keychain on macOS, LocalMachine\My on Windows).
  3. The browser presents it automatically on *.access.<region>.dashxtech.com.

Deny reason in the audit trail: device_not_managed — the user sees a page saying "This device is not managed by DashX".

note

Signing out of DashX Connect removes the certificate from the machine, which also removes access to apps that require a managed device. That is intended: sign-out means the device is no longer claimed by that user.

What is stored but not yet enforced​

The policy record also has fields for device posture and geo restrictions. They are saved but not evaluated yet — do not rely on them as a control. Use Allowed users or groups, Require MFA and Require managed device, which are enforced today.