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, two-factor authentication on their account 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 needs their own Mirox sign-in with two-factor authentication and the permission on the plant).
• 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)

You sign in to Mirox once; that sign-in covers all granted device UIs across all plants. Access through the Proxy lasts only as long as the sign-in does — see Authentication via the Mirox Account.

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 (they run as long as your sign-in does)
• 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 live Mirox sign-in. A browser that is not signed in is sent to the regular Mirox sign-in page and, after signing in, is forwarded to the requested device.

Proxy access ends with the sign-in. When you sign out, when the sign-in reaches its end, or when the session is signed out somewhere else (from the sessions list in your profile, or by a password reset), the Proxy closes for that browser: the next request is refused, and a live stream that is already open is closed within about a minute. Sign in again to continue. How long a sign-in lasts is set by your organization — see Organization Security Policy.

Two-Factor Authentication Required

Opening a device through the Proxy requires two-factor authentication (2FA) on your account, and the sign-in you are using must have completed the second step — the 6-digit code from your authenticator app, or your passkey. The Proxy checks this on every request: an account without 2FA is refused access to any device, even when its plant permissions would otherwise allow it. A path this close to the hardware always depends on a second factor, whatever your organization's own rules say.

If you remove your last second factor, proxy access closes until you set one up again. The same applies after signing in with your backup code, because using the backup code switches the authenticator app off — unless you also have a passkey. To enable 2FA, see Two-Factor Authentication.

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.

A Security Officer may also use the Proxy, limited to the devices in the network segments that role was granted — see Network Segmentation. A Security Officer uses the web targets that exist and cannot define or change them.

This is the same technical audience as the VPN, and both are granted plant by plant — the two paths to live plant equipment stay with the people who carry technical responsibility for that specific plant. What separates them is reach, not trust: the Proxy touches only the specific, individually toggled web interfaces a plant operator configured, never the plant network itself, and every single request is permission-checked and written to the access audit trail.

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
• Organization Security Policy — how long a sign-in lasts and when an organization requires 2FA
• Two-Factor Authentication — enable the second factor the Proxy needs
• Local Network Inspector — automatic discovery of new network devices
• Remote Access FAQ — common questions on VPN and Proxy access, security, and compliance
• Account Security FAQ — why you were signed out, why a device does not open, what the backup code does