Citrix vulnerabilities and the evidence question: can you show your logs haven't changed?

The vulnerabilities

On 9 September 2026, CERT-SE issued a warning about critical vulnerabilities in Citrix NetScaler ADC and Citrix NetScaler Gateway, components widely used for secure access and load balancing ^[1]. The vulnerabilities allow remote code execution and unauthorised access, meaning an attacker could gain control of the system without prior authentication.

Citrix has released patches and urged organisations to update immediately ^[1]. For those running these components, the first step is straightforward: patch and assess whether the vulnerabilities have been exploited in your environment.

The second step is harder. If logs are the record of what happened during an incident or an audit, how do you show they have not been altered, particularly if the vulnerability could have given an attacker the access needed to change them?

What DORA requires

DORA, the Digital Operational Resilience Act, has applied to financial firms across the EU since 17 January 2025 ^[2]. Article 12(2)(d) of the delegated regulation on ICT risk management requires logs to be protected against tampering, deletion and unauthorised access ^[2].

The rule is clear. Logs are what tell supervisors, auditors and internal teams what happened. They must be trustworthy, not just present.

For a bank, payment institution or insurer running Citrix NetScaler, the question raised by this week's vulnerabilities is whether the logs that would show what happened during an incident can still be relied upon. If an attacker gained access, could they have changed the logs? If so, how would you know?

Access controls and monitoring are the foundation. An independent fingerprint per log goes one step further, because a change shows up even when it is made by someone with the right access ^[5].

Reporting obligations under the Cyber Resilience Act

The Cyber Resilience Act applies from 11 September 2026 to manufacturers of products with digital elements ^[3]. Article 14 requires manufacturers to report actively exploited vulnerabilities and serious incidents via ENISA's common platform, with short deadlines at each step ^[3].

Citrix, as a manufacturer, has issued patches and guidance ^[1]. For organisations that build or distribute products that incorporate Citrix NetScaler, the question is whether this vulnerability counts as a serious incident in their own product chain, and whether it has been actively exploited in a way that affects their customers.

The penalties for failing to report are up to 15 million euros or 2.5 per cent of global annual turnover, whichever is higher ^[3].

The Swedish Cybersecurity Act

Sweden's Cybersecurity Act, which implements the NIS2 Directive, has applied since 15 January 2026 ^[4]. It covers essential and important entities in 18 sectors, including energy, transport, healthcare, digital infrastructure and public administration ^[4].

The reporting requirements are clear: an early warning within 24 hours, an incident report within 72 hours and a final report within one month ^[4].

For an organisation in one of these sectors running Citrix NetScaler, the question is whether the vulnerabilities and any related exploitation count as a significant incident. If they do, the clock has started.

Reporting obligations assume you can show what happened. If an attacker could have altered the logs, the report becomes harder to substantiate.

What this means for you

If your organisation runs Citrix NetScaler ADC or Gateway, consider the following questions:

1. Have you applied the patches Citrix released, and have you assessed whether the vulnerabilities were exploited in your environment?
2. If you are covered by DORA, can you show that your logs have not been tampered with, deleted or accessed without authorisation, as Article 12(2)(d) requires?
3. If you are a manufacturer covered by the Cyber Resilience Act, do these vulnerabilities trigger a reporting obligation under Article 14?
4. If you are an essential or important entity under the Swedish Cybersecurity Act, does this incident require an early warning within 24 hours and an incident report within 72 hours?
5. If logs are your record of what happened, how do you prove they have not changed since they were created?

Access controls and monitoring tell you who can reach the logs and when they were accessed. An independent fingerprint, sealed at the time each log entry is written, tells you whether the content has changed. The difference matters when someone questions the record.

The evidence question

A log you can quietly edit is a diary. A log you can prove has not changed is evidence.

The vulnerabilities CERT-SE warned about this week are serious because they allow an attacker to gain control of a system and potentially alter the very records that would show what they did ^[1]. For organisations in regulated sectors, that is not just a technical problem. It is a compliance problem and a trust problem.

DORA is explicit that logs must be protected against tampering ^[2]. The Cyber Resilience Act and the Swedish Cybersecurity Act both assume that when you report an incident, you can back up what you say with records that hold up under scrutiny ^[3][4].

That is the evidence question. When something is questioned, can you show what your systems did, and can you show that the record has not changed? A digital witness per log gives you an independent fingerprint that anyone can check, without having to trust whoever keeps the logs.

It does not replace access controls or monitoring. It adds one thing: the ability to show a change, even when it is made by someone with the right access.