Identity-based microsegmentation, taught in 12 modules. Each module has objectives, content, a Highlights card, cited references, and a self-check. An offline mirror of every sourced page is in elisity-mirror/.
Sourcing: mechanics are grounded in Elisity docs + Cisco TrustSec references. Percentage/performance figures (65% fewer firewall licenses, 85% less lateral-movement risk, etc.) are Elisity marketing claims — present them as vendor claims.
▶ How to use: work top-to-bottom. Beginner = the mental model; Intermediate = architecture & mechanics; Advanced = scaling, integrations, deployment, competitive positioning, design. Do each module's self-check out loud before moving on.
M1Beginner The Problem: Why Microsegmentation Exists
Objectives: explain lateral movement, flat-network risk, and "east-west."
Network segmentation is the key to stopping lateral movement and east-west attacks.Image: Elisity ↗
Traditional security is a castle: hard perimeter, soft trusting interior. Once something's inside — a phished user, a vulnerable IoT device — it can reach almost anything. That sideways spread is lateral movement (east-west traffic).
North-south = in/out through the perimeter firewall.
East-west = device-to-device inside the LAN; perimeter firewalls barely see it.
This is how ransomware spreads: infect one host, move laterally to servers, backups, domain controllers. A flat network turns one infection into an enterprise outage. Microsegmentation divides the interior into per-role zones with least-privilege rules between them, containing the blast radius.
Highlights
Perimeter = hard shell, soft center; once inside, attackers move east-west.
Lateral movement turns one infection into a full breach (ransomware).
Microsegmentation contains the blast radius with least-privilege rules between devices.
Self-check: explain lateral movement with the "locked doors between rooms" analogy.
M2Beginner What Elisity Is (The One-Breath Model)
Objectives: one-sentence definition; the brain-vs-muscle separation.
Elisity delivers identity-based microsegmentation for OT/IoT/IoMT with Zero Trust - on existing infrastructure.Image: Elisity ↗
One sentence: Elisity is a cloud-managed, identity-based microsegmentation platform that stops lateral movement by pushing policy onto the switches you already own — with no new hardware, no agents, no VLAN/IP redesign.
Brain (cloud): the Cloud Control Center — see everything, author policy. Out-of-band (not in the traffic path).
Muscle (switches): access switches enforce at the port closest to each device.
The differentiator: policy = WHO/WHAT a device is (identity), not WHERE it sits (IP/subnet). So moving or re-IPing a device doesn't break its policy.
Highlights
Cloud-managed · identity-based · agentless · runs on existing switches.
Self-check: one-sentence pitch + brain/muscle model in under 30 seconds.
M3Beginner Core Concepts: Identity & Zero Trust East-West
Objectives: identity-as-perimeter; Zero Trust applied east-west.
Microsegmentation and Zero Trust - the identity-as-perimeter shift (David Holmes, ex-Forrester).Image: Elisity ↗
Zero Trust = never trust/always verify, least privilege, assume breach. Elisity applies it inside the LAN — least privilege between devices, continuously. Identity is the new perimeter: "this camera → the camera server, nothing else," not "this IP → that subnet."
Versus VLANs (segment by location — coarse, IP-based, break when things move): Elisity segments by identity, and policy travels with the device.
Highlights
Elisity = Zero Trust applied east-west.
VLANs segment by location; Elisity segments by identity — same device, same rule, anywhere.
Identity is learned (traffic + integrations), not assigned by where you plug in.
Translator — learns identity from flows; converts cloud policy to switch-native; controls many switches
Distribution
Virtual Edge Nodes (VENs)
Muscle — the onboarded switches (Cisco C9000, Arista, Juniper, Aruba) that enforce
Enforcement (inline)
IdentityGraph™
Real-time correlated map of every user/workload/device
Visibility
Data flow: Virtual Edge gleans identity from flows → up to Cloud Control Center, correlated in IdentityGraph → admin authors policy → distributed back down over a secure channel → Virtual Edge translates & enforces on VENs, switch-native, closest to the endpoint. Virtual Edge runs as a VM or on the switch itself.
Highlights
Four parts: Control Center (brain), Virtual Edge (translator), VENs = switches (muscle), IdentityGraph (map).
Cloud is out-of-band; enforcement is on the existing access switch.
One Virtual Edge → many VENs; runs as VM or on-switch.
Self-check: draw the four components + arrows from memory.
M5Intermediate How Enforcement Works (TrustSec / SGT / SGACL)
Objectives: exactly what's programmed on a Cisco switch; why no added latency.
Cisco enforcement path: an IP-to-SGT binding tags the device, an SGACL permits/denies tag-to-tag, programmed into TCAM at line rate.Image: Cisco TrustSec ↗
Elisity programs the switch's own Cisco TrustSec constructs. Three things land on a Cisco VEN:
Programmed into TCAM, enforced in hardware at line rate. The Virtual Edge Nodes "don't process or intercept packets" — the existing switch does. No added latency, no new chokepoint.
Highlights
Cisco enforcement = IP-to-SGT bindings + SGACLs + CTS, in TCAM, at line rate.
Rules are tag-to-tag (identity), not IP-to-IP → portable policy.
Elisity ≈ automated, cloud-native TrustSec (the ISE classification/SGACL work, automated).
Vendor-agnostic: Cisco = TrustSec; Arista/Juniper/Aruba use native equivalents.
Self-check: narrate the full six-step flow, ending at SGACLs in hardware.
M7Advanced Scaling & Distribution Zones (TCAM Exhaustion)
Objectives: the TCAM/IP-SGT ceiling; how Distribution Zones prevent exhaustion.
Modern defensible architecture for OT - scaling segmentation across the estate.Image: Elisity ↗
A Catalyst 9K holds ~10,000 IP-SGT mappings in TCAM. Push every binding to every switch and the table overflows — policy silently stops programming. Distribution Zones scope where policy data goes:
Local: bulky dynamic IP-to-Tag mappings go only to the zone that needs them — enforcement close to the source; each switch carries only its zone's bindings.
Global: compact static / subnet-based rules (one line covers a subnet) go everywhere cheaply.
Sizing: Access DZ (C9300) ~9,000 devices; IE3400/C9200 ~1,000; Core DZ (C9500/9600) ~200,000 tag bindings. Mental model: OSPF areas for identity — localize high-volume state, flood only the small summary.
Highlights
Catalyst 9K cap ≈ 10,000 IP-SGT mappings → TCAM is the constraint.
Dynamic bindings stay local; compact subnet rules go global. No TCAM overrun.
Self-check: map Elisity's components to NIST 800-207 PDP/PEP.
M12Advanced Design & Consulting: Segmenting a Real Environment
Objectives: turn knowledge into an architecture recommendation + phased rollout.
Compliance-driven design - e.g. a PCI-DSS cardholder-data environment.Image: Elisity ↗
Discovery first (before naming a product): what are we protecting + compliance; existing stack (switching, IdP, SIEM/EDR, NAC/ISE, cloud); device reality (managed vs IoT/OT/IoMT — the decisive agent-vs-agentless question); ops maturity/day-2; budget/timeline/downtime.
Method: visibility first → classify by identity/role → policy in business terms → monitor before enforce → enforce crown-jewels first → operationalize.
Worked example — hospital: guest = internet-only, off the LAN; PoS = isolated PCI-DSS zone; IT = corporate; clinical/IoMT = crown jewel, agentless-enforced. Rollout: monitor everywhere → guest → PoS → IT → clinical/IoMT last (life-safety; longest observation + tested rollback). Justify by risk vs disruption.
Highlights
Discovery before product; the device/agent-tolerance question drives the vendor.
Offline mirror: ~410 pages (~100 blog posts + ~139 support/doc articles + product pages, 32 MB) saved in elisity-mirror/ — open index.html to browse, or manifest.csv for the full list. Includes the support/documentation articles that are bot-blocked from normal fetching.
