Proxy (Web Access to Plant Devices)

The Mirox platform's Proxy allows direct access to web interfaces of devices in the plant network — without a VPN client, without local installation, purely through the browser. Inverter configuration UIs, data-logger dashboards, camera UIs, switch-cabinet web pages, or self-hosted service tools become reachable through a unique Mirox URL — authenticated by the user's Mirox account and fully audited.

Concept

The Proxy closes the gap between the VPN and a classic cloud dashboard:

• No VPN needed: No VPN profile installation required. Any user with the proper role and a normal browser can open the device interfaces.
• Genuine device UI: The user sees and operates the unmodified original UI of the device, not a simplified Mirox-rendered version.
• Unique URL per device: Every reachable target has its own URL of the form <id>.proxy.mirox.io. This URL can be saved or shared (the recipient must in turn be authorized).
• Fully audited: Every call, every HTTP transaction, and every WebSocket connection feeds into a KRITIS / NIS2-compliant audit trail.

The Proxy is the deliberately more limited, more isolated, and more tightly controlled alternative to the VPN. It operates strictly at the application layer — HTTP, HTTPS, WebSockets, and Server-Sent Events only — and grants no network-level access to the plant: there is no IP route into the plant LAN, no reachable ports beyond the web interfaces, and no way to run arbitrary tools against the network. Only the web targets a plant operator has explicitly configured are reachable, and each one carries its own enable/disable switch, so reach is scoped target by target rather than to the network as a whole. Choose the Proxy when the task lives in a browser (opening an inverter or data-logger UI); choose the VPN when you need a real network connection for SSH, Modbus, or your own scripts across several plants.

What the Proxy Delivers

Direct Access to Device Web UIs

When a plant operator configures a web target for a network device, that target becomes reachable through a unique Mirox subdomain. The browser sees:

• A regular HTTPS connection to the Mirox domain with a valid wildcard certificate
• The unmodified content of the device (HTML, CSS, JavaScript, images, streams, file uploads, …)
• Full interactive functionality including forms, file downloads, and WebSocket streams (e.g. live consoles, video streams, real-time charts)

The user authenticates once with Mirox; the session remains valid for all granted device UIs across all plants.

Two Authentication Layers

Important: the Proxy only handles the transport and the Mirox-side access control to the device — the device itself can additionally require its own login (typically username/password, sometimes API keys or device-specific tokens). There are therefore two independent authentication layers:

1. Mirox authentication (enforced by the Proxy): Who is allowed to even open the device? Checked against the Mirox login and the plant permissions.
2. Device authentication (enforced by the device itself): Who is allowed to take which actions on the device? The device's login form simply appears in the browser; the user authenticates with the credentials provided by the manufacturer or plant operator.

Mirox records (see Audit Logging) who accessed which device and which pages — but authority over device-internal permissions (e.g. "maintenance mode", "configuration change") stays with the device's own login.

Secure Storage of Device Credentials

So that not every authorized staff member has to know the credentials of every device (and no one has to memorize a password personally or stash it in an unsafe tool), Mirox offers a central, encrypted credential vault. Plant operators can store the access credentials of their devices once, after which they are available to authorized users in a convenient form when they open the web target — without distributing the plaintext passwords.

Benefits:

• No distribution of plaintext passwords by email, chat, or sticky note.
• Auditable use: Who accessed what using stored credentials is captured in the KRITIS / NIS2 audit trail.
• Central rotation: When a device password changes, it is updated once in Mirox and is immediately effective for all authorized staff.
• Permission-bound: Access to stored credentials follows the same plant and job-role permissions as the device access itself.

Default Access and Additional Web Targets

For every network device the system discovers, the standard web port is auto-detected and made accessible without further configuration. Newly discovered devices can therefore be examined in the browser immediately, without the plant operator having to set anything up beforehand.

If a device has multiple relevant web interfaces (e.g. a service UI, a separate diagnostics dashboard, and a configuration page), the plant operator can define additional web targets. Each web target gets a meaningful name and its own Mirox URL, so that all interfaces are cleanly available side by side.

Every web target — including the default access — can be individually enabled or disabled by the plant operator. A disabled web target is no longer reachable through the proxy, while all other targets of the device and the plant continue to work. This makes proxy access controllable at fine granularity, without locking the whole plant.

Supported Protocols

• HTTP (all methods, including file uploads of arbitrary size)
• HTTPS endpoints (TLS terminates at the plant agent)
• WebSockets, fully bidirectional
• Server-Sent Events (SSE) and other long-running streams (no time limit on the overall session)
• File downloads (streaming, no size limit)

Resilient Error Messages

When something does not work, the proxy returns a clear error message with diagnostic info instead of an anonymous 502 page. The user can see, for example, whether

• the target device is not reachable,
• the plant's agent is not yet ready,
• the plant has no data-scraper agent installed,
• or whether a response actually came from the device itself.

This information is useful for troubleshooting without the user having to look at log files.

Security and Control

Authentication via the Mirox Account

The Proxy requires a valid Mirox cookie. Browsers that are not logged in are redirected to the regular Mirox login page and, after successful login, automatically forwarded to the requested device.

Two-Factor Authentication Required

Opening a device through the Proxy requires an active two-factor authentication (TOTP) setup on the account. The Proxy verifies this on every request: an account without 2FA enabled is refused access to any device, even when its plant permissions would otherwise allow it. This makes a hardware-near remote-access path conditional on a second authentication factor, not just a session cookie.

Per-Plant Permission Check

On every request the system checks whether the logged-in user has the necessary permission for this specific plant. The check honors the full permission system, including organization membership, cooperations, and job roles. Without the required permission, the user receives a 403 response.

Who May Use the Proxy

Proxy access to a plant is granted to the Operator and Technical Manager job roles on that plant — directly assigned, inherited by an organization's Administrators and Moderators through their role mapping, or held by a cooperation member carrying one of those jobs. Viewers and the commercial Asset Manager role are not granted Proxy access.

This is intentionally broader than the VPN, where network-level connectivity is reserved for the Operator role alone. The Proxy can be opened up to Technical Managers as well precisely because its blast radius is far smaller: it reaches only the specific, individually toggled web interfaces a plant operator configured, never the plant network itself. The narrower the reach, the wider the set of people who can safely be trusted with it.

Safe Redirect Handling

If the target device emits redirects of its own (e.g. after a login to a different internal URL), the proxy normalizes them so the browser never sees internal Mirox addresses or plant IPs. The URL stays consistently in the form <id>.proxy.mirox.io.

Diagnostic Endpoint for Connectivity Checks

A reserved diagnostic endpoint lets an operator verify that platform-side authentication and routing work correctly — without contacting any specific device. This makes it possible to tell apart platform problems from plant problems.

Audit and Compliance

Every call through the Proxy feeds into a KRITIS / NIS2-compliant audit trail at Layer 7 (HTTP). The audit trail captures:

• Who performed the session (account and email snapshot at session start)
• Which device and which web target were touched
• When the session started and ended
• Number of requests and the HTTP methods used
• Transferred data volume (inbound / outbound)
• The URLs actually called (query strings are redacted)
• Public IP address, location, and browser information of the user
• An AI-generated short description of the activity ("Configuration change on inverter", "Read access to diagnostics page" …). If the AI is unavailable at session close, the description is filled in later — it is a fixed part of every session, not optional.

A session is automatically closed when 10 minutes of inactivity have passed. Activity after that starts a new session.

The Proxy audit trail is presented in a unified access overview together with the VPN audit trail for the plant operator and is retained for at least 730 days. For details see Audit Logging.

Distinction From Related Features

Related Features

• VPN — personal tunnel for tools beyond the browser
• Access Audit Logging — unified access overview of all VPN and Proxy sessions
• Permission System — roles, job-level permissions and cooperations
• Local Network Inspector — automatic discovery of new network devices
• Remote Access FAQ — common questions on VPN and Proxy access, security, and compliance