Access Audit Logging

The Mirox platform maintains a continuous, tamper-resistant audit trail of every remote access to a plant's network devices — every VPN tunnel session (Layer 3/4) and every Proxy request (Layer 7, HTTP). This page describes exactly what is captured, how granular the detail goes, who is allowed to access it, and how long the data is retained.

The audit trail is what makes the platform's plant-device access compliant with the German KRITIS rules and the EU NIS2 directive. Those regulations dictate the minimum retention window and the categories of evidence the operator must be able to surface — but the audit log is, first and foremost, an access-tracking tool for the plant operator.

Why This Audit Logging Exists

KRITIS and NIS2 oblige operators of critical infrastructure (in our case the plant networks of solar parks, wind farms, and battery storage sites) to be able to answer the following questions for every remote access, completely and even months later:

Who reached the internal network of this plant?
When was the connection established — and for each connection: when was which subnet / which device first and last touched?
How much traffic was transferred during the connection?
Which specific device and which service was touched?
What was done there (at the HTTP layer: which URLs, which methods)?

The Mirox audit trail covers all of these questions and is designed for the plant operator as the party with the reporting obligation — not for the accessing user.

Two Access Paths, One Shared Audit

Both platform access mechanisms are merged into a unified access overview per plant:

Path	Captured layer	Which question does it answer?
VPN	Layer 3/4 (IP traffic)	"Who reached which subnet and which specific device from where — first when, last when, how much volume?"
Proxy	Layer 7 (HTTP)	"What did the user specifically do at the device — which URLs, which requests, how many requests, what duration?"

Both paths share the same identity basis (the user's Mirox account) and the same legal retention and access logic. From the plant operator's perspective there is one chronological access list per plant, in which both channels appear side by side and can be narrowed down as needed.

Capture Depth

The audit trail is organized in several detail layers. The deeper you drill into the hierarchy, the more granular the information becomes:

Layer 1: Certificate / Identity

The top layer captures, per VPN certificate, a snapshot of the user identity at issuance and rotation time:

Anonymized account name
Email address
Unique certificate identifier

Even if the user is later renamed, deleted, or the certificate is revoked, this identity is preserved.

Layer 2: Session

Each connection is tracked as a session. A session is a contiguous run of activity from the same certificate from the same source. Brief interruptions under ten minutes still count as the same session; longer pauses create a new session.

Per session we capture:

Who is connected (account and email snapshot at connection time — preserved even if the account is deleted later)
Connection time
Source IP address and geographical attribution (city, country)
Region and node that terminated the connection (for latency analysis)
Total data volume (inbound and outbound)

Layer 3: Subnet Volume (VPN Only)

Within a session we capture, per touched plant subnet:

Which park and which subnet was touched
Transferred data volume and packet count per session and subnet
Time of the first and last touch
Snapshots of the park and organization name in case the plant is later renamed or deleted

Noise such as DNS queries, mDNS multicast, ICMP pings, and port-scan-like behavior is filtered and/or rate-limited, so the audit trail only carries actual usage events.

Layer 4: Device Touches (VPN Only)

The finest VPN layer captures, per specific target device:

Device IP, protocol (TCP, UDP, ICMP, ICMPv6, SCTP) and port
The matched device from the plant inventory (name, type) — when registered
Time of the first touch within the session
Number of connection events in this session
Snapshots of all identifiers at the time of the first touch

Sub-threshold interactions (e.g. single TCP resets from misclicks) are conservatively captured, but recognisable as such.

Layer 4': HTTP Sessions (Proxy Only)

In parallel, the Proxy captures, per session at the HTTP layer:

Account and email of the accessing user
Which web target or default device access was used
Target device (name, IP) — with snapshot for later deletion or rename cases
Browser, operating system, public IP address, geographical location
Session start and end (session end: 10 minutes of inactivity)
Number of requests and their HTTP methods (e.g. {"GET": 42, "POST": 3, "PUT": 1})
Inbound and outbound data volume
A URL-based activity trace of the session (query strings are redacted, capped at the most recent activity within a fixed allowance)
An AI-generated short description of the session activity for fast triage. If the AI is unavailable at session close, the description is filled in later — it is not optional but a fixed part of every closed proxy session.

Maximum Possible Detail Depth

The maximum detail depth is therefore:

VPN access example:

"User X connected via VPN on 2026-05-13 at 13:44 from public IP 198.51.100.7 (region eu-central, Munich, DE), addressed subnet 10.90.69.0/24 of park 'Solar Park Annaburg' during this session (12 MB transferred, first touch 13:45, last 13:54), specifically touching device 'Inverter Block 3' (10.90.69.12, TCP/443) (first touch 13:45, 41 connections)."

Proxy access example:

"User Y accessed the web target 'Inverter Block 3 – Service UI' through the Proxy on 2026-05-13 between 13:46 and 13:55 from public IP 203.0.113.42 (region eu-central, Frankfurt, DE) on Mobile Safari 26.4 / iOS 18.7 (87 requests, of which 84 GET, 3 POST; 2.3 MB response volume, AI summary: 'Configuration change on the MPP tracker settings')."

Both VPN and Proxy capture the public source IP, the terminating region and the geographic attribution (city, country) of the connection. For the Proxy, browser and operating-system info additionally enter the audit trail (via the User-Agent sent by the browser), since these travel at the HTTP layer anyway. For pure VPN-based access (Layer 3/4) this application-client information is inherently not available — there the platform only sees the IP packet stream, not the application-level client.

A deeper detail level (packet contents, full HTTP bodies) is deliberately not captured, as this would be both privacy-problematic and operationally pointless.

Who Is Allowed to See the Audit?

Access to the audit trail is scoped by the job role a user holds on the plant:

Technical Manager or higher on the plant can view that plant's audit trail. In practice this means an Operator, Technical Manager, or Asset Manager on the plant. Admins and Moderators qualify automatically, because their organization role maps to a qualifying job on every plant of their organization (see the Permission System for the full role-to-job mapping).
Cooperators are included: a technician who reaches a plant through a cooperation with the required job role can also see the audit trail for that plant. Audit insight follows the same job-role gate as the rest of the plant's controls.
Viewers are denied. A Viewer (and anyone below the Technical Manager level) sees no audit trail. The frontend hides the access-log tab entirely for users below the threshold.

The platform exposes the audit view through a dedicated access-log API endpoint and a corresponding UI view. Editing or deleting audit records is not supported.

Retention Period and Tamper Resistance

At least 730 days retention for all audit layers (certificate, session, subnet volume, device touches, HTTP sessions). The retention period is aligned across layers so that cross-references between them always resolve within the full audit window.
Snapshot fields on every audit record (e.g. park name, device name, organization name, account, email) are write-once: they are stamped on first insert and never updated. This guarantees forensic identity even if the original record (user, plant, device) is later deleted or renamed.
Live resolution with fallback: As long as the referenced entities (user, park, organization, device) still exist, the audit view shows their current name (e.g. after the plant has been renamed). Once the entity is deleted, the view automatically falls back to the stamped snapshot. The audit trail thus stays readable — even months or years later, after personnel changes or plant sales.
No user-facing delete or edit paths: The audit tables cannot be modified through regular UI or API operations. They are only touched by automated audit events and by the nightly retention sweep after the 730 days expire.

Behavior Under Deletions

Event	Effect on the audit trail
User is deleted	Audit records are preserved. The view shows the account and email snapshot from the certificate or session.
Certificate is revoked	Audit records are preserved. The certificate is soft-revoked and stays available as a resolution source for 730 days.
Plant is deleted	Audit records are preserved. The view shows the park-name snapshot from the audit record.
Device is deleted / renamed / IP-changed	Audit records are preserved. The view shows the device-name snapshot; the IP in the record is the durable forensic identifier.
Organization is deleted	Audit records are preserved. The view shows the organization-name snapshot.

Protection Against Tampering With Audit Data

Sessions that cannot be attributed (e.g. because a header was stripped) are still captured with empty identity instead of being discarded. A later analysis can then specifically investigate these cases.
HTTP sessions are not closed by SaaS components alone but are closed and reported by the plant agent itself, so the SaaS platform cannot silently underreport request count or volume.
Sub-millisecond race conditions when reading counter chains are accepted as "lossy by design" and documented to be KRITIS-compliant; they can at worst affect a single counter cycle, never whole sessions or device touches.

Filtering and Searching in the Audit View

The audit view lets an authorized user narrow the result set:

By user account
By subnet or device IP
By protocol or port (VPN path)
By web target or specific device (proxy path)
By time range (from … to …)
Default sort by "last seen"

The default sort naturally groups by session, so the question "User X touched devices A and B in this session 18:43–19:00, and device C in a second session 13:44–14:30" is directly visible without further client-side grouping.

Privacy and Disclosure

What the audit trail contains:

Identity fields derived from the regular Mirox account (account, email)
Source IP addresses of the connection (legally required for KRITIS)
Geographical attribution of the source (city, country)
Data volume, request count, method distribution, timestamps

What the audit trail does not contain:

Contents of individual HTTP bodies
VPN packet contents
Keystrokes or screen recordings
Data not required for KRITIS / NIS2 reporting

What to Do for a Regulatory Request

For incident-driven information requests to the responsible authority (e.g. BSI under KRITIS), all necessary data is available within the 730-day window through the audit view. An export function (e.g. CSV) is planned as a separate, individually audited action and is provided on demand — such an export is itself an audit-worthy operation, so that it is documented who exported which audit data when ("audit of the audit").

VPN — personal tunnel with full Layer-3/4 audit capture
Proxy — browser-based access with full Layer-7 audit capture
Permission System — the role-to-job mapping that decides who can open the audit view
Cooperations — how a cooperating technician is granted (and audited for) plant access
Cooperation Restrictions — the limits that keep shared access within the owner's chosen scope