1. Help Center
  2. Creating Policies

Policies for Users, Applications and Devices

Before creating a policy, it is essential to onboard users, devices, and applications as objects into Elisity Cloud Control Center.

Elisity dynamically discovers and identifies assets as they come on the network. We have our own built-in identity engine, but we can also integrate with device identity platforms like Clarity and Medigate. Customers can also integrate their existing CMDB like ServiceNow to further enrich asset inventory data, and secure unidentified or unapproved devices on the network.

Once asset inventories are populated, an administrator will begin building policy constructs around this data to use in policy logic. Policy constructs, such as Asset Groups, help simplify and scale Elisity policy and will be covered in a later section.

Quick Links:

Onboarding Users

Onboarding Applications

Onboarding Devices

Onboarding Users:

Users are identities that are reference-able objects in Elisity policy for granular security control. An administrator can onboard users into Cloud Control Center by leveraging the Microsoft Active Directory connector. See the following guide to configure the Microsoft Active Directory connector:

Microsoft Active Directory

Once a user has been onboarded, user attributes such as AD groups and Title can be viewed and leveraged in your policy logic by clicking the name. Other information such as how the user was discovered, applied policy, log on and off times, IP addresses, and much more can also be displayed. Lastly, detailed analytics about the user behavior, such as denied flows, policy violations, traffic flows, and login activities, are also provided.

Onboarding Applications:

Applications are reference-able objects in Elisity policy and allow an administrator to specify which resources are the relative source and destinations for the policy logic. Three different applications exist in the Elisity platform: DPI-based, AWS-based, and custom-defined applications. Elisity can detect thousands of applications and populate them in Cloud Control Center based on our deep packet inspection engine, which can be used to define the type of application or protocol traffic flow the rule is to match on. AWS deployed applications and their attributes (ie. Tag, Instance ID, AMI) can be dynamically learned and easily leveraged within a policy as sources and destinations. Lastly, custom applications can be manually defined by an administrator and leveraged in policy in a similar fashion to how AWS applications are. Custom applications can live anywhere including on-premise and in the cloud.


You can view all the DPI based applications by navigating to the Application section on the left pane of Cloud Control Center. Clicking on an application name exposes more details about the application type, application category, and policy or application analytics.


Elisity offers seamless API based automation to connect, discover and onboard cloud hosted applications into the Elisity fabric.

To onboard AWS hosted applications navigate to the Policy Fabric section on the left pane of Cloud Control Center and select Access Service. At the top right-hand side of the page, select Private Cloud.

Once selected, if no AWS accounts have been integrated, you will be presented with a page to input your AWS account details. Select “Add Account Information” and follow the tool tip instructions to collect and input the required information for Cloud Control Center to integrate with AWS. Click Submit once completed. Cloud Control Center supports the integration of multiple AWS accounts for cross account security and connectivity.

NOTE: The last required field, AWS Account ID is your organization’s AWS account ID, not the ID provided in the tool tip instructions. The latter is used for Role ARN creation only.

After the VPC has been onboarded, all the applications hosted in that VPC will show up under the application section of Cloud Control Center with their instance ID as their name.

TIP: Filter the output to only show AWS and Static applications by selecting “Applications and Static Instances” at the top of the page.

Selecting the instance ID under the name column will open a window with more detail about the AWS application including what policy, if any, it was mapped to, IP addresses, AMI information, and Application Name (cloud native tag). Application Name is a powerful way to reference a cloud hosted application in Elisity policy as Cloud Control Center will immediately recognize changes made to application name when the cloud native tag is modified.

NOTE: For Application Name to populate and be available for consumption when building policy, you must assign a tag to the application in AWS using the following format:


On-Premise applications can be statically onboarded so that they can be referenced during policy creation. An application can be identified by its IP Address or Fully Qualified domain name (hostname) or groups of Applications can be identified by the Subnet IP they can be reached on. Fill out the mandatory fields such as Application Name, Onboard by, Site Name or Edge Node, FQDN/IP Address or Subnet Group, and ports. 

Today, onboarding a static application is done on the Device page the same way a statically defined device is onboarded. In the future, this workflow will be moved to the Application page. 

Navigate to Devices > Onboard Device > Add Device. You will be presented with a page to with fields to fill out to define the static application. Fill out the required fields and select Submit. The application will now be listed under the device inventory and can be referenced in Elisity policy match criteria. 



After deploying the static application, it is reference-able like any other device on the network.

Onboarding Devices:

Devices are reference-able objects in Elisity policy and allow an administrator to specify which resources are relative source and destinations for the policy logic. The Elisity Cognitive Trust platform provides several ways to onboard devices including dynamic OT/IoT/IoMT discovery, Active Directory, Claroty, and static definition.

Elisity Cloud Control Center has access to a continuously updating catalogue of thousands of devices. If you connect an OT/IoT/IoMT device to the network, through several network layer mechanisms and catalogue mapping, Elisity can dynamically discover what the device is, the manufacturer of the device, the device type, and other metadata that can then be referenced during policy creation.

If your organization wishes to integrate Cloud Control Center with Claroty, a leader in OT discovery and management, to onboard devices, see this link for instructions.

Devices such as PCs and mobile phones can also be discovered through means such as DHCP, HTTP User agent, and Active Directory.

Attributes of a dynamically discovered device can be edited by selecting the device, selecting More Options and then Edit Device.

Devices that are not discovered dynamically can be onboarded into Cloud Control Center in a static fashion. To add a static device, navigate to devices section on the left pane of Cloud Control Center and select Onboard Device. Either select Add Device to onboard a single device or Add Multiple Devices to onboard many at the same time.

Fill out the mandatory fields such as Device Name, Onboard by, Site Name, FQDN/IP Address or Subnet Group, and any of the optional attributes such as MAC Address, Device Class and Device type. Optionally, you can specify which Asset Group, a policy construct we will go over later in this document, this device should be a part of. Many of the attributes you can define on a per device basis can be referenced during policy creation for different levels of match criteria granularity.

After you have onboarded a statically defined device you can see all the details about that device by clicking its name.

Next up: Policy Constructs and Logic