User and Session-Aware Industrial Policy

L2Proxy Connect adds authenticated session identity to the normal L2Proxy rule context. A policy can therefore evaluate both the industrial operation and the person or session responsible for it.

Policy dimensions

Dimension	Representative decision
User	Is this the approved transformer vendor?
Session	Does this event belong to the authorized live work session?
Access domain	Is the session connected through the approved industrial access domain?
Session type	Is this an authenticated client session or infrastructure traffic?
Equipment	Is the destination TR1, F12, DER-5, or another approved asset?
Operation	Is this a read, Open, Close, reset, acknowledge, or setpoint request?
Process condition	Are mode, lockout, voltage, synchronization, range, and sequence requirements satisfied?
Outcome	Should the operation be recorded, accepted, or blocked?

Figure — User and session-aware policy is evaluated inside the authenticated industrial session.

Example: vendor read-only access

Requirement: a named vendor may diagnose one packaged unit but must not issue control operations.

The policy evaluates:

• the authenticated vendor identity;
• the current session;
• the assigned equipment;
• approved diagnostic reads;
• any attempted write or control;
• the required record or block outcome.

The user may remain connected while an unauthorized industrial command is blocked and recorded. If the behavior indicates misuse or compromise, the session can be disconnected through session management.

Example: user-specific breaker authority

Requirement: one protection engineer may inspect F12 relay and breaker state and perform approved controls; other remote users may only observe.

The industrial policy can combine:

Approved user
AND F12 equipment scope
AND approved command
AND Remote mode
AND no active lockout
AND approved control sequence

A failure in any required condition can produce a blocked, session-attributed event.

Session-aware multi-state control

Session identity can also become part of a stateful sequence. For example, an Operate request can be accepted only when the corresponding Select was issued by the same authenticated session and remains valid within the approved time window.

This helps prevent one session from consuming another session's authorization and makes replay or identity drift visible in the rule evidence.

Policy evidence

For a matching rule, the event can preserve:

• rule and policy identity;
• Accept or Drop decision;
• authenticated user;
• session identity;
• virtual access domain;
• session type;
• equipment and point;
• industrial operation and value;
• state-machine phase or prerequisite result;
• customer-selected dynamic metadata.

Next: In-Session Industrial Enforcement.