Remote Access — Frequently Asked Questions
Mirox gives you two ways to reach the devices on a plant network from anywhere: the VPN, a full network connection for any protocol, and the Browser Proxy, a browser-only path to a device's web interface. This page answers the security questions both raise — who can connect, how access is granted and taken away, what is recorded, and how the service stays available. The short version: remote access is a deliberately tiered, least-privilege capability, every connection is attributed to a named person and logged for compliance, and your plant network never has to expose an inbound port. For the full feature descriptions see VPN and Proxy; for the audit detail see Access Audit Logging.
Choosing Between the VPN and the Proxy
1. What is the difference between the VPN and the Browser Proxy?
They reach plant devices at two different levels. The VPN gives your computer a real network connection into the plant networks you are authorized for — any protocol works (a device's web UI, SSH, Modbus, SNMP, or your own engineering tools), which is powerful but means it is the most privileged form of access. The Browser Proxy is the deliberately narrower, more controlled option: it opens a specific device's HTTP or HTTPS web interface directly in your browser with no client to install, and it can reach only the web targets that have been configured for a device — never arbitrary addresses and ports on the plant LAN. Choose the Proxy for everyday browser tasks; choose the VPN when you genuinely need a network-level connection.
2. Which one should I use, and why are they restricted differently?
Use the Proxy when the task lives in a browser — checking an inverter portal, a datalogger UI, a switch's web admin. Use the VPN when you need a non-web protocol or your own tools talking directly to devices. Both are reserved for the plant's technical roles — Operator and Technical Manager — and both are granted per plant, never platform-wide. What differs is the blast radius, not the audience: the Proxy can only ever reach pre-approved device web pages, while the VPN opens a real network path, which is why every VPN session is routed, rate-limited and audited at the network level. Granting the reach plant by plant, and only to the people who carry technical responsibility for that plant, is the core of the least-privilege design. There is one more audience, narrower than either: a Security Officer reaches both paths as well, but only inside the network segments it was granted — see Network Segmentation.
VPN — Access and Permissions
3. Who can connect to my plant's network via VPN?
VPN connectivity is granted to the plant's technical roles — Technical Manager and Operator — and it is decided per plant, so a route exists only for the specific plants a person is technically responsible for. Someone reaches that level in one of three ways: a direct Technical Manager or Operator grant on the specific plant or portfolio, inheritance through an organization role (Administrator and Moderator map to Operator, Asset Manager (Technical) maps to Technical Manager, on their own organization's plants), or through a cooperation that grants one of those jobs on a shared plant. Everyone else — Asset Manager (Commercial), Viewer, plain members and guests — receives no VPN route at all. The commercial and read-only side of the platform never gets a raw network tunnel into a plant. A Security Officer also receives a VPN route, and it is the narrowest one the platform issues: only the subnets tagged as the segments that role was granted, never the rest of the plant and never a plant-control network.
This answer covers the personal VPN. The plant-level infrastructure tunnels — direct plant VPNs and organization VPN services — are configured separately by an organization Moderator or Admin and carry the plant's own monitoring and team traffic rather than an individual person's access.
4. Can I give someone VPN access to a single plant only?
Yes — that is the normal case. The check runs per plant, so you grant the Technical Manager job on exactly the plant (or the portfolio) that person is responsible for, and their VPN profile routes those subnets and nothing else. A technical operations manager looking after three of your twenty plants reaches three plant networks; the other seventeen are not merely hidden, they are never routed for that person. Keep in mind that an organization role sets a default job on every plant of the organization — someone who should reach only selected plants should hold an organization role that grants no VPN by itself (Member or External), with the Technical Manager job granted per plant on top. External people get the same treatment through a cooperation. See the Permission System for the complete role-to-job mapping.
5. Can an external technician get access to one of my plants?
Yes — through a cooperation — and under exactly the same rules as your own staff. VPN access still requires the cooperation to grant the external person the Technical Manager or Operator job on the shared plant, and it opens only that plant's networks; Proxy access follows the same technical roles. No cooperation can hand out more than you choose to share, every connection the external technician makes is recorded in your plant's access audit log just like an internal one, and you can lower or revoke the cooperation at any time, which removes their access — normally within seconds, and never later than the 10-minute synchronization cycle described in question 9.
VPN — Profiles, Keys and Routing
6. Why does every person get their own VPN profile instead of a shared one?
A personal profile is what makes accountability possible. Because each connection is tied to a named Mirox account, the compliance audit log can answer "who connected" for every session — a shared key would make that impossible. A personal profile also lets each user rotate or revoke their own keys independently without disrupting anyone else, and it keeps key custody on the user's side: the private key is generated on the user's own device and is never stored by Mirox. The configuration is shown only once when you create or rotate it; if you lose it, you simply rotate to get a new one.
7. What encryption does the VPN use?
The personal VPN uses WireGuard with modern cryptography: Curve25519 key exchange and authenticated encryption. Your private key is generated on your own device and never leaves it — Mirox only ever sees your public key. The tunnel is a split tunnel: only traffic destined for private plant networks enters it, while your ordinary internet traffic (web, email, video calls) stays on your own connection and never passes through Mirox. See the personal VPN setup guide for how to issue and import your profile.
8. How do new plants appear in my VPN without re-downloading anything?
Your configuration file is fixed for the lifetime of your profile — you never re-import it when your access changes. The part that moves is maintained on the Mirox side: the set of plant subnets your profile is allowed to reach is computed from your current permissions and kept in sync continuously. The moment you are granted Technical Manager or Operator access to a new plant, that plant's networks become reachable through your existing tunnel — typically within seconds, and at the latest within 10 minutes (see question 9) — with no reinstall and no action on your part. The Refresh button on your profile's VPN tab recomputes your routes on the spot if you do not want to wait. A plant whose agent is not yet deployed shows as "not yet reachable" and goes live automatically once its agent is online.
VPN — Revocation and Isolation
9. How is access taken away — and how fast?
When your technical role on a plant ends — because your job is removed or lowered, your organization membership changes, or a cooperation is lowered or ended — the affected plant is removed from your reachable routes and the network path into it is torn down. Usually this happens within seconds; the guaranteed upper bound is 10 minutes.
Both numbers are real, and the reason for the gap between them is deliberate. Most permission changes trigger an immediate recomputation of the affected profiles. Some changes fan out too widely to handle that way — lowering a cooperation role can affect every user on both sides of that cooperation at once — so rather than chase every conceivable path with an immediate recomputation, a background synchronization runs continuously and re-verifies every active profile against current permissions on a 10-minute cycle, removing any route that should no longer exist. That makes the upper bound a property of the system rather than of any single code path: a missed or unhandled event cannot leave a route in place beyond one cycle.
The same permission change also withdraws your Proxy access. If your user account is deleted, your remote access stops under the same rule, while the compliance history you generated is preserved for the legal retention period.
10. How are different plants and organizations isolated from each other?
Each user's connection is confined to an isolated set of routes derived solely from the plants that user holds a qualifying technical role on, plus any explicitly invited cooperation scope. Subnets you are not authorized for are simply never routed for you — there is no network path from your tunnel to another organization's plant networks, and one organization's users cannot see another's. Reachability is permission-derived end to end, so isolation is enforced by what is routed, not merely by what is shown in the interface.
11. What happens when two plants use the same internal IP range?
This is handled explicitly. If two plants you can reach both use the same local range (for example two plants on 192.168.1.0/24), the system detects the overlap and marks it in your route list rather than guessing. You decide which of the conflicting plants takes priority for you, so there is never any ambiguity about which network you are reaching — the Use this park switch on the conflicting route swaps the priority at any time, so you can reach the two plants one after the other.
The Browser Proxy
12. Who can use the Proxy?
The Proxy is open to Operator and Technical Manager on the plant — including the organization Administrators and Moderators that map to those jobs, and cooperation members holding them. Viewers are denied. That is the same technical audience as the VPN, and for the same reason: both are paths to live plant equipment, so both stay with the people who carry technical responsibility for that specific plant. The Proxy is the narrower of the two — it can only ever reach pre-approved device web interfaces, never the plant network itself, and every single request is permission-checked and audited. Configuring which device web pages exist as targets is itself a Technical-Manager-and-above action. A Security Officer may also open the Proxy, restricted to devices inside its granted segments — and only to use the targets that exist: defining or re-pointing a web target stays with Operator and Technical Manager, because aiming a target is how you would reach a network you were never given.
13. Does the Proxy require two-factor authentication?
Yes. Opening a device through the Proxy requires two-factor authentication (2FA) on your account (an authenticator app or a passkey) and a live Mirox sign-in that completed the second step; without 2FA the Proxy refuses to open a device, no matter your role. Proxy access also ends with the sign-in: when you sign out, or your sign-in ends or is signed out somewhere else, the Proxy closes with it (see question 24). By default this is stricter than the rest of the platform, where 2FA is optional unless an organization requires it for its plants — the Proxy always asks for it, because it is a path to live equipment. On top of your Mirox sign-in and 2FA, the device itself can require its own login, so there are often two independent authentication layers protecting a device.
14. Are my device passwords stored, and who can see them?
Device credentials you save for the Proxy (and for device connection checks) are held in an encrypted credential vault, and access to enter or use them is gated to Operator and Technical Manager on the plant. They are never exposed to other roles, never shown to the AI assistant, and never written into logs. The Proxy handles only the transport and the Mirox-side access control; the device's own authentication remains in force. A Security Officer holds the web-UI credentials of the network devices in its own segments — a camera's admin password, for instance — and never the data-logger secrets, which stay with Operator and Technical Manager.
15. Can someone get in if I share a proxy link?
No — a proxy URL is not an access grant. The address for a device's proxied web interface is stable and shareable, but anyone who opens it still has to sign in to Mirox themselves, have two-factor authentication on their own account, and hold the required role on that plant. A link on its own reaches nothing; these checks happen on every request.
Availability and Resilience
16. How robust is remote access — what happens if a server or a region fails?
The platform runs across multiple independent European data-center regions at the same time, each running the complete stack, and within each region remote access is served by multiple servers — so there is no single point of failure. Your connection always attaches to a healthy entry point; if one becomes unavailable, it is re-established automatically against another healthy server, and you do not have to reconfigure anything. Combined with automatic supervision of the plant agents, the architecture is engineered to deliver high availability.
17. What keeps the plant side available?
Each plant's agent is supervised by an orchestration layer that continuously verifies both its existence and its readiness on a short cycle. If an agent is missing, stops responding, or its host fails, it is automatically restarted, redeployed, or relocated to another healthy host — without a site visit. A safeguard ensures the same agent is never run in two places at once. Because the agent is what terminates the plant-side connection for both the VPN and the Proxy, this supervision is what keeps your plant reachable.
18. Does my plant network need an open inbound port?
The agent does not run inside your plant network — it runs in the Mirox cloud and reaches the plant through a dedicated VPN tunnel. You choose the direction of that tunnel: either your plant router dials out to the agent's VPN endpoint, in which case your firewall needs outbound connectivity only, or the agent dials in to a VPN server your router already runs. In both cases only the tunnel endpoint is involved — no device inside the plant is exposed to the internet, and nothing other than the plant's own agent can initiate traffic toward your plant network. This holds for both the VPN and the Proxy.
19. Is the agent the only way into my plant network?
Yes. The plant network becomes reachable over the platform only while the agent's tunnel to the plant is up, and all authorized traffic — VPN or Proxy — reaches the plant through that agent. It is the single point of entry, and it is bounded to its own plant: it cannot reach, and is not a path into, any other plant or network.
Audit and Privacy
20. Is every access recorded? Which standard does the log meet?
Yes — every VPN connection and every Proxy session is recorded automatically by the platform as traffic flows; users cannot influence what is captured. The access log is designed to meet German KRITIS and EU NIS2 remote-access logging requirements. For each access it records who connected, when, and from where (source IP and geographic region), which plant subnets and devices were reached, and which protocols and ports; for the Proxy it additionally records the web-request activity (the device reached, request counts and methods, data volume). Records are retained for 730 days (24 months) by default and then automatically purged. The depth of this audit is covered in full on the Access Audit Logging page.
21. Who can see the access log? Can I see my own connections?
The full plant access log is visible only to that plant's responsible operators — Technical Manager level and above on the plant, including invited cooperation technicians. The connecting user does not see the operator's audit log; that surface is reserved for the party with the reporting obligation. You can, however, review your own connection history from your profile: when each session started, from which region and source IP, the approximate location, and how much data moved. Neither operators nor users can edit or delete audit records — see the audit log's retention and tamper-resistance section. A Security Officer sees the log too, filtered to the devices inside its granted segments: enough to account for its own work on the plant, and nothing about who reached the networks it was not given.
22. Does Mirox see the content of my sessions?
No. The audit records metadata — connections, endpoints, ports, protocols, timestamps and traffic volumes, plus which device web pages a Proxy session touched — not the content of what you do. VPN packet payloads, the bodies of web pages, keystrokes and screen recordings are deliberately not captured, because that would be both privacy-problematic and unnecessary for compliance reporting. The privacy boundary is described in detail in the Access Audit Logging privacy section.
Sign-In, Sessions and 2FA
23. Does the VPN depend on my Mirox sign-in or on 2FA?
No. The VPN is certificate-based: a tunnel is opened with your personal VPN certificate, not with your sign-in to the web app or the mobile app. Being signed out does not disconnect it, no code is asked for a VPN connection, and an organization's 2FA requirement does not change your certificate or your routes. What decides your routes is the technical role you hold on each plant (question 3). Because the certificate is the key, keep it safe and revoke it at once if a device is lost. See VPN.
24. What happens to my Proxy access when my Mirox sign-in ends?
It ends with the sign-in: the next request to the device is refused, and a live stream that is already open is closed within about a minute. The Proxy needs a live sign-in, and a sign-in does not last forever. Your organization sets how long it lasts; without its own rule the Mirox default is one year in the web app. If your organization has set a 2FA re-check interval, an account with 2FA (authenticator app or passkey) is additionally asked to sign in again a set time after it last proved its second factor. The same happens when you sign out, when the session is signed out from the sessions list in your profile, or after a password reset. Sign in again and open the device again. See Organization Security Policy.
25. An organization requires 2FA for its plants. What changes for remote access?
For the Proxy, little: it needs 2FA anyway. What changes is the plant itself. From the start date the organization set, a user without a second factor no longer sees that organization's plants in the web app and the mobile app — and with them the plants' device proxy — until they enable 2FA. Nobody is signed out, and the plants are back as soon as 2FA is enabled. The rule belongs to the organization that owns the plant, so it also applies to a cooperation partner's technicians on that plant. VPN connections are not affected (question 23), and alarm notifications are always delivered. See Organization Security Policy.
Related Features
- VPN — the personal tunnel that reaches every plant network you are authorized for
- Proxy — browser-based access to plant device web interfaces, no VPN client required
- Access Audit Logging — the KRITIS- and NIS2-aligned record of all VPN and Proxy access
- Permission System — the role-to-job mapping that decides who reaches which plants
- Personal VPN Setup — step-by-step guide to issuing, rotating, and using your VPN profile
- Organization Security Policy — how long a sign-in lasts and when an organization requires 2FA
- Account Security FAQ — common questions on sign-in, sessions, 2FA and the backup code