Conditional Access Policies
Configure fine-grained access controls based on user context, location, and device
Conditional Access Policies allow administrators to enforce security requirements based on user context, such as IP address, geographic location, device trust, and authentication method. These policies help organizations meet compliance requirements and protect sensitive workforce data.
Overview
Conditional Access extends basic authentication by evaluating additional factors before granting access:
| Factor | Description |
|---|---|
| IP Address | Restrict access to specific IP ranges or block known threats |
| Geographic Location | Allow or block access from specific countries |
| Device Trust | Require registered or managed devices |
| Authentication Method | Enforce MFA, passkeys, or hardware security keys |
| Session Limits | Control concurrent sessions and timeouts |
Policies are evaluated in priority order, with higher priority policies taking precedence.
Role Templates
Role Templates provide a way to bundle permissions, app access, and conditional access policies into reusable configurations. When users join your organization via SSO or SCIM, they can be automatically assigned the appropriate role template based on their identity provider groups.
Understanding Role Templates
A role template includes:
- Employee Role: Admin, manager, or employee
- Team Permissions: What team management actions the user can perform
- App Access: Which applications (web, desktop, mobile) the user can access
- Access Policy: Which conditional access policy applies to users with this role
Creating a Role Template
- Go to Settings > Security > Role Templates
- Click New Template
- Configure the template:
- Name: Descriptive name (e.g., "Standard Employee", "Remote Contractor")
- Description: Explain when this template should be used
- Employee Role: Select admin, manager, or employee
- Set team permissions:
- Can create teams
- Can manage team members
- Can manage team settings
- Can approve team requests
- Set app access:
- Web application
- Desktop application
- Mobile application
- Optionally link an access policy
- Click Create Template
Global vs Organization Templates
- Global Templates: Available to all organizations, created by system administrators
- Organization Templates: Specific to one organization, created by org admins
Organization templates take precedence when names conflict.
IdP Group Mappings
Map identity provider groups to role templates for automatic provisioning:
- Go to Settings > Security > IdP Mappings
- Click Add Mapping
- Select the IdP type (SSO or SCIM)
- Enter the IdP group ID
- Select the role template to apply
- Set priority (higher = evaluated first)
- Click Save
When a user authenticates via SSO or is provisioned via SCIM, the system:
- Identifies their IdP groups
- Finds matching mappings (highest priority first)
- Applies the corresponding role template
Assignment Sources
Role templates track how they were assigned: manually, via SCIM, via SSO, or via invite code. This helps with auditing and troubleshooting.
Access Policies
Access policies define the security requirements for accessing your organization. Each policy can combine multiple conditions.
Creating an Access Policy
- Go to Settings > Security > Access Policies
- Click New Policy
- Configure the policy:
- Name: Descriptive name (e.g., "Office Only", "Strict Security")
- Description: Document the policy's purpose
- Priority: Higher numbers are evaluated first (default: 0)
- Enabled: Toggle policy on/off
- Configure restrictions (see sections below)
- Click Create Policy
Policy Priority
When multiple policies exist, they're evaluated in priority order (highest first). The first policy that denies access stops evaluation. If all policies pass, access is granted.
Example priority setup:
- Priority 100: "Block Sanctioned Countries" - Blocks specific countries
- Priority 50: "Office Network" - Requires office IP for sensitive roles
- Priority 0: "Default Policy" - Basic MFA requirement
Policy Actions
When a policy condition is violated, the system takes one of three actions:
| Action | Description |
|---|---|
| Blocked | Access denied, user cannot proceed |
| Challenged | User prompted for additional authentication (MFA, passkey) |
| Logged | Access allowed but logged for review |
IP Restrictions
Control access based on the user's IP address using CIDR notation.
IP Allowlist (Whitelist)
Restrict access to only specific IP ranges:
- In your access policy, find IP Restrictions
- Under Allowed IPs, click Add Range
- Enter the CIDR range (e.g.,
10.0.0.0/8or192.168.1.100/32) - Add multiple ranges as needed
- Save the policy
When an allowlist is configured, users MUST connect from one of the specified ranges. All other IPs are blocked.
Common CIDR examples:
| CIDR | Description |
|---|---|
192.168.1.100/32 | Single IP address |
192.168.1.0/24 | 256 addresses (192.168.1.0 - 192.168.1.255) |
10.0.0.0/8 | Class A network (10.x.x.x) |
0.0.0.0/0 | All IPv4 addresses |
IP Blocklist (Blacklist)
Block specific IP ranges:
- In your access policy, find IP Restrictions
- Under Blocked IPs, click Add Range
- Enter the CIDR range to block
- Add multiple ranges as needed
- Save the policy
Blocklists are evaluated before allowlists. If an IP is in both lists, it will be blocked.
VPN Considerations
If your organization uses VPNs, ensure VPN exit IPs are included in your allowlist. Remote workers connecting via VPN will use the VPN's IP address, not their home IP.
Device Requirements
Require users to access Z8 from trusted devices.
Trusted Device Sources
Devices can become trusted through several methods:
| Source | Description |
|---|---|
| Passkey | Device has a registered passkey for this user |
| Admin Registered | Administrator manually registered the device |
| Remember Device | User opted to remember device during login |
| MDM | Device is enrolled in Mobile Device Management |
Enabling Device Trust Requirements
- In your access policy, find Device Requirements
- Enable Require Trusted Device
- Save the policy
When enabled, users on untrusted devices will be prompted to register their device or use a passkey.
Registering Trusted Devices
Users can register devices by:
- Using a passkey (automatically trusts the device)
- Clicking "Remember this device" during login
- Having an administrator register the device
Administrators can register devices by:
- Go to Settings > Security > Trusted Devices
- Click Register Device
- Enter the user and device details
- Click Register
MDM Integration
For enterprise environments with Mobile Device Management:
- Configure your MDM provider (Intune, Jamf, Workspace ONE, etc.)
- Set up MDM integration in Settings > Integrations > MDM
- Devices enrolled in MDM are automatically trusted
- Compliance status is synced from MDM
MDM-enrolled devices include additional metadata:
- MDM provider name
- MDM device ID
- Compliance status
- Last compliance check timestamp
Device Fingerprinting
The system creates a unique fingerprint for each device based on:
- User agent string
- Platform (Windows, macOS, Linux, iOS, Android)
- Screen characteristics
- Browser/app version
This fingerprint is hashed and stored securely. One fingerprint can only be trusted once per user per organization.
Revoking Device Trust
To revoke a trusted device:
- Go to Settings > Security > Trusted Devices
- Find the device in the list
- Click Revoke
- Optionally enter a reason
- Confirm revocation
Revoked devices will need to re-establish trust through an approved method.
Location-Based Access Controls
Restrict access based on geographic location using ISO 3166-1 country codes.
Allowing Specific Countries
Restrict access to only certain countries:
- In your access policy, find Location Restrictions
- Under Allowed Countries, select countries from the dropdown
- Save the policy
When allowed countries are configured, users MUST be in one of those countries. Access from all other countries is blocked.
Blocking Specific Countries
Block access from certain countries:
- In your access policy, find Location Restrictions
- Under Blocked Countries, select countries to block
- Save the policy
Geolocation Accuracy
Location is determined by IP geolocation, which may not be 100% accurate. VPN users will appear to be in the VPN server's country.
Common Use Cases
Compliance Requirements:
- GDPR: Restrict processing to EU countries
- Data residency: Allow only countries where you operate
Security:
- Block high-risk countries
- Restrict contractors to their work location
Authentication Requirements
Enforce strong authentication methods.
MFA Requirements
Require multi-factor authentication:
- In your access policy, find Authentication Requirements
- Enable Require MFA
- Save the policy
Users without MFA enabled will be prompted to set it up.
Hardware MFA Requirements
Require hardware security keys or passkeys (stronger than TOTP):
- In your access policy, enable Require Hardware MFA
- Save the policy
This blocks TOTP-only authentication. Users must use:
- Passkey (device biometrics)
- Hardware security key (YubiKey, etc.)
Passkey Requirements
Require passkey authentication specifically:
- In your access policy, enable Require Passkey
- Save the policy
Users must authenticate using a registered passkey. Password + TOTP is not sufficient.
Session Constraints
Control session behavior and limits.
Session Duration
Limit how long sessions remain valid:
- In your access policy, find Session Settings
- Set Maximum Session Duration (in minutes)
- Save the policy
After this duration, users must re-authenticate regardless of activity.
Idle Timeout
Terminate sessions after inactivity:
- Set Idle Timeout (in minutes)
- Save the policy
Sessions with no activity for this duration are automatically terminated.
Concurrent Session Limits
Control how many simultaneous sessions a user can have:
- Toggle Allow Concurrent Sessions
- If enabled, set Maximum Concurrent Sessions (default: 5)
- Save the policy
When the limit is reached:
- New logins are blocked, OR
- Oldest sessions are terminated (configurable)
Session Tracking
Session activity is tracked separately from the main session. The system records last activity time, request count, and MFA verification status for policy enforcement.
Policy Evaluation
Understanding how policies are evaluated helps with troubleshooting and policy design.
Evaluation Order
- Get Active Policies: Fetch all enabled policies for the organization
- Sort by Priority: Order policies from highest to lowest priority
- Evaluate Each Policy: Check each condition in order:
- IP blocklist (blocked IPs)
- IP allowlist (if configured, IP must be in list)
- Blocked countries
- Allowed countries (if configured, country must be in list)
- Trusted device requirement
- Passkey requirement
- MFA requirement
- Hardware MFA requirement
- Concurrent session limit
- First Denial Wins: If any check fails, access is denied
- All Pass = Allowed: If all policies pass, access is granted
Access Context
The following information is collected for policy evaluation:
| Field | Description |
|---|---|
userId | The authenticated user |
sessionId | Current session identifier |
organizationId | Organization being accessed |
ipAddress | Client IP address |
country | ISO country code from geolocation |
region | Region/state from geolocation |
city | City from geolocation |
userAgent | Browser/app user agent |
deviceFingerprint | Hashed device identifier |
mfaVerified | Whether MFA was completed |
mfaMethod | Type of MFA used (TOTP, passkey, etc.) |
passkeyUsed | Whether a passkey was used |
Violation Types
When access is denied, the violation type indicates which check failed:
| Violation Type | Description |
|---|---|
ip_blocked | IP is in the blocklist |
ip_not_whitelisted | IP is not in the allowlist |
country_blocked | Country is in the blocked list |
country_not_allowed | Country is not in the allowed list |
untrusted_device | Device is not trusted |
mfa_required | MFA verification required but not completed |
passkey_required | Passkey authentication required |
session_expired | Session exceeded maximum duration |
session_idle_timeout | Session exceeded idle timeout |
concurrent_session_limit | Maximum concurrent sessions exceeded |
Violation Logging
All access violations are logged for compliance and security auditing.
What Gets Logged
Each violation log entry includes:
- Organization ID: Which organization was accessed
- User ID: The affected user (if authenticated)
- Session ID: The session that violated the policy
- Violation Type: Which check failed
- Policy ID: Which policy triggered the violation
- IP Address: Client IP
- Country: Geolocation country
- User Agent: Client software
- Request Path: URL being accessed
- Request Method: HTTP method
- Action Taken: Blocked, challenged, or logged
- Metadata: Additional context (device fingerprint, concurrent session count, etc.)
- Timestamp: When the violation occurred
Viewing Violation Logs
- Go to Settings > Security > Access Logs
- Filter by:
- Date range
- User
- Violation type
- Action taken
- Policy
- Click any entry for full details
Export for Compliance
Export violation logs for compliance reporting:
- Go to Settings > Security > Access Logs
- Set your filters
- Click Export
- Choose format (CSV or JSON)
Best Practices
Start Permissive, Tighten Gradually
- Start with logging-only policies to understand your traffic patterns
- Review logs for a week to identify legitimate access patterns
- Gradually add restrictions based on findings
- Monitor for false positives after each change
Use Policy Layering
Create policies at different priority levels:
- High Priority (100+): Critical blocks (sanctioned countries, known threats)
- Medium Priority (50-99): Role-based restrictions (contractors, remote workers)
- Low Priority (0-49): Default baseline requirements
Document Your Policies
For each policy, document:
- Why it exists
- Who it affects
- What happens when violated
- Who to contact for exceptions
Plan for Exceptions
Create a process for handling legitimate exceptions:
- User requests exception via support ticket
- Security team reviews the request
- If approved, create a time-limited exception policy
- Document the exception and review date
Regular Policy Reviews
Schedule quarterly reviews:
- Review violation logs for patterns
- Check if policies still match business needs
- Remove obsolete policies
- Update documentation
Troubleshooting
User blocked unexpectedly
- Check Settings > Security > Access Logs for the violation
- Note the violation type and policy ID
- Verify user's IP, location, and device status
- Check if they're using a VPN that changes their apparent location
- Review the triggering policy's configuration
Policy not taking effect
- Verify the policy is enabled
- Check the policy priority (might be overridden by higher priority policy)
- Ensure the policy is assigned to the right organization
- Check if there's a conflicting role template assignment
- User may need to log out and back in
Device trust issues
- Check if the device is registered in Trusted Devices
- Verify the device fingerprint matches
- Check if the trust has expired (for remember_device type)
- Ensure MDM integration is working (for MDM devices)
- Try re-registering the device
MFA challenges not appearing
- Verify MFA requirement is enabled in the policy
- Check if user already verified MFA in current session
- Review mfaVerifiedAt timestamp in session extension
- Ensure user has MFA methods configured
Concurrent session errors
- Check current session count in Settings > Security > Sessions
- Verify the maxConcurrentSessions setting
- User can terminate other sessions from their profile
- Admin can force-terminate sessions if needed
Geolocation incorrect
- IP geolocation is not 100% accurate
- VPN/proxy usage will show the exit server's location
- Corporate proxies may show headquarters location
- Consider using IP allowlists instead for office-based restrictions