Standalone L2Proxy Deployment and Operations¶
Standalone Deployment and Operations is the operational control plane for industrial inspection and enforcement. It allows the customer to create and operate multiple independent L2Proxy protection services, each with its own approved policy, protected access path, inspection mode, event handling, and operating lifecycle.
Figure — Standalone L2Proxy operations on the industrial network path.
Customer outcome: protection is deployed as a set of clearly owned industrial services—not as one shared configuration that must serve every user, plant area, and operational purpose.
Purpose and expected outcome
This section covers independently operated L2Proxy services. After reading it, the customer should understand when standalone deployment is appropriate, how Policy and Service Profiles differ, how multiple instances are operated, and how activation, health, evidence, rollback, and ownership are managed.
This chapter covers independently executed L2Proxy services. Identity-aware enforcement inside authenticated VPN sessions is the separate L2Proxy Connect deployment model.
From an approved profile to active protection¶
Approved Policy Profile
↓
L2Proxy Service Profile
↓
Protected industrial access path
↓
Independent L2Proxy instance
↓
Inspect → Record → Allow or Block
↓
Service health, logs, and industrial event evidence
The Policy Profile defines what is permitted. The Service Profile defines where and how that protection operates. The running L2Proxy instance performs the inspection and enforcement.
Complete management capability¶
| Management area | Delivered capability |
|---|---|
| Service inventory | View all saved profiles and the state of their independent instances |
| Profile creation | Create a new profile or use an existing profile as the starting point for another service |
| Profile maintenance | Inspect, edit, save, discard changes, and remove a stopped profile |
| Policy assignment | Select a Policy Profile created by the policy-management workflow |
| Activation | Start, stop, and restart each L2Proxy instance independently |
| Service visibility | See running or stopped state, service identity, activity duration, and operating summary |
| Local evidence | Open the log belonging to the selected service |
| Central evidence | Send detailed inspection and policy events to the event archive |
| Deployment choice | Select active enforcement, passive observation, or offline analysis per profile |
Industrial operating model¶
Independent service profiles can be aligned with the way the plant assigns ownership and risk:
- one remote vendor or maintenance user;
- one production cell or package unit;
- one feeder or substation function;
- one critical transformer or generation intertie;
- one commissioning activity;
- one passive monitoring point;
- one offline validation or investigation task.
This makes it possible to change, stop, or restart one protection service without reconfiguring unrelated services.
Per-user standalone isolation¶
In the remote-access architecture, each authenticated VPN user is assigned an isolated access path. An independent L2Proxy instance runs on that path and loads the Policy Profile approved for the user.
The result is more precise than general remote connectivity: the customer can control which equipment the user may reach, which industrial operations may be performed, and which deviations must be blocked and recorded.
Where native user and session identity should enter the Rule Engine directly inside the virtual access path, use L2Proxy Connect instead. The standalone pattern remains useful when each user requires a separately operated bridge or routed service.
Operational safeguards¶
- Configuration changes are saved deliberately.
- Unsaved changes can be discarded.
- A running service cannot be removed accidentally.
- Each service has independent start, stop, restart, and log access.
- Policy selection is visible in the Service Profile.
- Managed Policy Profiles remain distinguishable from other rule files.
- Independent service state reduces the impact of a localized change.
Customer value¶
- Isolation: separate users and industrial purposes into independent enforcement services.
- Operational control: manage activation and service state without manually operating background processes.
- Policy traceability: retain an explicit relationship between the approved Policy Profile and the service that enforces it.
- Progressive adoption: use passive and offline modes before enabling inline blocking.
- Focused troubleshooting: inspect the state and log of one service without mixing evidence from unrelated paths.
- Scalable operations: add services without turning one central configuration into a growing shared risk.
Continue with Service Profiles.