Leveraging Trust Attributes for Policy Group Definition

Dana Yanch

Cloud Control Center can validate a device’s existence in a particular Identity integration before trusting it and assigning it to a policy group, adding an additional layer of security verification.

This article details all of the trust attributes currently supported and how they can be leveraged for Policy Group Definition.

Elisity Cloud Control Center (CCC) allows administrators to enforce additional layers of trust validation before a device is classified into a Policy Group. By requiring devices to be verified by IdentityGraph connectors or manually reviewed and verified by an administrator, Trust Attributes help ensure that

This article outlines how Trust Attributes are used, how they’re managed in the Identity Graph, and their role in dynamic Policy Group assignment.

Understanding Trust Attributes

The Trust Attributes section of the Device Details page shows how a device has been verified across connected identity sources. IdentityGraph queries each active connector—such as Claroty, Active Directory, ServiceNow, and CrowdStrike—to determine if the device is known in any external system.

Trust status includes:

Known In – The device is recognized by a connector. Interactive tiles for each connector reflect this status.
Not Known In – The device is not currently found in the connector. These tiles appear grayed out.
Manually Verified – An administrator has explicitly marked the device as trusted. This status is used to include devices in Policy Groups that require manual verification.
Unverified – The device is neither known to any identity source nor manually verified.

A device is either Manually Verified or Unverified—these states are mutually exclusive.

In addition, each connector tile displays a status to indicate whether the connector data is current. For each enrichment cycle (typically 24 hours) connectors will be polled for each device.

The status will show as Up to Date if the enrichment event is successful and data is returned for the device.
The status will show as Stale if the enrichment cycle returns no data for the device from the given connector.

Managing Trust Attributes

Administrators can interact with each connector’s data for a device by using the context menu (...) on its Trust Attribute tile. Two actions are available:

Refresh Attributes – Re-queries the connector for the latest data on the device.
Purge Attributes – Clears IdentityGraph of the connector data for the device.

These operations will present confirmation dialogs when clicked to prevent accidental classification changes. Both modals include warnings that a refresh or purge may impact the device’s Policy Group assignment.

To update all connector data for a device at once, the global Refresh button at the top of the Trust Attributes section can be used.

Manually Verified vs. Unverified

Devices that are not known to any connector are marked Unverified by default. If manual verification is required—either for policy inclusion or operational assurance—administrators can set the device to Manually Verified.

This action serves two specific use cases:

It provides an intentional method to classify a device into Policy Groups that require Manual Verification as a condition.
It allows administrators to override the Unverified status when connector data is unavailable or unnecessary.

Only one of these statuses applies at a time: a device cannot be both Manually Verified and Unverified.

Impact on Policy Group Classification

Trust Attributes are directly usable as match conditions within dynamic Policy Groups. This ensures that devices must meet explicit validation requirements before policies are applied.

Policy evaluation behavior:

If multiple Known In match criteria are included in a Policy Group definition using OR logic, a device must be recognized by at least one required connector to match the PG.
If multiple Known In connectors are specified using AND logic, the device must match all selected identity systems.
Unverified devices are excluded from groups that require validation.

By leveraging these attributes, organizations can enforce segmentation based not only on identity, but also on validated trust—whether automated or human-reviewed.

Trust Attributes are supported for the majority of integrations offered by Elisity, as seen in the image below.

With these enhancements, administrators have greater control over device trust status and segmentation enforcement. By leveraging Trust Attributes effectively, organizations can ensure that only properly identified and validated devices gain network access according to their policies.

Utilizing Manually Verified Trust Attribute

By manually verifying assets within the Cloud Control Center, admins can confirm the authenticity of devices and establish their association with the organization. This feature becomes especially valuable when building highly secure policy groups for critical assets, ensuring that only assets that have undergone rigorous admin review can access these sensitive resources. With the ability to establish trust and control over verified devices, organizations can reinforce their security posture and minimize the risk of unauthorized access to their most crucial assets.

To leverage Manually Verified match criteria, first add the match criteria to your policy group. This can be found in Trust Attributes for Devices.

Now you need to review the assets you want to be permitted into this Policy Group. Find your devices in Cloud Control Center, verify them, and edit the device by clicking the three dots and clicking edit. You need to select the Manually Verified box for the asset to be permitted to our Policy Group. If this box is unchecked, the asset cannot be included in our verified Policy Group.

Utilizing Unverified Trust Attribute

It's crucial to note that if a device is unrecognized by any active Identity Connector, IdentityGraph labels it as Unverified. This status can be viewed by navigating to the device's IdentityGraph page and examining the Trust Attributes section.

The Unverified status can serve as a matching criterion when outlining Policy Group Trust Attributes.