L'orologio NIS2 europeo è già partito: perché il vostro polling SNMP da cinque minuti non rispetterà la scadenza di 24 ore

L'orologio di preallarme di 24 ore della NIS2 si attiva dal momento in cui si viene a conoscenza di un incidente significativo. Se il monitoraggio di rete continua a effettuare il polling dei contatori di dispositivo ogni cinque minuti, l'orologio è già avviato prima che chiunque nel NOC abbia visto l'evento. Quel divario, tra la cadenza regolatoria e la cadenza della telemetria, è la parte della conformità NIS2 che nessuna dashboard può risolvere.

Ciò che non rivendichiamo

Prima dell'esposizione normativa o dell'argomentazione tecnica, l'inquadramento onesto è il seguente:

Cosa richiede effettivamente la NIS2

La NIS2 è la direttiva di seconda generazione dell'Unione europea sulla sicurezza delle reti e dei sistemi informativi (direttiva (UE) 2022/2555). Sostituisce quella originaria del 2016 e definisce una linea di base armonizzata in materia di cybersicurezza in tutti i 27 Stati membri; le norme nazionali si applicano dal 18 ottobre 2024. La direttiva include nel proprio ambito circa 160.000 soggetti: ISP regionali, IXP, operatori di sovereign cloud e data center, MSSP e prestatori di servizi fiduciari, accanto agli operatori tier-one. Tutti si collocano all'interno dello stesso perimetro di compliance, con lo stesso termine di notifica.

La maggior parte degli operatori non ha interiorizzato cosa significhi, in pratica, un termine di 24 ore ancorato alla consapevolezza. Prima di affrontare il tema della telemetria, ecco come si presenta quel termine.

Vale la pena soffermarsi un momento. Un regolatore che successivamente scopra che l'incidente è in realtà iniziato a T-90 minuti, perché il ciclo SNMP di 5 minuti ha mancato i primi tre stati, non restituirà il tempo che la cadenza di polling ha consumato.

Chi rientra nella NIS2, e cosa costa restarne fuori

ENISA estimates more than 160,000 entities fall under NIS2, against 10–15,000 under NIS1. The directive splits them into soggetti essenziali (Annex I: energy, transport, banking, health, water, digital infrastructure, ICT service management, public administration) and soggetti importanti (Annex II: postal, waste, food, manufacturing of critical products).

Chi rientra nell'ambito, per il pubblico di IP Infusion

• Regional fibre ISPs, mobile and Open RAN operators: essenziali, non soggetti alla soglia dimensionale.
• IXPs, data-centre and cloud providers (including sovereign cloud): essenziali.
• Prestatori di servizi fiduciari: sempre essenziali, senza soglia dimensionale.
• MSP e MSSP: essenziali nell'ambito della gestione dei servizi ICT.

Per le comunicazioni elettroniche pubbliche, il DNS, i TLD e i servizi fiduciari, la soglia dimensionale non offre alcuna esenzione.

Sanzioni, responsabilità personale e orologio di notifica

Article 34's €10M or 2% of turnover figure for essential entities (€7M / 1.4% for important entities) is the EU-wide soglia minima that member states can exceed, not a cap; none have gone lower. Article 20 puts the obligation on named individuals at the management body, and Article 32(5)(b) lets regulators temporarily prohibit a CEO or legal representative from managerial functions until the breach is remediated. Article 33 extends the same enforcement to important entities; Germany codifies personal executive liability in Section 38(2) of the BSIG (the German IT Security Act). Article 23 anchors the reporting clock on awareness: 24-hour early warning, 72-hour incident notification, one-month final report.

La Germania guida il recepimento con la NIS2UmsuCG (in vigore dal 6 dicembre 2025, oltre 29.500 soggetti, nessun periodo transitorio). Italia e Austria raggiungeranno la piena operatività entro ottobre 2026; la maggior parte degli altri grandi mercati è in vigore o ancora in fase di redazione. L'azione di vigilanza è iniziata: a inizio 2026, il BSI ha emesso notifiche formali ai soggetti nell'ambito, la Germania ha avviato procedimenti per notifica tardiva di incidenti, la Francia ha emesso diffide formali e l'Italia ha avviato ispezioni settoriali. Le grandi sanzioni parametrate al fatturato non sono ancora arrivate, ma l'escalation in stile GDPR è chiaramente in atto.

Article 21(2) lists ten minimum risk-management measures. The ones that drive this post are (b) incident handling, (f) policies to assess effectiveness of measures, e (d) supply chain security. The first two share a technical prerequisite most operators have not built: continuous, standards-based network telemetry. The third requires a supply chain you can actually inspect.

Già in esercizio in giurisdizioni di recepimento della NIS2

While the incumbents publish NIS2 readiness whitepapers, European operators on OcNOS are already in production inside transposed jurisdictions. eww ITandTEL runs a sovereign MPLS backbone in Upper Austria on disaggregated 400G ZR+ hardware (essential-entity profile under Austria's NISG 2026). DIGI Group runs OcNOS for OLT aggregation in Romania, where the DNSC can verify the hardware and software substitution path. AnschlussWerk across DACH and ASOM-Net in Denmark run OcNOS in production under Germany's NIS2UmsuCG, the most aggressive regime in Europe. Three jurisdictions, three operators, one architectural shape. The rest of this post is the technical reasoning behind that shape.

Perché la telemetria di rete è il punto debole (e il settore vi sta vendendo la soluzione sbagliata)

Your detection is only as fast as your telemetry. NIS2 never uses the word "monitoring" in its operative articles, and vendors have taken that as cover to frame the directive as a governance exercise. That framing does not hold up: Implementing Regulation (EU) 2024/2690 and ENISA's Technical Implementation Guidance v1.0 (26 June 2025) name network traffic monitoring, log management and anomaly detection outright for digital-infrastructure entities, and operators outside IR 2024/2690 scope face the same expectations through national transposition. Article 23's 24-hour clock leaves very little room once a five-minute SNMP cycle has eaten part of it.

Perché SNMP non può sostenere il carico

Tre modalità di fallimento, ciascuna delle quali erode la finestra di risposta entro un termine di 24 ore:

• Cadenza di polling. Un intervallo da 5 a 15 minuti significa che la consapevolezza di qualsiasi evento è in ritardo fino a un ciclo completo. Un DDoS volumetrico che si esaurisce all'interno di una finestra, o un withdraw BGP che riconverge prima del polling successivo, è invisibile all'NMS. Se ne viene a conoscenza tramite una segnalazione a valle, e si sono già consumate ore del budget di 24 ore.
• Campionamento del solo ultimo valore. Se un link oscilla cinquanta volte tra due polling, si osserva un unico stato finale. La cronologia forense che la notifica entro 72 ore e la relazione finale entro un mese dell'Articolo 23 si attendono è difficile da ricostruire da dati mai acquisiti.
• Trasporto fragile. Le trap SNMP su UDP/162 sono fire-and-forget. In una tempesta di control-plane, esattamente il momento in cui l'allarme è più necessario, le trap sono la prima cosa che la rete scarta. Le community string SNMPv1/v2c sono in chiaro, e l'adozione di SNMPv3 USM negli apparati di transito resta disomogenea.

Un operatore può comunque rispettare la cadenza di notifica della direttiva continuando a usare SNMP, a condizione che i propri processi siano sufficientemente rigorosi. Il trade-off riguarda la latenza di conoscenza dell'evento e la profondità forense: la finestra di risposta è più stretta di quanto potrebbe essere e la timeline ricostruita per l'autorità competente è più sottile.

Cosa sbagliano le «piattaforme di conformità»

La narrativa dominante dei vendor tratta la NIS2 come un acquisto di SIEM, XDR o AIOps. Le piattaforme in sé (Cisco, Splunk, Dynatrace e le altre) sono eccellenti in ciò che fanno, ma il modello di ingestion che ereditano non può fare meglio dei propri input: le piattaforme di observability ingeriscono ciò che la rete fornisce loro, non possono rilevare ciò che la rete non ha mai segnalato. Il pricing a GB ingestionato penalizza poi proprio il volume di telemetria che rende utile la rilevazione. Il trasporto carrier-grade, ossia l'IXP, i data-centre interconnect e l'underlay del sovereign cloud, dove gli obblighi NIS2 dei telco mordono davvero, è in larga parte invisibile agli stack di endpoint e perimetrali.

La soluzione duratura consiste nello spingere il piano di rilevamento all'interno dello stesso sistema operativo di rete, in un formato vendor-neutral. Stessa fisica, indipendentemente da quale logo si trovi al di sopra.

Cosa cambia effettivamente la telemetria in streaming

I dettagli contano:

• gNMI utilizza gRPC su HTTP/2, supporta TLS e offre sottoscrizioni a eventi ON_CHANGE insieme alla modalità Sample per i contatori periodici. Streaming in tempo reale. Non polling di cinque minuti.
• OpenConfig YANG fornisce uno schema unico tra i fornitori: lo stesso XPath in /interfaces/interface/state/counters/in-discards è portabile su qualsiasi sistema operativo di rete che implementi openconfig-interfaces. Un solo parser su tutto il parco, con le medesime regole di alerting e la medesima audit trail in esecuzione sovrastante.
• Trasporto protetto da TLS: le sessioni gNMI sono autenticate reciprocamente con certificati X.509, non con community string in chiaro.

Abbiamo sviluppato l'argomentazione tecnica più estesa a febbraio 2026 in Stop polling, start streaming: why SNMP is crippling your network visibility. La NIS2 è ciò che la trasforma da preferenza architetturale in requisito regolatorio.

L'open networking fornisce le fondamenta di telemetria che le architetture NIS2 richiedono

NIS2 pone due aspettative tecniche su cui poggia il resto della postura di notifica dell'operatore: visibilità continua a livello di rete (Articles 21(2)(b/c/f/g) and, for digital-infrastructure entities, IR 2024/2690) and trasparenza dei fornitori (Article 21(2)(d)). The proprietary majors now all expose OpenConfig YANG and gNMI, so the gap is not about telemetry standards. It is about supply-chain layer count: a vertically-integrated chassis is one vendor across silicon, hardware, NOS and orchestration; a disaggregated stack splits the same network into independently sourceable layers, which is what makes the Article 21(2)(d) supplier assessment tractable.

This matters more as European operators move to IPoDWDM with 400G ZR+ optics e SR-MPLS / SRv6 in the core, where optical pre-FEC BER drift, segment-routing transitions and BFD session state are the early-warning signals SNMP cannot see fast enough to be useful.

Telemetria in streaming nativa, non un componente aggiuntivo

OcNOS exposes gNMI come sottosistema a livello di sistema, not a management overlay, with TLS-secured transport and OpenConfig YANG schemas. The properties that matter for NIS2:

• Modelli dati OpenConfig YANG per interfacce, BGP, routing-policy, sistema e percorsi di piattaforma. Uno schema standardizzato è ciò che consente a un singolo set di regole di alerting di sopravvivere a un parco multi-vendor. Senza di esso, ogni apparato è un problema di parser a sé.
• gNMI Subscribe con streaming di eventi ON_CHANGE per lo stato, più la modalità Sample periodica per i contatori. Push, non polling. La differenza emerge nella latenza di consapevolezza, non nelle matrici di confronto funzionale.
• BGP RPKI Origin Validation respinge le rotte BGP non valide a livello di dispositivo. Un controllo verificabile anti-prefix-hijack rilevante per i più ampi obblighi di sicurezza di rete di cui all'Articolo 21(2).
• Campionamento di flusso sFlow a line-rate sull'intera gamma SKU, affiancato ai flussi di stato e contatori di gNMI anziché in loro sostituzione.
• BMP route monitoring with BGP-LS topology export so a controller or SIEM sees every announce and withdraw, not just interface counters. Exactly the kind of state-transition record the 72-hour and 30-day reporting clocks expect.

La disaggregazione è trasparenza della catena di fornitura

L'articolo 21(2)(d) impone ai soggetti di valutare le pratiche di sicurezza di ciascun fornitore diretto. Il regolamento di esecuzione (UE) 2024/2690 trasforma tale obbligo in un'aspettativa di disclosure per singolo componente e le linee guida ENISA del giugno 2025 lo interpretano come un mandato SBOM implicito.

Uno chassis monolitico è una singola distinta base chiusa che l'operatore non può ispezionare, sottoporre ad audit né sostituire dall'interno. Uno stack disaggregato (OcNOS su hardware whitebox di Edgecore o UfiSpace, approvvigionato tramite integratori come EPS Global nell'UE) suddivide quella BOM in livelli acquistabili in modo indipendente, ciascuno con il proprio SBOM e sostituibile secondo una propria tempistica. Il costo del 5G Toolbox tedesco (Huawei fuori dal core 5G entro fine 2026 e dai sistemi di gestione della rete in accesso e trasporto entro fine 2029) mostra come si presenta il lock-in monofornitore una volta arrivata una designazione di high-risk vendor. L'articolo 21(2)(d) si riduce alla questione se la catena di fornitura dietro il livello di trasporto sia ispezionabile. Le architetture di questa forma lo sono. Quelle a integrazione verticale no.

Le installazioni di eww ITandTEL, DIGI, AnschlussWerk e ASOM-Net descritte sopra non sono casuali. Condividono la stessa forma a quattro tratti: hardware disaggregato che l'operatore può sottoporre ad audit, streaming telemetry nativa fin dal primo giorno, una catena di fornitura che regge a una designazione di high-risk vendor senza un rip-and-replace pluriennale e un audit trail che un assessor del BSI, dell'ANSSI, dell'ACN o del DNSC può effettivamente ispezionare.

La NIS2 non è una casella di verifica che si acquista da un fornitore. È un audit della catena di fornitura governato da un problema di fisica. Nessuna dashboard al di sopra del piano di telemetria può rilevare un incidente più rapidamente di quanto il piano sottostante si aggiorni.

Le piattaforme unificate di conformità proposte dagli incumbent riproducono l'esposizione a fornitori concentrati che l'Articolo 21(2)(d) è progettato per evidenziare, posizione poco propizia da cui correggerla.

Su IP Infusion · IP Infusion è il leader nelle soluzioni di networking disaggregato. OcNOS è impiegato in produzione da service provider, IXP, operatori di data center e piattaforme di cloud sovrano in Europa, Nord America, APAC ed EMEA. Per maggiori informazioni visitare ipinfusion.com.