An encryption gateway audit log is the record a gateway keeps of its own cryptographic activity: tunnels opening and closing, key exchanges, rekeys, failures and configuration changes. In air-gapped OT networks these logs stay on site. They are often the only way to show an auditor that quantum-safe encryption is actually running and not just configured.
In critical infrastructure the encryption gateways are often designed so that no data leaves the site. That is good for security, but it creates an audit problem: no vendor dashboard and no cloud console can confirm the state of the control. This article explains how to build that evidence locally, how to get it out of an isolated network safely, and what European and international frameworks expect.
How do you prove to auditors that quantum-safe encryption is active when a gateway sends no telemetry?
You prove it by combining three things: configuration records, local event logs and independent observation of the traffic on the wire. Auditors want to see that the control was designed correctly, that it ran without interruption over the audit period, and that someone checked it.
Some gateways are built without any outbound reporting. The Quantum Gateway from Quantum Network, for example, sends no telemetry, has no cloud dependency, and combines a classical and an ML-KEM (FIPS 203) key agreement into one session key, with both handshakes renewed every two minutes. With a design like this, the organisation running the gateway has to produce all of the evidence itself. A practical evidence set has three parts:
Design evidence
Export the cryptographic configuration of the gateway after every change: algorithm settings, peer definitions, routes and software version. Calculate a hash of each export and store it with the change ticket. That gives the auditor a fixed reference point to compare the running state against.
Operating evidence
Local logs show that handshakes and rekeys kept happening at the expected rate throughout the period, and that every failure was followed by a recovery. A steady, unbroken series of successful rekeys is stronger evidence than any single screenshot.
Independent verification
From time to time, take a short packet capture on the WAN side of the gateway with a mirror port or tap. Then show that industrial protocols such as Modbus/TCP or DNP3 appear only on the protected side, never in cleartext on the transport path. Record who took the capture and when, and keep the analysis with the audit file.
Which encryption events should be logged locally in an air-gapped OT network?
Log every event that changes or confirms the cryptographic state of a connection, plus every change to who can alter that state. Do not log packet contents or key material.
Being selective matters. In NIST SP 800-92 Rev. 1, Karen Scarfone and Murugiah Souppaya warn that “Recording more log data is not necessarily better.” The draft asks organisations to determine whether the log source might intentionally or inadvertently capture sensitive data, including personal information, passwords, private keys, and access tokens. That revision replaces the original SP 800-92, Guide to Computer Security Log Management.
| Event category | What to record | Why auditors care |
|---|---|---|
| Tunnel establishment and teardown | Peer identity, timestamp, result, reason code | Shows when protection was in place on each path |
| Hybrid key exchange | Classical and post-quantum algorithm identifiers, success or failure | Shows that the quantum-safe part was actually negotiated |
| Rekey events | Timestamp, result, interval drift | Gaps or failures show where cryptographic protection may have weakened |
| Peer authentication failures | Source address, failure type | Points to misconfiguration or unauthorised connection attempts |
| Configuration and algorithm changes | Administrator, old and new value, change reference | Supports change control and crypto-agility decisions |
| Software and algorithm updates | Version before and after, method of installation | Shows the patch status of the cryptographic implementation |
| Logging service state and time sync | Start, stop, pause, clock source changes | A gap in logging is itself an audit finding |
The last row reflects a specific legal requirement. Implementing Regulation (EU) 2024/2690 lists the activation, stopping and pausing of the various logs among the items logs should include. In OT terms, IEC 62443-3-3 SR 2.8 (auditable events) sets the system-level expectation for generating audit records. NIST crosswalks group it with SR 2.9, SR 2.10, SR 2.11, SR 2.12, which cover audit storage, failure response, timestamps and non-repudiation.
How do you collect and export gateway logs from an offline network without creating a new attack path?
Collect logs inside the OT zone on a dedicated log server. Seal them with hashes as they are written. Export them only in one direction, so that nothing can come back into the network through the same path.
NIST asks organisations to determine how log data should or must be transferred to the log infrastructure, including out-of-band methods where appropriate. For air-gapped sites, three patterns are common:
| Export method | Strength | Controls required |
|---|---|---|
| Hardware-enforced one-way transfer | Return traffic is physically impossible | Fixed destination, format checks on the receiving side, monitoring of transfer gaps |
| Controlled removable media | Low cost, suits small sites | Registered media, scanning kiosk, two-person rule, hash verification at both ends |
| Write-once archive kept on site | No export at all, auditor reviews on site | Physical access control, redundant copies, documented retrieval procedure |
Whatever method you choose, calculate the integrity hash before the logs leave the source and check it again after transfer. ENISA’s draft guidance lists protection mechanisms including encryption and hashing, along with logging of all access and changes to log files. Keep the export station separate from engineering workstations. The log server should never need inbound connections from the IT side.
What does NIS2 require for logging and monitoring of cryptographic controls?
NIS2 Directive Article 21 requires risk-management measures that include policies on cryptography and encryption. Implementing Regulation (EU) 2024/2690 then turns this into concrete logging, monitoring and key-management requirements.
The Implementing Regulation lays down the technical and methodological requirements of the measures referred to in Article 21(2) of Directive (EU) 2022/2555. It applies directly to digital infrastructure and ICT service providers. Energy, transport and other OT-heavy sectors follow their national transposition, but ENISA notes its guidance may provide indications on the technical and the methodological requirements of the cybersecurity risk-management measures of NIS 2 Directive for other entities as well.
Three provisions matter most for encryption gateways:
- Logging scope: entities shall maintain, document, and review logs, and select the assets to log based on their risk assessment.
- Review and alarms: The logs shall be regularly reviewed for any unusual or unwanted trends. If the laid down values for alarm threshold are exceeded, an alarm shall be triggered, where appropriate, automatically.
- Key management: the cryptography requirements include logging and auditing of key management-related activities, which directly covers key exchange and rekey records.
On the ISO side, the ENISA draft maps these provisions to ISO 27001:2022 · A.5.28, A.8.15, A.8.16. ISO/IEC 27001:2022 Annex A 8.15 itself is about logging: maintaining and analysing logs of security-relevant activity. The SC 27 summary adds the protection obligation: We protect our logs from tampering.
The policy pressure is clear, but readiness lags. ENISA’s Executive Director Juhan Lepassaar said: “The implementation of NIS2 is a top priority for ENISA.” ENISA’s own survey data show where organisations currently stand:
- 70% of surveyed organisations name compliance as the main driver of cybersecurity investment (ENISA NIS Investments 2025, December 2025).
- 30% had not carried out a cybersecurity assessment in the previous 12 months (ENISA NIS Investments 2025, December 2025).
- 4% had already invested in quantum-safe cryptography, and 68% said they will not invest (ENISA NIS Investments 2024, November 2024).
Taken together, these figures suggest that many auditors will be seeing post-quantum key exchange for the first time. Clear logs that label each algorithm make their job easier.
How long should key-exchange and rekey logs be kept for critical infrastructure audits?
No single legal number applies. Set the period yourself from your risk assessment, your audit cycle and national law, document it, and make sure backup copies are kept at least as long as your review period.
The Regulation says entities shall maintain and back up logs for a predefined period and shall protect them from unauthorised access or changes. ENISA adds that the backup logs’ maintenance period shouldn’t be shorter than the logs’ review period. It also advises: Delete data when the retention period ends.
To decide on a period that holds up in an audit, work through these questions:
- Audit horizon: keep rekey logs for at least the full period an auditor can examine. For an ISO/IEC 27001 certificate, that usually means the whole certification cycle, including surveillance audits.
- Incident investigation: keep tunnel and handshake logs long enough to rebuild events after a slow-moving incident is discovered.
- Volume tiering: short rekey intervals produce many routine success events. Keep the full detail for a shorter period and store daily summaries (counts, failures, gaps) for longer. Keep failures, configuration changes and algorithm changes for the longest period.
- Sector rules: check your national competent authority and sector regulator. Transposition laws can add retention periods on top of NIS2.
Finally, link retention to your list of logged assets. The Regulation requires that the procedures as well as the list of assets that are being logged shall be reviewed and, where appropriate, updated at regular intervals and after significant incidents. Every new gateway, cloud endpoint or remote-access client should be added to that list on the day it goes live.
Where Quantum Network fits
Quantum Network is a quantum-safe encryption gateway that protects the connections between your own locations, without replacing the network equipment you already run.