Contents

• Overview
• Planning rule sets
• Creating rules
  • Transaction types
  • Attributes
    • Rule operators (Is/Is Not complexity)
  • Rule outcomes
    • Device posture evaluation and security
• Viewing and restoring previous policy rules
• Appendix: Example Rules
  • Transaction-specific rules
    • Example 1: Creating an authentication transaction rule
    • Example 2: Creating a device transaction rule
  • All transaction-type rules
    • Example: Creating a rule to deny authentication

Overview

Beyond Identity's Policy engine is a powerful, rule-based decision engine that allows you to customize access decisions based on attributes from various sources, such as user, device, event, and third-party integrations.

The Policy engine ensures that users attempting a specific transaction, such as authenticating to web apps or adding a device, must meet the policy rule requirements defined to gain access. 

A single policy rule can consist of any number of transaction-based attributes. When a transaction is initiated, the policy engine evaluates each defined rule in numerical order. Once an exact match is found, access is allowed or denied based on the criteria defined in the rule. No further processing through the remaining rules is necessary. If a match is not found after searching through all rules, the default 'deny rule' is matched, and access is denied.

For example, a rule has been defined as allowing access when authenticating from a macOS device with a firewall turned on. The Policy engine searches through the rules starting with Rule 1, and when it finds a match, it stops searching and allows access. In this example, a match is found in Rule 3. The Policy engine does not need to continue searching through the remainder of the rules.

 

Planning rule sets

Review the following recommendations for defining rules:

• Consider setting up a break-glass rule for a specific group of admin users so they cannot lock themselves out from the system.

• Rules are evaluated sequentially until an allow/deny rule is matched. The processing of rules stops once a matching rule has been met. 

• The recommended order for rules is:

  1. Monitor - Place all Monitor rules first so you can gather information before the authentication is allowed/denied.
  2. Allow - Place an Allow rule before any related deny rules so authentications that should be allowed aren't denied accidentally. 
  3. Deny - Place Deny rules last since any rules after that will likely be ignored. 
• Until a rule allowing access is defined, access is denied. Any number of rules can be added. The last rule is a built-in default deny all rule. If none of the policy allow/deny rules are matched, the default will deny the transaction.

• Policy rules can be edited and deleted; however, the last remaining policy rule in a set cannot be deleted. It can only be edited.

• The default rule denying authentication and device add cannot be deleted.

• To define an explicit allow rule, for example, allow authentication transactions for macOS with disk encrypted and firewall enabled. Followed by a rule that explicitly checks for authentication for macOS with an unencrypted disk and denies it with the message "Disk encryption required for macOS authentication." A second, deny rule would then check explicitly for the firewall is off and denies the authentication with the message "Firewall must be enabled for macOS authentication."

 

Creating rules

1. Navigate to Policy in the Admin console. The Policy page displays a list of current rules that have been configured.
2. (Optional) Click on Manage attributes if you want to add a list of IPs that you want to block in the policy. For more information, see How to create IP address lists for policy rules.
3. Click Edit Policy.
4. Click Add Rule. The Add Rule dialog is displayed.
   
5. Select the order you want to process the rule. In general, the recommended order for rules is:
   1. Monitor - Use Monitor to test rules before rolling them out to production. 
   2. Deny - Place Deny rules before Allow rules to make certain that an authentication is not allowed prematurely since once a condition is met the policy engine will stop processing rules. 
   3. Allow - Place Allow rules after any related deny rules. 
6. Enter an optional name and description for the rule. 
7. Under Rule Definition, select the transaction type. For more information, see the Transaction types section below. 
8. Enter various attributes for evaluating a policy related to the following. For a description of available attributes, see the Attributes section in this article.
9. Select whether to Allow, Monitor, or Deny an authentication. For more information, see Rule Outcomes.

10. Click Publish changes on the Edit Policy page to begin applying the rule(s) when users authenticate. 
    Note:  For the rule to be preserved upon exiting the Admin console, the rule must be published. Multiple rules can be defined before publishing them.

    

Transaction types

The Policy engine supports creating rules for the following types of transactions:

• Authentication - Defines rules for authentications where Beyond Identity is the Identity Provider for a Single Sign On (SSO) provider or an application, typically configured via OIDC, SAML, or WS-Fed.

• • IP addresses - For information about creating IP address lists, see How to create IP address lists for policy rules.
    Examples:

    • Use this attribute to require a step up for all authentication transactions. Example 'If Transaction = Authentication then Allow w/ OS Verification'

    • Use this attribute to define requirements of users and devices that are permitted to authenticate, as opposed to users and devices that are permitted other transactions. Example: All Contractor users with Windows platforms that have their firewall and encryption enabled are permitted to authenticate.

  • Launch Mechanism - Checks whether the authentication uses a launch mechanism without origin information. These mechanisms have weaker phish resistance properties. 

    The following authentication flow types trigger detections:

    Loopback (All platforms)	Applies to authentication via the localhost. Set this transaction to Allow.
    Embedded (Web Authenticator)	Applies to authentication via a Web Browser. Set this transaction to Allow.
    App Scheme (All platforms)	Applies to the app identifier in a deep link. Set this transaction to Deny.
    Pipe/COM (Windows)	Applies to a temporary authentication connection between programs or commands. Set this transaction to Deny.
    Roaming (All platforms)	Applies to authentications made from a secondary device that is enrolled with Beyond Identity. This option requires that Roaming Authentication is enabled. See Configure roaming authentication for more information. Set this transaction to Allow if you've enabled roaming authentication.
    Copy/Paste (All platforms except Linux)	Applies to authentications where a link is manually copied/pasted to authenticate. Set this transaction to Deny.
    Universal Link (iOS only)	Applies to authentications where a magic link is clicked on to authenticate. Set this transaction to Deny.
    Autofill (Android only)	Applies to authentications where credentials are passed in using the autofill feature on Android. Set this transaction to Deny.
    Accessibility (Android only)	Applies to authentications where an alternative mechanism used to launch the platform authenticator app. Set this transaction to Deny.

      
• Add Device - Defines rules related to the users’ ability to add the passkey to additional devices.
• GPG Key Creation - Defines rules related to the users' ability to create keys to sign code commits. This transaction type should be used when the Secure DevOps entitlement has been enabled. 

 

Note: Rules can be set for a specific transaction type, or across transaction types to apply all transaction types with the same rule.

 

Attributes

The following table lists the device posture attributes and options available when writing policy rules.

Type	Platform	Name	Source	Description
User	N/A	Is in user group	SCIM Groups API	Checks whether a user is a member of a user group.
User	N/A	Has registered device(s)	Beyond Identity Cloud	Checks how many devices a user has registered. For example if a user in the Accounting group has more than 5 registered devices, it could indicate a risk.
Device	N/A	Platform	Beyond Identity Authenticator	Checks whether the  OS on a device is supported by your organization. Options are:  - Android - iOS - macOS, - Windows - Linux
Device	Android	Device Root Is	Queries files and packages that would indicate a root.	Checks whether a device has been rooted so you can deny authentication.
Device	Android	Device has authentication	Android KeyguardManager API	Checks whether device authentication is required. If not, you may want to deny authentication because the device can connect to unsecure internet connections.
Device	Android	Authentication method enabled	Android KeyguardManager API	Checks the type of authentication on the device such as - Biometric - PIN or Password
Device	Android	API level	The SDK version of the software currently running on the device.	Check the version of the framework API.
Device	Android	OS Version: SDK is still maintained	The SDK version of the software currently running on the device.	Checks whether the authenticating device OS is past end-of-life.
Device	ChromeOS with Android PA	N/A		Checks whether the user installs the Beyond Identity Android Authenticator from the Google Play store and registers a passkey.
Device	ChromeOS with Web Authenticator	N/A		Checks whether the user uses a Web Authenticator enabled by the admin and registers a passkey on a Chromebook.
Device	iOS	Device Jailbreak is	Checks for a jailbreak.txt file and whether the device can access cydia or the shell	Checks whether a device has been jailbroken so you can deny authentication.
Device	iOS	Device has authentication	Apple canEvaluatePolicy API	Checks whether device authentication is required. If not, you may want to deny authentication because the device can connect to unsecure internet connections.
Device	iOS	Authentication method enabled	Apple canEvaluatePolicy API	Checks the type of authentication on the device such as  - Biometric - PIN - PIN and Password
Device	iOS	Device type is	Apple DeviceCheck API	Checks the type of iOS device. For example, you may want to deny authentications by iPods to corporate applications.
Device	iOS	Version	Apple operatingSystemVersionString API	Checks the major and minor version of the device.
Device	iOS	OS Version: Major release is still maintained	Apple operatingSystemVersionString API	Checks whether the authenticating device OS is past end-of-life.
Device	macOS	Antivirus is	Queries XProtect plist file	Checks whether the authenticating device has antivirus disabled.
Device	macOS	Firewall is	Queries firewall plist file	Checks whether the authenticating device has a disabled firewall.
Device	macOS	Installed Security Software	Queries files for specific apps	Checks whether security software is installed on the device.  Options are: - CrowdStrike - Tenable - Jamf - McAfee - Kaspersky
Device	macOS	Apps installed	osquery	Checks whether an app you specify has a specific version installed. This is useful for locating unsupported versions of apps in your environment.
Device	macOS	File Exists	osquery	Checks whether a file you specify exists on the device.
Device	macOS	Plist Key Value contains	osquery	Checks whether the preference file contains a specific value for the: - Path - Key - Subkey -Number / String - Value
Device	macOS	Process Running contains	osquery	Checks whether the name of a process is running on the device.
Device	macOS	Process Running does not contain	osquery	Checks to make sure a process is not running on the  device.
Device	macOS	User FileVault Is	Queries FDE status	Checks whether the authenticating  device has FileVault disabled.
Device	macOS	OS Version: Build	Apple operatingSystemVersionString API	Checks whether the build version is within the last n updates of a major release.
Device	macOS	OS Version: Build Release Date	Apple operatingSystemVersionString API	Checks whether the build version's release date is/isn't within a specified timeframe.
Device	macOS	OS Version	Apple operatingSystemVersionString API	Checks the OS version on the device.
Device	macOS	OS Version: Minor release is still maintained	Apple operatingSystemVersionString API	Checks whether the authenticating device OS is past end-of-life.
Device	macOS	OS Version: Matched critical severity CVEs		Checks whether the number of critical severity CVEs have a specified score value. Recommended value:  > 30
Device	macOS	OS Version: Matched high severity CVEs		Checks whether the number of high severity CVEs have a specified score value. Recommended value:  > 200
Device	macOS	Secure Enclave is	Apple CryptoKit API	Checks whether the authenticating device does not have TEE (Trusted Execution Environment OR TPM/Secure Enclave).
Device	Windows	Antivirus is	Microsoft Windows Security Center API	Checks whether the authenticating device has antivirus disabled.
Device	Windows	Firewall is	Microsoft Windows Security Center API	Checks whether the authenticating device has a disabled firewall.
Device	Windows	Installed Security Software	Microsoft Windows Security Center API	Checks whether security software is installed on the device.  Options are: - CrowdStrike - Tenable - Jamf - McAfee - Kaspersky
Device	Windows	Domain Name contains		Checks whether the device is on an approved Windows domain.
Device	Windows	File Exists	osquery	Checks whether a file you specify exists on the device.
Device	Windows	Applications Installed	osquery	Checks whether an app you specify has a specific version installed. This is useful for locating unsupported versions of apps in your environment.
Device	Windows	Process Running contains /	osquery	Checks whether the name of a process is running on the device.
Device	Windows	Process Running does not contain	osquery	Checks to make sure a process is not running on the device.
Device	Windows	Registry Key	osquery	Checks whether the name of a registry key exists.
Device	Windows	Registry Key Value	osquery	Checks whether a specific value for a registry key exists.
Device	Windows	Service Installed	osquery	Checks if Windows services are installed.
Device	Windows	Service Running	osquery	Checks whether a specific Windows service is running.
Device	Windows	System Disks BitLocker is	Microsoft BitLocker API	Checks whether BitLocker has been enabled on the device.
Device	Windows	OS Version	Microsoft Environment API	Checks the OS version on the device.
Device	Windows	OS Version: Revision	Microsoft Environment API	Checks whether the build version is within the last n updates of a major release.
Device	Windows	OS Version: Revision Release Date	Microsoft Environment API	Checks whether the build version's release date is/isn't within a specified timeframe.
Device	Windows	OS Version: Build is still maintained	Microsoft Environment API	Checks whether the authenticating device OS is past end-of-life.
Device	Windows	OS Version: Matched critical severity CVEs	Microsoft Environment API	Checks whether the number of critical severity CVEs have a specified score value. Recommended value:  > 30
Device	Windows	OS Version: Matched high severity CVEs	Microsoft Environment API	Checks whether the number of high severity CVEs have a specified score value. Recommended value:  > 200
Device	Windows	TPM		Checks whether the authenticating device does not have TEE (Trusted Execution Environment OR TPM/Secure Enclave).
Device	Windows	TPM version		Checks the version of the TPM chip in the device.
Device	Linux	Installed Security Software		Checks whether security software is installed on the device. Options are: - CrowdStrike - Tenable - Jamf - McAfee - Kaspersky
Device	Linux	Process Running contains	osquery	Checks whether the name of a process is running on the device.
Device	Linux	Process Running does not contain	osquery	Checks to make sure a process is not running on the device.
Device	Linux	System Disks Encrypted is	Beyond Identity Authenticator	Checks whether the disk is encrypted.
Device	Linux	File Exists	osquery	Checks whether a file you specify exists on the device.
Device	Linux	OS Version	osquery	Checks the OS version on the device.
Device	Linux	TPM version	osquery	Checks whether the authenticating device does not have TEE (Trusted Execution Environment OR TPM/Secure Enclave).
Passkey	N/A	Passkey Tag Is	Beyond Identity Authenticator	Checks for the value of a specific passkey tag.
Integration	CrowdStrike Falcon	ZTA Score	Crowdstrike Host API	Checks the device's zero trust score. Click here for more details about CrowdStrike-specific policies.
Integration	CrowdStrike Falcon	Device Found	Crowdstrike Host API	Checks whether CrowdStrike is able to collect data on the device.
Integration	CrowdStrike Falcon	Connection is	Crowdstrike Host API	Checks whether the device is connected to CrowdStrike.
Integration	Cybereason	Sensor Found	Cybereason API	Checks whether the Cybereason Silent Sensor is available on the device.
Integration	Cybereason	Prevention Status	Cybereason API	Checks whether Cybereason prevention is enabled or not installed.
Integration	Google Workspace	Mobile Android Managed State is	Beyond Identity Cloud	Checks whether Android devices are managed by Google Workspace MDM.
Integration	Intune	Connection is	Microsoft Graph API	Checks whether the device is connected to Intune.
Integration	Intune	Registration	Microsoft Graph API	Checks the device's registration status for Intune.
Integration	JAMF	Connection is	Jamf Pro API	Checks whether the device is connected to JAMF.
Integration	JAMF	Computer Managed State is	Jamf Pro API	Checks whether the device is managed by JAMF.
Integration	JAMF	Mobile Device Managed State is	Jamf Pro API	Checks whether the mobile device is managed by JAMF.
Integration	Kandji	API is	Kandji API	Checks whether the Kandji API is available on the device.
Integration	Kandji	Device is managed	Kandji API	Checks whether the device is managed by Kandji.
Integration	SentinelOne	Agent is active	SentinelOne API	Checks whether the SentinelOne agent
Integration	SentinelOne	Agent is decomissioned	SentinelOne API	Checks whether the agent is decomissioned while the device is under maintenance, the user is on vacation, etc.
Integration	SentinelOne	Agent operational state	SentinelOne API	Checks the status of the SentinelOne agent on the device.
Integration	SentinelOne	Connection is	SentinelOne API	Checks whether the device is connected to SentinelOne.
Integration	SentinelOne	Device Found	SentinelOne API	Checks whether SentinelOne can collect data on the device.
Integration	Workspace ONE	Connection is	VMWare AirWatch API	Checks whether the device is connected to Workspace ONE.
Integration	Workspace ONE	UEM	VMWare AirWatch API	Checks whether the device is enrolled in Unified Endpoint Management (UEM).
Authenticator Details	N/A	Authenticator version	Beyond Identity Authenticator	Checks the version of the Beyond Identity Authenticator installed on the device.
Authenticator Details	N/A	Authenticator IP is new to the user (in last year)	Beyond Identity Authenticator	Checks whether the IP address has been changed in the last year.
Authenticator Details	N/A	Authenticator location is new to the user (in last year)	Beyond Identity Authenticator	Checks whether the location has been changed in the last year.
Location	N/A	If Location is	IP Address of the authenticating device	Checks whether the device is in a specific region (useful for denying countries where cyberattacks frequently originate).
Behavior	N/A	Impossible travel detected	Beyond Identity Authenticator	Checks whether consecutive authentication locations from the same user imply a travel speed > 500 mph.
Behavior	N/A	Number of user authentications in last minute	Beyond Identity Authenticator	Checks for a high number of authentications in the last minute.
Behavior	N/A	Days since last user authentication	Beyond Identity Authenticator	Checks whether a user hasn't logged in over a long period of time, such as 30 days.

 

Rule operators (Is/Is Not complexity)

The policy rules have many different options for the operators, depending on which item is configured. Many of them are easy to follow, but the explicit IS and IS NOT operators can be slightly misleading in some cases.

For example, using Kandji MDM integration and making a policy rule that is intended to catch all the "happy days scenarios" to allow authentication, could look something like this:

• The device must be a Mac
• The firewall must be enabled
• Disk encryption must be enabled
• Kandji API must be available (meaning that Beyond Identity can make the API call to Kandji's services)
• The device must be managed by Kandi

If the intention is to have a check for the computer being managed and deny a user's authentication when they are using a non-managed computer, you could configure a rule where the check is:

• Kandji API must be available (meaning that Beyond Identity can make the API call to Kandji's services)
• The device must be not managed by Kandi

If Kandji reports that the computer is not found, it cannot tell if it is managed or not.

Instead of changing the true/false option, changing the check from "is" to "is not" will explicitly check that the computer isn't managed.

Note: All of these combinations are different, and when looking from a programmatic perspective:

• Something == true (something is explicitly true)
• Something == false (something is explicitly false)
• Something != true (something is explicitly not true)
• Something != false (something is explicitly not false)

Using monitor rules to define a policy rule that works as intended is the best method to identify the desired behavior before implementing them for all users.

Rule outcomes

The policy engine has the following types of outcomes.

Rule	Requirements / Actions	Description
Allow	N/A	Allows the authentication to complete if the rule criteria are met. Optionally, you'll be able to define a toast message that shows when the authentication is successful.
Allow	If user verified with *Feature flag must be enabled	If someone gains control of a device and knows the pin/passcode for it, they could register another biometric and gain access to applications. Selecting "Registered Biometric" as an option provides an additional layer of security to protect devices.  For more information about this feature, see Biometric Enrollment Detection.  Registered Biometric (Recommended) - Allows authentication if the rule criteria are met AND the user verifies their identity using a biometric registered with Beyond Identity as an authentication method. (Most secure)  Any Biometric - Allows the authentication if the rule criteria are met AND the user verifies their identity using a biometric.  Note: This doesn't require registration of the biometric with Beyond Identity. Any Factor - Allows authentication if the rule criteria are met AND the user verifies their identity using a biometric, PIN, or operating system password.  The user will receive a denied notification when they attempt to authenticate if their biometric is not registered with Beyond Identity.
Allow	With SAML Assertion	Allows the authentication to complete and generates a SAML assertion with static values you provide to a 3rd party. Tip: If you want to send a SAML assertion with supported dynamic values, you can configure it for a SAML integration (Integrations > SAML tab). Note: SAML assertions are not generated on deny rules, which is in line with industry standards.
Monitor	N/A	This option doesn't stop processing the rules. It enables the administrator to define a policy and observe how it works before enforcing it using Allow or Deny. Note: It's recommended that you use Monitor to test a new rule to ensure that users will not be interrupted.
Deny	N/A	If any of the rules are met, stops processing the rules. and denies the authentication. It's a good practice to write a descriptive message for the user as to why they were denied. For example, if the policy checks for disk encryption, indicating that disk encryption is required would explain why the authentication was denied.
Deny	With Crowdstrike Quarantine, Zscaler Force Remove Device, SentinelOne disconnect from network, Cybereason Isolate	Stops processing the rules and will deny the authentication. It's a good practice to write a descriptive message for the user as to why they were denied. For example, if the policy checks for disk encryption, indicating that disk encryption is required would explain why the authentication was denied.
Customize notification	N/A	You can add an optional message that explains why an authentication was denied by a policy rule under Customize notification.

 

Device posture evaluation and security

Device posture is always evaluated at the time authentication is performed. Beyond Identity does not rely on previous values for posture attributes to decide policy.

All values sent from the device to the cloud are sent over a secure channel (https), and posture attributes are also cryptographically signed with the user's credential.

For information about leveraging risk and misconfiguration detections to enable security controls via the Beyond Identity policy engine. see Risk Signals & Policy Configuration. 

 

Viewing and Restoring Previous Policy Rules

You can view a list of all previously published rules and also restore a specific set of rules. When a set of rules is restored, those rules become the current set and immediately take effect.

1. Click the Last published link at the top page.
   
   A list of all previously created rules, as well as the current rule set, is displayed on the right of the page, along with the date they were last published.
   

2. Clicking on any of the previous rule sets will display those rules on the page. For example, clicking on the previous rule set directly beneath the current rule set will display the policy rules defined for that set.
   

Restore this rule set as the current set of rules

1. Click I want to restore this version located in the upper-right corner of the page.
   

2. The set of rules is previewed on the Edit Policy page. Click Restore. 
   

3. A prompt is displayed asking if you want to publish this set of rules and update the policy. Click Yes, publish changes.
   

This set of policy rules is now in effect.

 

Appendix: Rule Examples

The following sections provide examples for creating rules:

• Rules that apply to a specific transaction type

• Rules that apply to all transaction types

Transaction-specific rules

The following section provides examples for writing:

• An authentication transaction rule

• A device transaction rule

Example 1: Creating an authentication transaction rule

This example creates a rule to allow access to users who are part of the Admin group and are authenticating from an Android device that is registered with Intune and running an Authenticator version greater than version 2.90.0.

1. After logging into the Admin console and opening the Add Rule dialog, select the attributes that are required for authentication for your organization. In this example, we are selecting the following attributes to allow authentication:

   • The Transaction type is Authentication.

   • The user is in the Admin user group.

   • The device platform is Android.

   • The device integration type is registered with Intune.

   • The Authentication version is greater than 2.90.0.

2. To select the attributes, click the Add rule associated with the desired attribute and select or type in a value as follows:
   • For transaction, select Authentication from the drop-down menu.
   • For user, select is in user group and Admin from the drop-down menus.
   • For device platform, select Android from the drop-down menu.
   • For integration, select Intune Registration is Registered from the drop-down menus.
   • For authenticator version, select Is greater than from the drop-down menu, and type in 2.90.0.
3. Leave the default Allow setting.
   
3. Click Add when done. The rule is added to the Policy Rules list.
   

Important: For the rule to be preserved upon exiting the Admin Console, the rule must be published. Multiple rules can be defined before publishing them.

Example 2: Creating a device transaction rule

This example creates a rule that allows a non-jailbroken iOS device that is connected using JAMF to add other devices.

To create a device transaction rule:

1. After logging into the Admin console and opening the Add Rule dialog, select the attributes that are required to allow users to add devices. In this example, we are selecting the following attributes:

• The Transaction type is Device.

• The user is any user.

• The device platform is iOS with Device Jailbreak set to Not Detected.

• The integration is JAMFConnection set to Available.

• The Authentication version is greater than or equal to 2.34.0.

To select the attributes, click the +Add button associated with the desired attribute and select or type in a value as follows:

a. For transaction, select Add Device from the drop-down menu.

b. For user, leave the default setting. (Defaults to any user)

c. For device platform:

i. Select iOS from the drop-down menu.

ii. Click + Add and select Device Jailbreak is and Not Detected from the drop-down menus.

d. For integration, select JAMF, Connection is, and Available from the drop-down menus.

e. For authenticator version:

i. Select is greater than or equal to from the drop-down menu.

ii. Type in 2.34.0.

2. Leave the default Allow setting.

3. Click Add when done. The rule is added to the Policy Rules list.

Note: For the rule to be preserved upon exiting the Admin Console, the rule must be published. See Publishing rules below. Multiple rules can be defined before publishing them.

 

All transaction-type rules

In addition to setting a policy for a specific transaction type, you can set a policy that applies to all transaction types. The following provides an example that writes a policy that denies authentication for any transaction type that matches the criteria set in the policy.

Example: Creating a rule to deny authentication

This example creates a rule that denies users from the QA Group attempting to authenticate or add a device that is installed with an Authenticator version less than 2.40.0.

1. After logging into the Admin console and opening the Add Rule dialog, select the attributes that deny authentication or the ability to add devices that match your requirements. In this example, we are selecting the following attributes::

• The Transaction type is Any. (Does not need to be specified. The default value of Any is implied.)

• The user is in the QA Group.

• The Authentication version is less than 2.40.0.

To select the attributes, click the +Add button associated with the desired attribute and select or type in a value as follows:

a. For transaction, select Add Device from the drop-down menu.

b. For user, select QA Group from the drop-down menu.

c. For authenticator version:

i: Select is less than from the drop-down menu.

ii: Type in 2.40.0.

2. For Then, select Deny from the drop-down menu.

3. Add an optional message in the Customized notification box that is displayed to inform the user why the authentication or device add function was denied. For example, Please update your Authenticator to version 2.40.0 or greater.”

4. Click Add when done. The rule is added to the Policy Rules list.

Note: For the rule to be preserved upon exiting the Admin Console, the rule must be published. Multiple rules can be defined before publishing them.