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.

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.

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.

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