A legacy PLC accepts any connection on its open port. It has no concept of users, roles, or sessions. It cannot log who accessed it or when. It transmits in plaintext. It was designed this way because when it was built, the network it ran on was physically isolated. That assumption no longer holds.
The lollipop architecture solves this by placing an identity-aware proxy in front of each PLC. The proxy handles everything the PLC cannot: authentication, authorization, logging, and encryption. The PLC continues operating exactly as before. It does not know the proxy exists.
What the Lollipop Looks Like
Imagine each OT asset as a piece of candy on a stick. The candy is the asset (PLC, CNC, HMI). The stick is the single enforced path through the proxy. There are no other paths. No lateral connections between assets. No direct access from the network.
The diagram traces a single east-west session from SERVER A in the IT zone (subnet 10.0.1.0/24) to a PLC in the OT zone (subnet 10.0.2.0/24). The flow does not cross the core bus directly — it is redirected up through the Access Gate, where identity, role, protocol, and time-window policies are evaluated. Only then does the connection descend into the OT zone and reach the PLC. The other assets in each zone (Server B, the workstation, the HMI, SCADA, RTU) share the same fabric but remain unreachable from the IT side unless a policy explicitly creates a path. The Edge Gateway and Internet upstream are shown for context; they are not part of the enforcement decision.
Every connection to the PLC must:
- Authenticate the connecting principal — MFA at the proxy for human users (password + TOTP, FIDO2, or badge); a degraded but auditable credential for machine-to-machine sessions (mutual TLS certificate, scoped API key, or service-account credential)
- Verify authorization (role, asset, protocol, time window)
- Establish a logged session (user or service identity, timestamp, payload)
- Encrypt the user-to-proxy segment (TLS)
The proxy-to-PLC segment runs the native industrial protocol (Modbus, EtherNet/IP, OPC UA). The PLC sees exactly what it expects. No protocol translation. No firmware changes.
How It Deploys
The Access Gate appliance or VM connects adjacent to the existing network. It does not sit inline with production traffic. It creates an overlay network using the 100.64.0.0/16 address space.
For each OT asset, the Access Gate creates a proxy endpoint. The overlay routes all traffic to that asset through its proxy. The original IP address and switch configuration remain unchanged.
Deployment takes hours, not weeks. Connect the appliance, discover assets, define policies, enforce. No VLAN reconfiguration. No recabling. No IP changes. No production downtime.
What the Proxy Enforces
Identity Verification
Before any session reaches the PLC, the connecting principal must authenticate through the Access Gate identity gateway. Human users authenticate with username, password, and a second factor (TOTP, FIDO2, or badge). Service accounts and machine-to-machine flows authenticate with a mutual TLS certificate or a scoped service-account credential bound to a named identity. The PLC never sees unauthenticated traffic.
Role-Based Access Control
Not every user should reach every PLC. An OEM vendor gets access to the specific CNC they are servicing, on the specific protocol they need, during the specific maintenance window. An operator gets access to the HMI, not the PLC behind it. Policies define who can access what.
Session Logging
Every connection is logged with: user identity, source IP, destination asset, protocol, command payload, timestamp, and session duration. This is the audit trail that CMMC AU 3.3.1 requires and that the PLC cannot generate on its own.
Deny by Default
If there is no policy allowing a connection, the connection is dropped and logged. This inverts the flat network model where everything can reach everything. With the lollipop architecture, nothing reaches anything unless explicitly authorized.
Encryption
The segment between the user and the proxy is encrypted with TLS. The segment between the proxy and the PLC runs the native protocol in plaintext, but this segment is isolated within a micro-DMZ with no external egress. CUI in transit is protected.
Why "Lollipop" and Not "Hub and Spoke"
Hub-and-spoke implies lateral paths between spokes through the hub. The lollipop model is stricter. Each asset has exactly one enforced path. There is no connectivity between assets unless a policy explicitly creates it. This eliminates lateral movement by design.
If an attacker compromises one PLC (through physical access or a zero-day in the protocol), they cannot reach any other asset. The overlay topology blocks all lateral paths. The attacker is contained in a segment of one.
Where This Fits in Compliance
| Framework | Requirement | Lollipop Addresses |
|---|---|---|
| CMMC | Access Control (AC) | Identity-based authorization per session |
| CMMC | Audit Logging (AU) | Session logging with user identity |
| CMMC | Encryption (SC) | TLS on CUI paths |
| NIS2 | Network Segmentation | Microsegmentation per asset |
| IEC 62443 | Zone and Conduit | Each proxy is a conduit boundary |
The Industrial DMZ Design Patterns whitepaper covers the four architecture patterns in detail, including the lollipop (inline mediation) model.
For more Zero Trust OT resources, architecture guides, and comparisons, visit the Zero Trust for OT Networks hub.
