Test and enforce access policy

Creating rules does not change traffic while enforcement is Off. In that state the routed overlay remains an open mesh.

Before the change window, create explicit rules for:

• operator and recovery access;
• every required application flow;
• DNS and management paths that are actually subject to policy;
• AI agents and automation identities; and
• full-tunnel egress behavior where applicable.

Keep console/host access out of band so a policy mistake can be corrected.

Select Test access on Access Policies.

1. Choose the Agent or supported source shown by the deployment.
2. Enter Destination IP or hostname.
3. Choose Protocol.
4. Enter Port.
5. Select Run test.

The test explains current policy intent. It does not send traffic, resolve DNS, or prove the gateway applied the artifact. Run both an expected-allow and an expected-deny case.

1. Confirm an out-of-band host path is working.
2. Confirm at least one recovery/operator allow rule.
3. Select Enable enforcing.
4. Read the server-verified rule count and impact warning.
5. Select Enable enforcing in the confirmation only when the impact is expected.

Enforcing denies all traffic except matching allow rules. A zero-rule confirmation is deliberately destructive: it denies every governed flow.

Do not stop at the toggle. Verify all layers:

1. Control plane: the organization shows Enforcing.
2. Gateway: required gateways report the new policy revision without apply failure.
3. Allowed flow: connect to a representative allowed destination/port.
4. Denied flow: attempt one intentionally ungranted destination/port.
5. Evidence: confirm the allow/deny under Access Events.

nc -vz 10.20.4.5 5432   # expected allowed example
nc -vz 10.20.4.5 22     # expected denied example

Use addresses/ports from your own approved test plan. A timeout can also mean routing or application failure, so correlate it with the access event.

Open Settings → Access & security to enable Require device approval and the optional Just-in-time agent access feature.

Device approval affects future enrollments; existing active devices remain active. Review new devices under Devices → Approvals.

Posture is configured under Devices → Posture. Only managed macOS and Windows clients report it. Warn keeps access while surfacing noncompliance; Require removes access when a noncompliant managed report is applied. The facts are self-reported, not hardware attestation.

When enabled:

1. Open the just-in-time section in Access Policies.
2. Choose Agent and Destination.
3. Enter a specific Reason.
4. Choose duration: 15 minutes, 1 hour, 4 hours, or 24 hours.
5. Select Request access.
6. An approver selects Approve or Reject.
7. The requester can Cancel while pending; an approver can Revoke an active grant.
8. Review History and the audit log.

A pending request creates no rule. An approval creates an ordinary expiring grant. Disabling the feature is blocked while pending or approved requests remain.

If required traffic fails immediately after enforcement:

1. Preserve the failed allow/deny evidence.
2. Use the out-of-band console path.
3. Disable enforcement if the missing access cannot be corrected safely in place.
4. Confirm gateways applied the rollback.
5. Add/test the missing narrow rule.
6. Re-enable enforcement during a new watched change.

Do not broaden a resource to a whole subnet merely to make the incident stop. See Access events and audit for evidence handling.