Fast Check: After CISA's 30 July 2026 WireGuard Key Advisory, MikroTik's RouterOS Falls Under the CRA's Class I Rules
On 30 July 2026, the US Cybersecurity and Infrastructure Security Agency published advisory ICSA-26-211-01, covering CVE-2026-14227 in MikroTik RouterOS. The flaw is an insufficient session expiration weakness in the RouterOS API: an active session keeps the permissions it was created with even after the account is downgraded or the timeout passes. CISA's assessment is that this lets an attacker read the router's WireGuard private key in plaintext from a low-privilege API account, enough to impersonate the router to every peer in the tunnel. Two days earlier, on 28 July 2026, CISA published a companion advisory, ICSA-26-209-05, reporting that the same API accepts unlimited login attempts with no lockout. No firmware fix exists for either.
An EU manufacturer, with no importer buffer
MikroTik is SIA Mikrotīkls, based in Riga, Latvia. Most of our recent Fast Checks looked at third-country vendors, where importers and distributors carry part of the load under Articles 19 and 20. This manufacturer is established in the Union, so the obligations in Article 13 land directly on the company.
RouterOS is Class I three times over
The CRA sorts products with digital elements into a default tier, viktig products (Annex III) and kritisk products (Annex IV). RouterOS and the hardware it runs on hit Annex III, Class I from three directions at once:
- item 11, operating systems, which is what RouterOS is;
- item 12, routers, modems intended for the connection to the internet, and switches;
- item 5, products with digital elements with the function of virtual private network (VPN), which is exactly the WireGuard function at issue.
Class I is the lower of the two Annex III bands, but under Article 32 a Class I product may only take the light internal-control route (module A) where the manufacturer applies harmonised standards, common specifications or a European cybersecurity certification scheme covering the essential requirements. Otherwise it needs modules B and C, module H, or certification. You can test any device against the tiers with our classification tool, or run the full Fast Check yourself.
Which essential requirements this engages
Annex I, Part I has four points in play. Point (2)(d) requires protection from unauthorised access by appropriate control mechanisms, including authentication and access management: a session that outlives the privileges that created it fails that, and an API with no lockout fails it twice. Point (2)(e) requires protection of the confidentiality of stored data, such as by encrypting relevant data at rest, and a permanent VPN identity key readable in cleartext by a low-privilege account is the textbook case that point is aimed at. Point (2)(j) requires products to limit attack surfaces, including external interfaces. Point (2)(a) requires that products be placed on the market without known exploitable vulnerabilities.
The absence of a patch is the sharper problem
Annex I, Part II(2) requires manufacturers to address and remediate vulnerabilities without delay, including by providing security updates. MikroTik's published answer is an operating instruction: log out active API sessions manually whenever an account's permissions change. That is a workaround placed on the customer, not a remediation delivered by the manufacturer, and the duty runs for the whole declared support period under Article 13(8). Our efterlevnadsmatris maps the Annex I duties to the evidence a manufacturer must hold.
Would this have to be reported?
Not on these facts. Article 14 is triggered by an actively exploited vulnerability or a severe incident, not by publication of a CVE, and neither advisory reports exploitation in the wild. Were that to change after 11 september 2026, MikroTik would owe an early warning to its CSIRT and ENISA within 24 timmar of becoming aware, a vulnerability notification within 72 timmar and a final report within 14 dagar. One point is often misread: it is the receiving CSIRT or authority, not the manufacturer, that may delay onward dissemination on cybersecurity grounds. The manufacturer's 24 hour clock does not stop. Our rapporteringsguide sets out the sequence.
ENISA's Single Reporting Platform, the channel through which these reports are meant to be filed, is not yet live. ENISA has scheduled it to be operational by 11 september 2026, the date the reporting obligations start to apply, and the exact submission screens and electronic end-points remain subject to ENISA's specifications. Separately, no CRA harmonised standard has yet been cited in the Official Journal, so the Article 27 presumption of conformity, and with it the self-assessment route for Class I products, is not available in practice today. The CRA's full obligations apply from 11 December 2027.
What to do now
Operators should follow CISA's steps: disable the RouterOS API where nothing needs it, restrict ports 8728 and 8729 to a dedicated management network, use only the TLS service, terminate stale sessions after any permission change, and rotate the WireGuard key on any broadly reachable device. For EU buyers there is also a procurement point. From 11 December 2027, whether a vendor ships a code-level fix or a configuration workaround stops being a service-quality preference and becomes a market-access condition.
