Why NIS2 CIR Annex §6.7 Requires RPKI for IXPs — and How Route Leaks Trigger Art.23 Reporting

Internet exchange points carry a disproportionate share of the EU’s internet traffic. A major IXP — DE-CIX Frankfurt, AMS-IX Amsterdam, LINX London — peers hundreds of networks exchanging tens of terabits per second. BGP, the protocol those networks use to exchange routing information, has no built-in authentication. That gap is what makes IXPs a compliance priority under NIS2 that most compliance frameworks miss.

The NIS2 Directive and its implementing regulation CIR 2024/2690 place IXPs explicitly within the digital infrastructure category, making them subject to the same security obligations as DNS providers, cloud platforms, and data centres. For an IXP, the core obligation is not endpoint security or patch management — it is routing security.

This guide covers three things other resources don’t. First, why CIR Annex §6.7 (Network Security) is the operative provision for IXP BGP controls — and what it actually requires. Second, how BGP hijacks and route leaks have materially different Art.23 reporting consequences. Third, how the MANRS IXP Program serves as the operational compliance framework for §6.7. If you operate or advise a digital infrastructure entity, this guide provides the specific framework your Art.21 evidence package needs.

IXP Scope Under NIS2: Who Must Comply and What That Means

The NIS2 Directive (2022/2555) lists Internet exchange points in Annex I under the Digital Infrastructure subsector. The directive defines an IXP as a network facility that enables interconnection of more than two independent autonomous systems, primarily for the purpose of facilitating internet traffic exchange, which neither requires traffic to pass through a third autonomous system nor alters or otherwise interferes with that traffic.

That definition matters for scope assessment. A peering fabric operated by a single carrier — where the carrier routes traffic at its own discretion — does not qualify as an IXP under NIS2. A neutral interconnection facility where member ASes peer directly does. The Finnish NCSC, the national competent authority for digital infrastructure in Finland, confirms IXPs are subject to CIR 2024/2690 as digital infrastructure operators, with jurisdiction determined by the location of the entity’s main establishment in the EU.

Entity classification follows the standard NIS2 thresholds. Large IXPs — those with 250 or more employees or annual turnover exceeding €50 million — qualify as Essential entities. Medium IXPs (50–249 employees, or €10–50 million turnover) qualify as Important entities. Small operators may still be designated in scope by member states that identify systemic criticality regardless of size, a provision particularly relevant for IXPs that are the sole interconnection point for a national or regional market.

The distinction matters operationally. Essential entities face proactive supervision, mandatory management accountability under Art.20, and fine exposure up to €10 million or 2% of global annual turnover. Important entities face reactive supervision and fines up to €7 million or 1.4% of global annual turnover. Both categories must comply with CIR 2024/2690, which sets binding technical and methodological requirements that apply directly without national transposition.

One common compliance error: assuming that because DORA applies to financial entities peering at the IXP, the IXP itself falls under DORA supervision. The IXP is digital infrastructure, not a financial entity. NIS2 is the applicable framework. DORA applies to the financial entities that are members of the IXP, not to the IXP operator itself.

CIR Annex §6.7: The Network Security Obligation and What It Means for BGP

CIR 2024/2690 organises its technical requirements in a 13-section Annex. Section 6 addresses security in network and information systems acquisition, development and maintenance. Within that section, §6.7 specifies network security: measures to protect networks and information systems against cyber threats. Section §6.8 addresses network segmentation — segmentation of systems into networks or zones based on risk.

A note that prevents a common error: CIR Annex §6.4 covers change management, repairs and maintenance — not routing security. Multiple commercial guidance documents incorrectly cite §6.4 as the BGP/routing provision. The operative section for IXP network controls is §6.7.

The CIR’s language is intentionally technology-neutral. It does not name BGP, RPKI, or MANRS by name. This creates an interpretation challenge for IXP compliance officers: the regulation mandates an outcome (networks protected against cyber threats) without specifying the mechanism. Three sources close that gap.

First, the ENISA Technical Implementation Guidance (June 2025) provides practical examples of how §6.7 requirements translate into technical controls for specific entity types. Second, the European Commission has endorsed MANRS as a relevant internet security standards initiative, providing a direct bridge from the technology-neutral §6.7 text to IXP-specific routing controls. Third, national competent authorities for digital infrastructure — including NCSC-FI — confirm that IXPs are subject to CIR 2024/2690 network security obligations, and BGP routing security is the primary control domain the regulation addresses for this entity type.

For general enterprise network architecture — the 4-zone segmentation model that satisfies §6.7 and §6.8 for internal IT environments — see the NIS2 network security guide. For an IXP, §6.7 compliance has three technical dimensions specific to routing infrastructure. Route server filtering prevents RPKI-invalid and IRR-inconsistent route announcements from propagating to peering members. BGP session authentication, typically via MD5 or TCP-AO, prevents session hijacking. BGP monitoring with defined alerting thresholds creates the awareness mechanism that triggers Art.23 notification obligations. An IXP with enterprise-grade firewall coverage but no route server filtering policy has not satisfied §6.7.

RPKI as the Primary §6.7 Control: How Route Origin Validation Works

Resource Public Key Infrastructure (RPKI) provides cryptographic proof of which autonomous system is authorized to originate a given IP address prefix. The core object is the Route Origin Authorization (ROA): a digitally signed statement that specifies which AS number may originate a given prefix and the maximum prefix length permitted.

When an IXP route server applies RPKI-based Route Origin Validation (ROV), each incoming BGP announcement is checked against the globally distributed RPKI repository. The result is one of three states. A VALID route has at least one ROA that matches the announced origin AS and prefix length — it is accepted. An INVALID route has a ROA covering the prefix, but the announcement comes from a different AS or uses a longer prefix than the ROA permits — it is filtered. An UNKNOWN route has no ROA covering the prefix — it is typically accepted, because absence of a ROA does not indicate a problem, only absence of cryptographic proof.

The practical implementation at an IXP involves four components. The IXP creates ROAs for its own infrastructure prefixes using its Regional Internet Registry (for European IXPs, RIPE NCC). The IXP deploys Relying Party (RP) software — tools such as Routinator, FORT Validator, or OctoRPKI — that cache and validate the global RPKI repository and export validated ROA sets. Route server software (typically BIRD2 or OpenBGPD) queries the RP software and applies INVALID-state filtering to member announcements. Members are encouraged, and required under MANRS, to create ROAs for the prefixes they announce to the IXP.

There is a critical limitation to understand for Art.23 purposes: RPKI solely offers origin validation. It answers the question “is this AS authorized to originate this prefix?” It does not validate the AS-PATH — the sequence of autonomous systems a route traverses to reach its destination. This means RPKI detects and prevents BGP prefix hijacks, where the wrong AS claims to originate a prefix. It does not detect route leaks, where the correct AS’s prefix is re-advertised by an intermediary in the wrong direction. That distinction drives directly into Art.23 incident classification.

Route Leaks vs BGP Hijacks: The Art.23 Classification That Changes Reporting Obligations

A BGP hijack and a route leak look similar in operational impact — both cause traffic to flow through the wrong path — but they are distinct incidents with different RPKI detection signatures and different probabilities of triggering Art.23 significance criteria.

BGP hijack: An AS announces prefixes it does not legitimately hold. The announcement carries the wrong origin AS. If the legitimate holder has created ROAs, the RPKI state of those announcements will be INVALID. Traffic intended for the legitimate AS is diverted to the hijacking network, where it may be dropped, delayed, or intercepted.

The Pakistan Telecom incident of February 2008 illustrates the Art.23(3) consequence: Pakistan Telecom announced YouTube’s address blocks to block domestic access, but the more-specific routes propagated globally, effectively blocking YouTube for users in over 60 countries for several hours. Under Art.23(3)(a), this meets the severe operational disruption criterion. Under Art.23(3)(b), it caused considerable non-material damage to millions of third-party users. The 2022 KLAYswap attack used a BGP hijack combined with a fraudulent TLS certificate to redirect DNS traffic and steal approximately $2 million in cryptocurrency — clearly meeting both Art.23(3)(a) and Art.23(3)(b) criteria.

Route leak: An AS re-advertises routes it has legitimately received from one BGP neighbor to another neighbor that should not receive them. The origin AS in the route’s AS-PATH is correct — only the propagation path is wrong. Because the originating AS has valid ROAs, RPKI does not flag these routes as INVALID. Route leaks travel through correct-origin paths; they simply travel too far.

The Art.23 analysis for route leaks is more nuanced. The November 2018 MainOne/China Telecom incident illustrates the spectrum: a route leak caused a significant volume of Google traffic to transit through China before reaching its destination. Operational disruption was limited — traffic was delayed, not dropped. But the potential for interception created Art.23(3)(b) exposure even without confirmed service disruption. The June 2019 Allegheny Technologies leak caused a severe disruption with substantial traffic blackholing — clear Art.23(3)(a) territory.

The classification framework below reflects published implementation guidance on CIR 2024/2690 thresholds. According to CIR 2024/2690 Art.3 significance criteria, financial loss thresholds for digital infrastructure providers are commonly cited at approximately €500,000 or 5% of annual turnover — confirm the exact figure applicable to your entity category against the CIR text directly. For service disruption, implementation guidance and NCA supervisory practice commonly reference approximately 30 minutes of unavailability as a practical threshold for digital service providers when assessing whether Art.23(3)(a) “severe operational disruption” is met.

Incident Type	RPKI Detection	Art.23(3)(a) Trigger	Art.23(3)(b) Trigger	24h Clock
BGP Hijack (intentional)	INVALID state if ROA exists	Near-certain — traffic diverted or dropped	Near-certain — third-party users affected	At BGP monitoring alert
BGP Hijack (accidental mis-origination)	INVALID state if ROA exists	Depends on duration and scale	Possible if traffic interceptable	At BGP monitoring alert
Route Leak (blackhole — traffic dropped)	Not detected by RPKI	Yes, if outage exceeds ~30 minutes	Yes — peering members lose reachability	At detection of service impact
Route Leak (suboptimal path — traffic degraded)	Not detected by RPKI	Unlikely unless financial loss threshold met	Possible if interception risk confirmed	Only if significance threshold met

The awareness timestamp is the most operationally significant detail. Art.23 starts the 24-hour clock when the entity “becomes aware” of the significant incident — not when root cause is confirmed, not when the incident is contained, and not when significance is formally assessed. The full Art.23 notification workflow — covering content requirements for each stage and the CSIRT routing rules — is covered separately. An automated BGP monitoring system that fires an alert constitutes awareness for Art.23 purposes. IXPs that defer the 24-hour clock to the end of their significance assessment process are already in breach of the timeline.

The practical implication: write the significance assessment procedure before the first BGP alert fires. The NOC runbook should include a documented decision tree — received alert, assessed impact against Art.23(3)(a)/(3)(b) criteria, determination made, escalated to compliance function if threshold met — with timestamps at each step. That document is what a competent authority will request first.

MANRS IXP Program: The §6.7 Compliance Framework in Practice

Mutually Agreed Norms for Routing Security (MANRS) is the primary industry framework for implementing CIR §6.7 controls at IXPs. The European Commission has endorsed MANRS as a relevant initiative for internet security standards. MANRS participation is not legally mandated by the NIS2 Directive or CIR 2024/2690, but it provides the most operationally recognised framework for demonstrating §6.7 compliance, and the documentation it requires directly satisfies the Art.21(2) evidence package.

The MANRS IXP program defines five actions, three compulsory and two recommended.

Compulsory Action 1 — Filtering: Prevent propagation of incorrect routing information by implementing filtering of route server announcements based on IRR data and route origin data. This is the direct §6.7 technical control. IRR-based filtering rejects routes inconsistent with the publicly registered AS-SET objects. RPKI-based filtering adds cryptographic verification on top of IRR records.

Compulsory Action 2 — Coordination: Facilitate global operational communication and coordination by providing mailing lists and member directories. This supports the fast incident response that Art.23’s 24-hour clock requires.

Compulsory Action 3 — Global Validation via IRR: Facilitate routing information validation using Internet Routing Registry data. Members are encouraged to maintain accurate AS-SET objects and route objects in the IRR so that filtering can be applied across the membership.

Recommended Action 4 — Anti-Spoofing: Prevent traffic with spoofed source addresses from transiting the peering fabric, protecting against DDoS amplification attacks that use IXP infrastructure.

Recommended Action 5 — RPKI Validation: Implement route origin validation using RPKI ROA data on the route server. MANRS designates RPKI as a recommended rather than compulsory action because a significant share of the internet’s address space still lacks ROA coverage — deploying strict RPKI filtering before ROA coverage reaches critical mass would create reachability gaps. For NIS2 compliance purposes, however, deploying RPKI-based filtering with a “reject INVALID, accept UNKNOWN” policy is the current industry standard and the expected §6.7 implementation for IXPs.

For audit purposes, MANRS membership and its associated documentation — filtering policies, route server configurations, IRR query scripts, RP software deployment records — constitute primary evidence of §6.7 compliance. Non-member IXPs can produce equivalent evidence through documented internal policies, but MANRS membership provides third-party verification that the controls are implemented and maintained.

Building the Art.21 Documentation Package for IXP BGP Security

Art.21(2) requires not only implementation but documented evidence that security measures are in place, proportionate, and regularly reviewed. For IXPs, the §6.7 compliance documentation package should include the following components.

Network Security Policy (§6.7 evidence): Documents the IXP’s approach to routing security, covering route server architecture, filtering methodology (IRR-based, RPKI-based, or both), the rationale for the RPKI treatment of UNKNOWN-state routes, and the review cadence. This policy should explicitly reference CIR Annex §6.7 and §6.8 as its regulatory basis.

BGP Anomaly Detection Procedure (§6.7 and Art.21(2)(b) evidence): Defines how BGP hijacks and route leaks are detected — monitoring tools, alerting thresholds, escalation path — and the documented response steps, including the Art.23 significance assessment. For a six-phase IR framework applicable to digital infrastructure entities, the NIS2 incident response playbook guide provides the structural template. The procedure must specify the awareness timestamp mechanism so the 24-hour clock is unambiguous.

Art.23 Significance Assessment Checklist (Art.23 evidence): A documented decision process applied consistently to every BGP incident alert before the reporting decision is made. The checklist covers the Art.23(3)(a) operational disruption test (duration, scale, financial impact), the Art.23(3)(b) third-party harm test (which member ASes are affected, whether traffic interception is possible), and the escalation authority.

Incident Notification Templates (Art.23 evidence): The 24-hour early warning, 72-hour incident notification, and 1-month final report templates, pre-populated with IXP-specific fields. The 72-hour notification should include AS numbers involved, affected prefix ranges, peering session counts disrupted, and downstream impact assessment. For BGP hijacks, indicators of compromise should include the specific RPKI-INVALID routes observed and the timeline of propagation.

RPKI ROA Audit Log (§6.7 evidence): A quarterly audit confirming that all prefixes originated by the IXP have valid ROAs in the relevant RIR’s RPKI system, and that the Relying Party software version is current. ROA expiry monitoring should be part of routine operations — an expired ROA converts VALID routes to UNKNOWN, silently degrading the filtering effectiveness.

Art.20 management accountability means the IXP’s governing body must approve the security policy and receive regular incident and compliance reporting. For IXPs with multi-stakeholder board structures, a dedicated cybersecurity committee with incident review authority satisfies this requirement. The board approval of the Network Security Policy should be minuted and dated — that approval record is what a competent authority examines when assessing Art.20 governance compliance.

Frequently Asked Questions

Does NIS2 explicitly require RPKI for IXPs?

No. The NIS2 Directive and CIR 2024/2690 use technology-neutral language. CIR §6.7 requires “measures to protect networks and information systems against cyber threats” without naming RPKI. However, RPKI-based route origin validation is the standard technical control for BGP prefix hijack prevention at IXPs, and the implementation that ENISA guidance and MANRS requirements point to. An IXP that implements §6.7 via RPKI is in the expected position; one that does not should document a risk-justified alternative.

When does a route leak trigger the Art.23 24-hour clock?

The 24-hour clock starts when the IXP becomes aware of a significant incident. If a BGP monitoring alert fires and the initial assessment indicates the leak may have caused service disruption or third-party harm meeting the Art.23(3) criteria, that awareness moment starts the clock. The significance determination does not need to be complete before the clock starts. When in doubt, submit the early warning within 24 hours — it can be updated in the 72-hour notification.

Is MANRS membership a legal requirement under NIS2?

No. MANRS membership is not mandated by the directive or the CIR. It provides an industry-recognised compliance framework and third-party verification of filtering controls, but equivalent documentation from internal policies satisfies the same Art.21(2) evidence requirement.

Can a route leak trigger Art.23 even without confirmed data interception?

Yes. Art.23(3)(b) requires only that the incident “is capable of” causing considerable damage to other persons — not that damage has been confirmed. A route leak that routes traffic through an AS in a jurisdiction with known deep-packet inspection capabilities meets this criterion even if no confirmed interception occurred. Document the capability assessment, not just the confirmed outcome.

Sources

NIS2 Directive (EU) 2022/2555, Article 21: Cybersecurity risk-management measures.

NIS2 Directive (EU) 2022/2555, Article 23: Reporting obligations.

Commission Implementing Regulation (EU) 2024/2690, Annex: Technical and methodological requirements. Advisera annotated text.

NIS2 CIR 2024/2690: Cybersecurity requirements for EU digital infrastructure companies. Advisera, 2024.

RIPE NCC, BGP origin validation (RPKI). RIPE NCC documentation.

Finnish National Cyber Security Centre (NCSC-FI), Digital infrastructure, digital services and ICT services. Traficom/NCSC-FI.

Kentik, A brief history of the internet’s biggest BGP incidents. Kentik Blog, 2023.

nisd2.eu, NIS2 reporting obligation: incident significance thresholds.

OpenKRITIS, CIR 2024/2690 — NIS2 technical measure mapping.

European Commission, Mutually Agreed Norms for Routing Security (MANRS).

This article provides general information only and does not constitute legal or regulatory advice. Requirements may vary by jurisdiction and organisation type. Consult a qualified legal professional or compliance specialist for advice specific to your situation.