Introduction

What is Identity-Based Microsegmentation?

Traditional network security relies on IP addresses and VLANs to control access. This approach has a fundamental problem: IP addresses don't tell you who or what is communicating, only where traffic is coming from.

Identity-based microsegmentation changes this paradigm. Instead of asking "Is this IP address allowed to talk to that IP address?", Elisity asks:

This shift from location to identity makes policies intuitive, portable, and dramatically easier to manage.

Why Elisity is Different

Elisity applies an identity-based policy model to the supported network infrastructure you already own, including switches, wireless controllers, and firewalls. Supported enforcement surfaces and deployment requirements are maintained in the Hardware Compatibility Matrix. The policy model also covers supported cloud workloads. For device-to-cloud paths, see North-South Enforcement Mechanics: Devices to Cloud Workloads; cloud onboarding guides describe enforcement between workloads using the supported cloud-native controls.

Cloud Control Center provides the management experience. The Virtual Edge translates identity and policy between Cloud Control Center and the infrastructure it manages. The Virtual Edge operates at the control plane, out-of-band from the data path; it programs supported network infrastructure with identity-based policy while enforcement remains native to the infrastructure.

Figure 1: Animated high-level architecture walkthrough. Cloud Control Center coordinates policy and visibility; the Virtual Edge operates in the control plane, while enforcement remains native to the infrastructure.

The Core Promise

👁️ Visibility

See every device, user, and application on your network with rich identity context from AD, CMDB, and device inventory integrations.

✨ Simplicity

Build policies using natural groupings (by device type, department, function) instead of IP addresses.

🛡️ Confidence

Test policies in simulation before enforcement, with AI-powered recommendations from Insights.

Core Constructs

How Policy Works in Elisity

At its simplest, an Elisity policy answers one question:

"Can assets in Group A communicate with assets in Group B, and if so, how?"

Figure 2: Policy = Source Policy Group + Security Profile + Destination Policy Group

Policy Foundations

With the architecture established, the remainder of this guide focuses on the policy model: Policy Groups classify assets, Security Profiles define traffic rules, and the Policy Matrix expresses the resulting communication decisions. Virtual Edge deployment planning belongs in the Virtual Edge and Virtual Edge Node Design Guide.

Policy Groups: The Foundation

Policy Groups answer the question: "Which assets should receive the same security treatment?"

CCC has two Policy Group types, Dynamic and Static. Dynamic Policy Groups can be built by device identity, by user identity (Active Directory or Entra ID), or by business labels. Static Policy Groups match IP subnets. Most deployments combine all four approaches: identity-based dynamic matching covers the majority of devices, while user, subnet, and label-based groups fill specific gaps.

User-Based Dynamic Policy Groups

A user-based Dynamic Policy Group classifies by who is logged in, using user identity from Active Directory or Entra ID (for example, membership in an AD group). The classification follows the user across devices and locations, which makes it the right fit for BYOD and knowledge-worker access.

Label-Based Dynamic Policy Groups

A label-based Dynamic Policy Group classifies by why a device matters in business terms, using imported labels (for example, "Mfg Line 1") applied manually or through the API. Label-based groups are the primary pattern for OT zones and other device groups that do not map cleanly to a discovered attribute.

IdentityGraph: The Source of Truth

Before understanding Policy Groups, it's essential to understand IdentityGraph, the identity engine that powers dynamic classification.

IdentityGraph is an intricate mapping service that dynamically constructs a holistic view of every entity in your network. It doesn't just see devices; it perceives relationships, roles, and patterns by aggregating data from multiple sources.

Attribute Layers in IdentityGraph

The Consistency Score

Consistency Score measures agreement between the Category values reported by different identity sources for the same device. Category is a key match criterion for Policy Groups. A high score indicates that sources agree on that classification; a low score flags disagreement to review before using Category in policy. The score does not measure the accuracy of every device attribute.

Dynamic Policy Groups

Dynamic Policy Groups classify assets automatically using IdentityGraph attributes as match criteria:

As devices are discovered, IdentityGraph enriches them with attributes from connected identity sources. The Identity Engine then evaluates devices against your Policy Groups and automatically assigns them based on match criteria.

Match criteria can leverage:

• Core effective attributes: Type, Category, Vendor, Model, Operating System, Hostname, FQDN, Label, Genre, Class, Trust Attributes (recommended for most use cases)

• Connector-specific attributes: ServiceNow CMDB Class Name, Claroty Device Type Family or Risk Score, CrowdStrike Tags

• Active Directory attributes: User, User Groups, OU

• Network attributes: VLAN, SSID, MAC address (including partial matches using CONTAINS), IP subnet, and Site Label. Adding a Site Label condition makes the group a Local Policy Group for that site.

Static Policy Groups

Static Policy Groups classify assets by network location (IP/subnet) when identity-based classification isn't available or appropriate.

Global vs Local Policy Groups

Policy Groups can be scoped globally or locally based on organizational needs:

Evaluation Order: When a device is evaluated for Policy Group matches, local Policy Groups are evaluated first. If no local match is found, the device is evaluated against global Policy Groups. This local-first evaluation ensures site-specific rules take precedence.

Most deployments run a mix of the two. Local Policy Groups are Dynamic Policy Groups bound to one Site Label; Static Policy Groups are always global. Local Policy Groups are not enabled in every tenant by default, so confirm availability in your environment.

Connector Precedence & Core Effective Attributes

Several attributes overlap across connectors. Category, Type, Vendor, Model, and OS can each be reported by more than one source. When sources disagree, the higher-ranked connector wins, and that value becomes the Core Effective Attribute used for policy matching. For example, if CrowdStrike reports Category = PC while another source reports Server Appliance and Storage, the Core Effective Category is PC when CrowdStrike is ranked higher. A source that reports Unclassified never overrides a lower source's Category.

Category provides a standardized classification derived primarily from type and vendor data.

Selecting Connector Precedence

CCC ships a default order with Manually Configured first. A connector added later is placed at the bottom, below Elisity Native, so review the order after adding one (Settings > Connectors, Reordering Mode). Keep Manually Configured at the top so administrator overrides always win. Order the remaining sources according to the authority, accuracy, and freshness of their data in your environment. The source families below are a selection guide, not a universal ranking.

• Directory and endpoint management: Active Directory / Entra ID, Microsoft Intune, Tanium, and 42Gears SureMDM.

• Endpoint security: Microsoft Defender, CrowdStrike, SentinelOne, and Palo Alto Cortex XDR.

• OT, IoT, and cyber-physical security: Microsoft Defender for IoT, Claroty, Medigate, Armis, ORDR, Nozomi Networks, Dragos, Asimily, and Palo Alto Networks IoT Security.

• Asset inventory and exposure context: ServiceNow, NetBox Labs, TenableOne, and Rapid7 InsightVM.

• Other identity sources: customer-maintained Custom Connectors, Open Connector, and Elisity Native.

You can also pull a specific attribute directly from a chosen source rather than relying solely on the precedence order.

Validate the configured connector order against representative assets and the identity data available in your environment.

The Custom Connector

Any custom database or spreadsheet can become a system of record in IdentityGraph through the Custom Connector, including IT, SecOps, OT and ICS team spreadsheets, identity platforms that have no dedicated connector, or a new primary database. It is self-contained, with no middleware to deploy.

The connector is multi-instance, so each team's data stays separate: a deployment commonly runs distinct IT, Security, Network and OT instances. Data arrives by XLSX upload or API, and enrichment is applied as a merge and replace, with duplicate and error checking on ingest. Ordering is customer-defined, and trust attributes are supported alongside everything else.

What each instance carries

Each instance carries Type, Hostname, FQDN, Label, Vendor, Model, Operating System, Category, Description, Genre, Class, Owner Username and Owner Id, plus up to 40 custom attributes (30 text, 10 integer) and time-based access dates. Devices are matched by MAC, IP, IP and MAC, or hostname, in the order you set. New instances join the bottom of the connector precedence order, and their Trusted Connector setting is off until you enable it. Advanced settings cover timers, match ordering, data purge and exclusions. Instances support search and filtering, custom attributes, custom icons, full CRUD operations, RBAC, and the Device List page.

Referencing Custom Connector attributes in match criteria

Because the connector is multi-instance, a Custom Connector attribute is referenced together with its instance qualifier, for example Type (Custom Connector | OT Devices) = HMI. The qualifier is what keeps two teams' identically named attributes from colliding in a Policy Group definition.

Verified vs. Unverified Devices and Trust

A Verified device is one registered in a verified system of record. A representative customer definition: an HMI, PLC, laptop, tablet, IoT/IIoT device, server, printer, or phone on the internal wired or wireless network that is registered in any verified system of record.

Trust recommendations (used as match conditions when building Policy Groups):

• Known in Active Directory and/or Entra ID

• Known in CrowdStrike or SentinelOne

• Known in ServiceNow. In many cases ServiceNow ingests data from other sources and from discovery scans in order to create CI entries, so apply Connector Filtering Rules to exclude those CI classes:

  • CMDB Name

  • Configuration Item

  • DNS Name

  • Exit Interface Routing Rule

  • IP Address

  • IP Switch Forwarding

  • Router Interface

  • Switchport

• Known in Intune (add an AND "Compliant" condition)

• Known in Microsoft Defender for Endpoint (add an AND "Onboarded" condition if Defender scans same-VLAN devices)

Confirm the Trusted Connector setting for each connector you rely on for trust conditions.

Combine Policy Group match conditions with AND / OR. Available operators depend on the attribute type. Numeric attributes, such as Risk Score and integer Custom Connector attributes, support equals, not equals, greater than, greater than or equal to, less than, less than or equal to, and ranges. Subnet and Site Label support equals only, and Active Directory distinguished names support CONTAINS only. Choose the operators available for the selected attribute.

Policy Group Ordering

A device belongs to exactly one Policy Group at a time, and it can move between Policy Groups as its conditions change. Higher stack-ranked Policy Groups are matched first. The hard ordering, top to bottom, is:

1. Locked devices stay in their Policy Group

2. Local Policy Groups for the device's Site Label, in admin order

3. Static Policy Groups with Prioritize over Dynamic, by the most specific subnet

4. Global Dynamic Policy Groups, in admin order

5. Unassigned

Static Policy Groups without priority never receive discovered devices; they classify IP addresses that aren't discovered devices (datacenter, VPN, remote subnets), as does Internet.

A device that is locked to a Policy Group stays there regardless of dynamic attribute changes. Locking applies to assets only; Policy Groups themselves cannot be locked. You can lock a single asset or assets in bulk, or enable Auto-Lock Devices on a Dynamic Policy Group, or on a Static Policy Group with Prioritize over Dynamic enabled, to lock every device it receives.

Genre Tagging

Each Policy Group can be tagged with a genre (IT, OT, IoT, or IoMT) for dashboard filtering and reporting.

Baseline Policy Groups

Once Insights is enabled, Insights proposes Dynamic Policy Group suggestions for devices in the Unassigned Policy Group, tailored to your environment's industry vertical. Suggestions are built from Category and trust (for example Verified PCs, Unverified Printers), and each carries a genre (IT, OT, IoT, IoMT).

Recommended Baseline Custom Policy Groups

• Quarantine: label-based; Deny-All to every Policy Group

• Bypass: label-based; temporary Allow-All

• Internet-Only: label-based; allows only Internet plus DHCP/DNS

Recommended Baseline Static Policy Groups

• Guest networks

• BYOD (if applicable)

• Datacenter

• Remote-Access VPN

• Intranet (RFC 1918 plus org-owned public space used internally)

• Site-to-Site / B2B VPNs

Prioritize the Guest and BYOD static groups above the Dynamic Policy Groups.

Unassigned vs. Unclassified

Unclassified is the Category a device carries when no source has assigned it one of the standard Categories. Unassigned is the Policy Group a device lands in when it matches no Policy Group. Unassigned devices still appear in the Matrix and receive Security Profiles and policies like any other Policy Group.

Security Profiles: The Rules

A Security Profile is an ordered list of Allow and Deny rules that defines what traffic is allowed between Policy Groups. Traffic that matches no rule receives the policy's Final Policy Action; there is no implicit deny.

The Policy Matrix

The Policy Matrix visualizes all Policy Groups and their relationships:

Figure 3: The Policy Matrix showing Allow, Deny, Custom, Independent Control and No Policy cells. Active and simulated policies are drawn differently.

Each cell in the Matrix carries one of five policy states:

• Allow: communication between the two Policy Groups is permitted

• Deny: communication is blocked

• Custom: a Security Profile permits or blocks specific ports and protocols

• Independent Control: Elisity is intentionally not enforcing between these Policy Groups; a third-party control (for example, a firewall) governs this path

• No Policy (Default Allow All): no decision has been made yet for this pair

Working in the Matrix

Toolbar controls

The Matrix toolbar carries Refresh (pick up any changes), Show Traffic View (show traffic between cells), Reveal More Characters (matrix size optimization), View Mode, Zoom, and the Legend.

View Modes

Three view modes are available: Outline, Filled, and Accessibility. The mode is a per-admin-user setting, so each administrator customizes their own view of the Matrix without affecting anyone else.

Filters

Filters build custom views of the Matrix, either for visibility or for policy creation and editing. Filters can be saved and shared with other users, which is what lets a team standardize on a set of working views rather than rebuilding them per session.

Table View

Table View is the operational counterpart to the Matrix View: it performs bulk operations across a wide range of the Matrix, including activation/enforcement, deletion, and moving policies to simulation.

Creating Policies

Policies are created for an individual cell or in bulk, in the platform or via API. The workflow has three decisions:

1. The policy name, auto-generated from the two Policy Group names and editable.

2. The Security Profile: select a saved profile or create a new one.

3. The Final Policy Action, Allow or Deny, for traffic that no Security Profile rule matches; and whether to save the policy as Active (enforced) or Simulation.

Policy Lifecycle

Elisity policy deployment follows a natural progression:

Figure 4: The five phases of policy deployment

Phase 1: Discover

Goal: Gain visibility into all assets

• Deploy Virtual Edges

• Onboard switches as VENs

• Enable discovery & telemetry

• Connect identity sources

Phase 2: Classify

Goal: Organize assets into Policy Groups

• Review Insights suggestions

• Create Dynamic Policy Groups

• Assign Security Levels

• Reduce Unassigned to <20%

Phase 3: Define

Goal: Specify communication rules

• Build Security Profiles

• Deploy policies via Matrix

• Use Traffic Analytics

• Start broad, refine later

Phase 4: Simulate

Goal: Validate without blocking

• All policies in Simulation Mode

• Monitor Traffic Analytics

• Use Traffic Review

• 7-30 days observation

Phase 5: Enforce

Goal: Activate validated policies

• Transition to Active

• Start with low-risk

• Monitor for blocks

• Target: 76%+ Device Score and Device Policy Score

Discovery Requirements

A device must have both an IP address and a MAC address to show as online in CCC. Attachment is confirmed through the Device Tracker (state REACHABLE). Device Tracker support varies by vendor, so confirm what your platform provides as part of site readiness; CDP/LLDP information enriches attached devices but does not confirm attachment. Identity matches occur by IP+MAC or MAC-only; IP-only matching is an opt-in setting per connector (for example, when correlating ServiceNow with CrowdStrike).

The Virtual Edge reads identity metadata from each VEN, including device-tracking entries and CDP/LLDP neighbors, and receives flow telemetry (NetFlow, IPFIX or sFlow) that the VEN exports. This is control-plane telemetry, not forwarded user traffic. Plan the Virtual Edge deployment model before onboarding the infrastructure it will manage.

The device detail view in CCC records the attach, detach and enrichment events for each device, up to the most recent 250 events within the last 30 days, which is usually the fastest way to answer "when did this device change?" during triage.

Data Analytics

Discovery and policy activity are not only visualized in CCC; analytics and logs can be exported to a SIEM for correlation and long-term retention.

Security Profiles in Depth

A Security Profile is an ordered list of Layer 4 rules (protocol and source or destination ports), each set to allow or deny. Two common patterns are: allow specific ports and deny the rest, or deny specific ports and allow the rest. Saved profiles are reusable across any cell in the Matrix.

Reading the Traffic Matrix

The Matrix uses a consistent visual language:

• Green: allowed Layer 3 communication

• Red: denied Layer 3 communication

• Blue: Layer 4 rule (a mix of allow and deny)

• Outlined cell: policy is in Simulation

• Filled cell with a shield: policy is Active (enforced)

• Cells with a policy but no observed traffic in the selected window are marked separately (for example, Simulation Policy (No Traffic)). Open the Matrix Legend for the full key.

Reading a Simulation Matrix

Reviewing a Matrix that is still in simulation comes down to two outcomes:

• Green (allowed traffic) observed: the policy is ready for activation.

• Red (denied traffic) observed: investigate before activating. There are three causes: a misclassified device, a previously unknown legitimate use case, or genuinely malicious traffic.

Denied traffic is where simulation feeds remediation: send misclassified or unverified devices back to your inventory tooling for reconciliation, and send devices confirmed as rogue to the security team for removal from the network.

Policy Sets

A Policy Set is an individual Matrix, scoped to a specific site, to a tagged group of sites, or to a function. Conceptually you organize Policy Sets by grouping sites that will share the same Policy Groups and policies; the typical functional grouping is site type: Tier 1, Tier 2, Tier 3.

Policy Sets can be created, edited, cloned or deleted, and each one is scored separately in Executive Reporting. Site Labels are assigned to Policy Sets, and that assignment is what lets administrators stage sites in a Simulation set before migrating them to an enforced set.

Replica Policy Sets

A Replica Policy Set mirrors a Standard Policy Set's Policy Groups but keeps the entire matrix in Simulation. You can create up to 5 replicas per Standard set, useful for migrating sites or waves into enforcement with confidence while the Standard set continues to operate. Policy Sets can also be duplicated or cloned, and custom views help focus on a subset of the matrix.

Insights

Insights analyzes your devices, observed traffic and network behavior to recommend Policy Groups, device categories and policies, so you can build segmentation policy faster. Every recommendation is shown to an administrator for review.

Enabling Insights

1. Go to Settings > System and open the Advanced tab.

2. In the Insights card, turn on Enable Insights.

Figure 5: Insights surfaces recommendations for administrator review. Nothing is applied until an administrator accepts it, or until an automation rule an administrator created does.

How Device Classification Works

Most devices on your network are classified by the identity sources Elisity already uses: your connected integrations and Elisity's own discovery on the network. Insights fills the gap for devices that are still Unclassified.

1. Discovery. A device appears in IdentityGraph with a Device Category of Unclassified.

2. Grace period. Insights waits briefly (5 minutes by default) so your other identity sources can classify the device first. If one of them does, Insights takes no action.

3. Evidence. If the device is still Unclassified, Insights evaluates the evidence available for that device and for similar devices on your network.

4. Suggestion. Insights proposes a Device Category with a confidence score from 0 to 100 and shows the supporting evidence. The suggestion appears in the Insights table as Category - MAC Adjacency or Category - Traffic Pattern.

5. Review. An administrator accepts or rejects the suggestion, or an automation rule an administrator created does. Accepting changes the device's Device Category, which can move it into a different Policy Group. The Insight Details dialog shows the current and new Policy Group before you accept.

Depending on how much evidence is available, a suggestion can appear soon after the grace period, or only after more of the device's traffic has been observed.

Examples of the Signals Insights Uses

Insights combines several independent signals to decide what a device is. The three below are examples that are easy to reason about, not the complete list. Insights also weighs additional signals and context about the device and about similar devices on your network.

🔍 MAC Address Adjacency

Manufacturers usually assign MAC addresses in blocks, so devices from the same product line often share a prefix and sit close together. Insights looks at the categories of already-classified devices with nearby MAC addresses. This signal counts for little with devices that use randomized (private) MAC addresses.

Example: "Twelve devices with nearby MAC addresses are classified as Medical Devices."

📊 Traffic Patterns

Devices of the same kind tend to communicate in similar ways. Insights compares how the device behaves on the network with devices whose category is already known.

Example: "This device communicates the way the printers on your network do."

🌐 Public IP Ownership

For devices that talk to destinations on the internet, Insights checks who owns those public IP addresses using public registration records. The services a device connects to are a strong hint about what it is.

Example: "Most of this device's internet traffic goes to a video-conferencing service," which points to a collaboration device.

Insight Types & Priorities

Insights are categorized by type and assigned a default priority:

Insight Statuses

Insights that no longer apply (for example, because the device was removed) are withdrawn automatically.

Policy Suggestions: Traffic Review

After policies have been in simulation, Traffic Review uses observed traffic to recommend enforcement decisions.

There are three reasons to evaluate traffic:

• To aid the categorization and assignment of a device, by looking at its communication profile.

• To review simulation policies and judge whether the observed traffic is expected for those Policy Groups.

• To review denied flows on policies that are already activated.

This is most commonly done by reviewing the traffic-flow detail of policies in simulation. Existing network flow-analysis tooling already in your enterprise stack can serve as a useful cross-reference.

Traffic Review Timer

A simulated policy is suggested for activation once it has stayed unchanged for the timer period and no traffic has matched it.

* By default, Insights doesn't suggest activating policies for SL3 or SL4 Policy Groups; you decide when those move to enforcement. If you raise Policy Suggestion Maximum Security Level to include them, Insights applies the longest period of your chosen timer.

Security Levels

Each Policy Group has a Security Level from 1 to 4 (or No Security Level), set when the group is created and changeable later. This classification drives multiple platform behaviors:

• Device Score calculation: Higher Security Levels carry more weight

• Traffic Review timing: Longer observation windows for critical assets

• Operational prioritization: Focus attention on highest-risk policy decisions

Elisity Security Levels align with the IEC 62443 industrial cybersecurity standard.

Each suggested Policy Group comes with a default Security Level from Elisity's library; review it before creating.

Figure 6: Security Levels aligned with IEC 62443

Security Level Guidelines

Insights never assigns SL4 to the Policy Groups it suggests and, by default, doesn't suggest activating policies for SL4 groups. Assign SL4 yourself.

The Device Score and Device Policy Score

Each Policy Set has two scores from 0 to 100. The Device Score weights each Matrix cell by the Security Level and the number of devices in the Policy Groups on each side, so covering critical, populous groups counts most. The Device Policy Score is the share of Matrix cells that have a policy applied. In both, enforced policies count in full and simulated policies count at 10%. Bands: 0-10 Poor, 11-50 Moderate, 51-75 Adequate, 76-100 High.

Score Interpretation

Healthcare

Healthcare environments present unique microsegmentation challenges: thousands of connected medical devices, strict regulatory requirements, and the critical nature of patient care systems.

Modern healthcare networks mix IT, IoT, and IoMT devices on the same VLANs, a pattern often called "VLAN sprawl." Because Elisity applies policy at the existing access layer, it delivers microsegmentation even on flat networks, with zero dependency on a network redesign.

Deployment Patterns by Vertical

Before the vertical detail in this section and the Manufacturing section that follows, it is worth seeing the three common patterns side by side. Carpeted space (the enterprise campus) is included because it is the pattern most often deployed alongside the other two.

Carpeted Space

Carpeted space is the enterprise campus pattern: standard user and IT estate on the access layer, generally built on Global Policy Groups rather than site-specific ones. It usually coexists with controls the customer already runs (802.1X and guest wireless through a NAC solution, and a SASE solution for off-network access), so the segmentation work concentrates on separating verified from unverified PCs, IT and IoT devices. Cross-zone enforcement is typically required, and sites are grouped into a Policy Set per site type.

Healthcare Network Segmentation

Figure 7: Healthcare network segmentation with Elisity Policy Groups

Healthcare Policy Group Strategy

Healthcare Policy Pattern: Protect Critical Medical Devices

Manufacturing

Manufacturing and industrial environments require protecting operational technology (OT) assets that often run legacy systems, use proprietary protocols, and cannot tolerate downtime.

Understanding Purdue Model and IEC 62443

Two frameworks commonly guide OT security architecture:

Mapping Purdue Zones to Policy Groups

Figure 8: Purdue zones with recommended IEC 62443 Security Levels

Manufacturing Policy Pattern: Zone-Based Enforcement

The Purdue Model Visibility Paradox

Traditional Purdue model implementations create a difficult trade-off: segmentation vs. visibility.

Organizations implementing strict Purdue zones often use VLANs or hardware firewalls to segment production cells. While this achieves isolation, it creates blind spots:

Staged Rollout

Successful microsegmentation deployments follow a phased approach. Attempting to enforce all policies at once leads to production outages and loss of stakeholder confidence.

Figure 9: The Day 0/7/30/90 staged rollout framework

Day 0: Foundation (Week 1)

Goal: Deploy infrastructure and establish visibility.

• Deploy Virtual Edges (switch-hosted, hypervisor-hosted, or cloud-hosted)

• Onboard Virtual Edge Nodes

• Configure identity integrations (AD, CMDB)

• Enable Endpoint Discovery and Flow Telemetry

• Verify devices appearing in Cloud Control Center

Target score (Device Score and Device Policy Score): 0% (expected: no policies yet)

Day 7: Discovery & Classification (Weeks 1-2)

Goal: Classify discovered assets into meaningful Policy Groups.

• Review Insights Policy Group Suggestions

• Create core Policy Groups for major device categories

• Assign appropriate Security Levels

• Build initial Security Profiles

• Reduce Unassigned Policy Group to <20%

Target score (Device Score and Device Policy Score): 0-5% (initial simulated policies)

Day 30: Simulation & Validation (Weeks 2-6)

Goal: Deploy policies in simulation mode and validate against real traffic.

• Accept Simulation Suggestions from Insights

• Deploy all policies in Simulation Mode

• Review Traffic Analytics daily

• Review Activation Suggestions in Insights to find simulated policies that are ready to activate

• Adjust policies based on observed traffic

Target score (Device Score and Device Policy Score): up to 10% (simulation counts 10%). Track simulation progress by Policy Group pairs that have a simulated policy, not by score.

Day 90: Enforcement (Weeks 6-12+)

Goal: Transition validated policies from simulation to enforcement.

• Start with low-risk policies (SL1 → SL1)

• Progress to medium-risk (SL2 → SL2)

• Finish with high-risk (SL3-4 involvement)

• Monitor for unexpected blocks

• Document exceptions and iterate

Target score (Device Score and Device Policy Score): 76%+ (shown as High coverage)

Mode Transition Gates

Successful deployments formalize the transition between modes with explicit review gates and stakeholder checkpoints:

Gate 1: Discovery and classification → Simulation

Gate 2: Simulation → Active (enforced)

Distribution Zones & Intelligent Tag Distribution (ITD)

A Distribution Zone (DZ) is a logical grouping of Virtual Edges and VENs that share Policy Group Tag mappings, overlaid on existing hardware without re-architecting the network. DZs operate independently of Site Labels; you can run one DZ across many sites, one DZ in a single site, or many DZs within one site.

Distribution Zone Types

Core DZ

A central tag repository for scalable, cross-zone policy distribution. It can import the mappings of all zones except Isolated zones, or selectively import them from chosen Access and Core DZs. Supports ITD.

Access DZ

Typically used at access or aggregation layers. Shares only its local members' tag mappings, supports ITD, and can feed Core DZs.

Isolated DZ

Bound to a single site. Separates network areas that reuse overlapping IP address space, such as identical OT cells. Mappings stay inside the zone. An Isolated DZ cannot be imported by a Core DZ and does not use ITD.

Workload DZ

Created for cloud workloads discovered through cloud connectors. Capacity and mapping distribution are managed automatically, and ITD does not apply.

Figure 10: Distribution Zones are logical policy-distribution boundaries that align mapping scope with the existing topology.

You may also hear the term Global DZ for a Core DZ set to import mappings from all zones (Import Group Tags From All Zones). It holds every mapping except those in Isolated zones, so policy between zones can be enforced at the aggregation layer. Set its Distribution Zone Limit to about 90% of the mapping capacity of the aggregation hardware. The limit raises alerts; it does not cap distribution.

How Intelligent Tag Distribution (ITD) Works

Distribution Zones are logical policy-distribution boundaries that overlay the existing topology. Access Zones hold local mappings, Core Zones can support cross-zone distribution, and Isolated Zones keep mappings within their boundary. This lets mapping scope reflect the architecture and the capacity of the enforcement infrastructure.

ITD works from the flow telemetry the Virtual Edge already collects. When a VEN reports traffic between a local device and a device in another Distribution Zone, the Virtual Edge installs that remote device's Policy Group mapping on the reporting VEN. The mapping is removed after a period with no matching traffic. ITD requires Flow Telemetry, applies to individual device addresses, and can be suppressed for a zone during onboarding.

Figure 11: Intelligent Tag Distribution supports the required mapping distribution for observed cross-zone communication.

Cross-zone mappings are temporary. They are retained only while needed for the observed communication, which bounds the mapping footprint instead of distributing every mapping everywhere.

Where Enforcement Happens

Enforcement happens natively on the infrastructure the Virtual Edge programs. Where and how a platform applies policy depends on the platform; see the Hardware Compatibility Matrix and platform deployment guide. Until a remote device's mapping arrives, that device isn't in any Policy Group, including Unassigned, and traffic to it follows the platform's default behavior. Enable ITD, or import the remote zone into a Core Distribution Zone, wherever policy between zones must be enforced.

As part of site readiness, confirm that no interface on the enforcement path has been configured locally to bypass policy. The platform deployment guide lists the checks for each supported platform.

Scale Context

Different hardware enforces against different tag-capacity limits. Distribution Zones let you align segmentation to these limits without a redesign. These are hardware capacities, not Distribution Zone types:

Mapping capacity varies by platform and model. Use the Hardware Compatibility Matrix for your models, size each Distribution Zone to its smallest member, and set the zone limit to about 90% of that capacity.

Initial Site Deployment Methodology

Complementing the Day 0/7/30/90 framework, roll out in waves of 5-10 small or mid-size sites of similar geography or site type. For each wave:

1. Assign the wave's Site Labels to a Replica Policy Set of the target Standard Policy Set (the replica keeps every policy in Simulation). If the wave uses its own Distribution Zone, keep Suppress Tag Distribution on until the sites are ready.

2. Run a Device Classification Audit (repeat as needed).

3. Run a Traffic-Flow Audit (repeat as needed).

4. Hold a team review before cut-over and adjust classification and policy.

5. Move the Site Labels to the Standard Policy Set during a change window.

“No Device Left Behind”

• Review the Unassigned Policy Group filtered to the in-scope sites.

• Sample-audit IoT and non-PC Policy Groups.

• Confirm IdentityGraph looks right across connectors.

• Export "unverified" assets to the CMDB team to flag rogue devices versus add-to-CMDB candidates.

Best Practices

Policy Group Naming Conventions

Simulation Duration Guidelines

Recommended minimum observation before activation (operational guidance; independent of the Insights Traffic Review Timer). Insights suggests activation on its own observation window, set by the Traffic Review Timer and the Security Level. Choose a timer option that fits these minimums so Activation Suggestions do not arrive before your review gate.

Common Mistakes to Avoid

Only Create a Policy Group for Differentiated Access

"Start with 15-30 groups" is a count, not a test. The test is simpler: limit complexity by limiting the number of Policy Groups, and create a new one only if those devices require differentiated access. If two candidate groups would end up with the same policies in every cell of the Matrix, they are one group.

Expect granularity to grow over time rather than up front. Servers are usually the first split, followed by progressively more specific groups as custom attributes such as risk score mature in your connectors.

Score Targets by Phase

RBAC Personas

Two roles ship by default: Tenant Admin (read/write across all sites) and Tenant User (read-only across all sites). Customers typically add four to five custom personas auto-assigned via SSO; OT and multi-entity customers often define more.

Policy Group Hierarchy Recommendation

When ordering Policy Groups from most to least specific, a proven hierarchy is:

1. Most-specific single-label matches

2. IoMT/OT-specific groups

3. Specific non-IT groups (Physical Security, BMS, collaboration)

4. Catch-all IoMT/OT

5. AD device match

6. Verified PCs & Servers

7. Unverified PCs & Servers

8. Catch-all IoT

9. Catch-all Mobile

Rogue and Unverified Device Remediation

Route Unverified devices back to your inventory tools for reconciliation, and escalate true Rogue devices to the security team for removal.

Site Label Descriptions and Tags

Apply descriptions and tags to Site Labels in the Virtual Edge and Site Label settings pages. It is a small amount of work at deployment time that pays off twice: in troubleshooting and site filtering, and on the dashboard, where administrators can view device summaries by total enterprise, by individual site, or by tag (site type).

Optimizing After the Initial Build

The initial Policy Group and policy build is not the finish line. Five areas repay attention once the first pass is in place:

Blocking to the Internet

Where possible, block Policy-Group-to-Internet traffic. Where a group genuinely needs outbound access, save a custom Security Profile that blocks everything except the required services rather than allowing the group wholesale.

Blocking to Unassigned

Unclassified describes a missing or unknown device attribute, such as vendor, type, category, model, or operating system. Unassigned describes an asset that does not match any Dynamic or Static Policy Group under the criteria configured in Cloud Control Center. Unassigned assets remain in the Policy Matrix and can receive Security Profiles and policy decisions like other Policy Groups. During early rollout, choose Allow or Deny for the Unassigned Policy Group deliberately, based on deployment maturity and confidence in device classification.

Server and application granularization

Servers start life in large Verified and Unverified groups. Split out, in roughly this order: local servers with a known role (printer, NVR, and similar); centralized management and jump servers that specific device groups need to reach; and branch-to-datacenter application paths, where a datacenter hosts common apps and services that regional or local devices consume.

Additional static, subnet-based use cases

Beyond the baseline static groups, common additions are internal public IP space, client VPN, DNS and DHCP services, network management, and other critical services.

Scale rationalization

As the global rollout completes, re-review actual versus estimated scale across devices per site, sites per Distribution Zone, switch counts and types, Policy Groups, Policy Sets, and policies. This is also the point to revisit Distribution Zone and ITD design against what the estate actually turned out to be.

Support & Customer Experience

Deployment is a joint effort. This section sets out what Elisity Support covers, where the Customer Experience (CX) team engages, and what stays with the customer.

What 24/7 Premium Support Includes

• Proactive infrastructure-connectivity monitoring and customer alerting: Elisity watches the connectivity underpinning your deployment and raises the alert rather than waiting for a ticket.

• Reactive troubleshooting for connectivity, Virtual Edge / Virtual Edge Node, connector and access issues.

• Scheduled availability for remote assistance with site deployments or network changes.

• Support ticket summaries, metrics and trends included in executive business reviews.

Where Customer Experience Engages

CX engagement concentrates in three areas.

Site preparation and readiness

Finalizing the master list of site types and counts; infrastructure readiness (switch counts and models, software versions, licensing); site prioritization by risk profile, tier and size; the number of endpoints per site; Distribution Zone mapping; the Virtual Edge type for each site; and a high-level design per site type.

Policy preparation and activation standards

Global CCC configuration; the device-visibility strategy and connector ecosystem, current and future, including which fields will drive Policy Groups; nomenclature standards for labels and Policy Groups (global or local, default or custom); custom Policy Group creation and the label-import framework for servers and IoMT; the process for activating policies through learning, simulation and enforcement; the methodology for evolving Policy Groups and policies as granularity grows; and the move / add / change process.

Support and operations workflows

Building the ongoing operational workflows: connector integration, RBAC profiles and SSO, initial Policy Groups with Security Levels, custom Security Profiles and Policy Sets, baseline Policy Groups into simulation, and planning for ongoing monitoring. Customers using the Elisity APIs for custom external dashboards or import/export automation are supported here too.

What the Customer Owns

These responsibilities cannot be delegated to Elisity, and deployments slow down when they are unassigned:

• A core team covering security strategy and site deployment.

• A project management function.

• Access to data and to the customer directory.

• An understanding of existing systems, ecosystems and the overall security strategy.

• Validation of preparation decisions.

• The authority, planning and mechanisms to create change windows.

• Internal-communications authority.

• An explicit decision on who is responsible for deploying sites, executing custom Policy Groups, and activating and enforcing policies.

• Documentation of all decisions and processes: RACSI matrices, run books, site priority lists.