🛠️NIS2 for ICT Service Management (MSP / MSSP) — deadlines, obligations, fines

MSPs and MSSPs must implement the ten minimum measures set by NIS2 Art. 21(2)(a-j): risk and security policies, incident handling, continuity and recovery, supply-chain security, ICT acquisition and development, effectiveness assessment, cyber hygiene and training, cryptography, HR security and access control, MFA [C2]. Specifically for MSPs and MSSPs, Implementing Regulation (EU) 2024/2690 of 17 October 2024 sets out the technical and methodological requirements: the Annex contains 13 thematic sections (security policy, risk, incident handling, business continuity, supply chain, ICT acquisition, detection / monitoring / logging, vulnerabilities, hygiene and training, access control, human resources, asset management, physical security) [C3][C8]. The framework builds on ISO/IEC 27001, ISO/IEC 27002 and ETSI EN 319401 [C2]. The management body approves and oversees implementation (NIS2 Art. 20) [C15].

MSPs and MSSPs occupy a particular position in the supply chain: they are ICT providers to all their customers and at the same time depend on their own providers (RMM, EDR, file transfer, identity provider, hyperscalers). NIS2 Art. 21(2)(d) requires supply-chain security management, including for relationships with direct suppliers [C9]. Section 5 of the Annex to Reg. (EU) 2024/2690 spells out: written supply-chain security policy, supplier assessment before contracting, contractual security clauses, continuous monitoring [C3][C9]. In practice, the MSP must cascade these requirements: any critical sub-supplier (e.g. the RMM tool used across clients, identity provider, credentials vault) must itself sit under a NIS2-aligned contractual regime.

NIS2 Art. 23 sets the milestones: early warning to the national CSIRT (the DNSC team) within 24 hours of awareness of the significant incident, detailed notification within 72 hours, and final report within one month [C4]. For MSPs and MSSPs there is a second dimension: customers affected by the incident must be informed "without undue delay" so they can respond on their side (Recital 86 plus customer-facing notification obligations derived from contracts and Art. 21(2)(d)) [C6]. CISA and NCSC-UK have called in a joint advisory for MSPs to maintain contractual clauses transparently identifying ICT responsibilities between the MSP and the customer [C10]. In practice, an MSP must run two channels: one to DNSC, one for cascading notification to customers.

An MSP/MSSP serving multiple customers from a single centrally managed tenant must demonstrate operational isolation: separation of privileged access per customer, per-tenant segmented logging, distinct identities for MSP operators when acting on customer systems, mandatory MFA on any inter-tenant access [C10]. Reg. (EU) 2024/2690 Section 10 (access control) and Section 7 (detection / monitoring / logging) require adequate access-control and logging policies; for an MSP this means per-customer logging with sufficient retention to support "blast radius" investigations [C3][C8]. Advisory AA22-131A recommends disabling inactive accounts and mandatory MFA on MSP accounts with access to customer environments, plus monitoring of failed authentication attempts [C10].

When an MSP incident hits tens or hundreds of customers at once (the typical Kaseya, MOVEit, 3CX pattern), the continuity plan stops being an internal problem and becomes a coordinated response across N organisations. Sections 3 and 4 of the Annex to Reg. (EU) 2024/2690 require written incident-handling policies (Section 3) and continuity and crisis-management policies (Section 4), with periodic testing [C3][C8]. For an MSP/MSSP, that means tabletop scenarios that explicitly cover "our build / our RMM / our portal has been trojanised", a kill-switch procedure to stop automated propagation, and a communication plan running in parallel to all customers at once. The lessons from incidents I1-I4 (SolarWinds, Kaseya, MOVEit, 3CX) show that firms which did not actually test the "cascade" scenario reacted with days or weeks of delay.

Type: Software supply chain attack (Sunburst); attributed to APT29 / SVR (Russia)

Impact: ~33.000 clienti Orion au primit comunicarea SolarWinds; ~18.000 au avut o instalare cu vulnerabilitate; un subset mult mai mic a fost compromis activ ulterior (agentii guvernamentale SUA, FireEye, Microsoft etc.). CISA a emis Emergency Directive 21-01 pe 13 dec 2020 obligand decuplarea sistemelor afectate.

Lesson: The supplier's software build became the vehicle for ~18 000 trojanised installs distributed as a legitimate update. NIS2 Art. 21(2)(d) and (e), together with Reg. (EU) 2024/2690 Sections 5-6, require ICT acquisition security policies and controls on the integrity of the development and delivery pipeline.

Type: REvil ransomware exploiting zero-day CVE-2021-30116

Impact: Aprox. 60 de MSP-uri compromise direct prin VSA on-premises; ~1.500 organizatii downstream criptate (clientii MSP); cerere de rascumparare initial 70 mil. USD, redusa apoi la 50 mil. USD. Atacul a coincis cu weekend-ul de 4 iulie.

Lesson: The RMM tool used daily by MSPs (Kaseya VSA) turned into a simultaneous encryption vector for their customers. Operational takeaway: any privileged tool used transversally across customers needs an aggressive patching pipeline, per-tenant isolation, and the operational capability to halt propagation instantly.

Type: Zero-day SQL injection exploit CVE-2023-34362; LEMURLOOT web shell for exfiltration

Impact: Pana la 19 iulie 2023: 383 organizatii si peste 20 milioane persoane afectate (Emsisoft). Cascade prin furnizori downstream: Zellis (payroll) -> British Airways, BBC, Boots. CISA si FBI au emis joint advisory AA23-158A.

Lesson: A product (MOVEit Transfer) used by a single downstream vendor (Zellis) exposed dozens of large organisations. NIS2 Art. 21(2)(d) and Reg. (EU) 2024/2690 Section 5 require continuous monitoring of critical suppliers and testing of the scenario in which your tier-2 supplier becomes the attack vector.

Type: Double supply chain attack; attributed to Lazarus (North Korea, UNC4736)

Impact: 3CX raporteaza ~600.000 clienti corporativi si ~12 milioane utilizatori in aerospatial, sanatate, ospitalitate, finante. Aplicatiile desktop (Win + macOS) au fost livrate cu cod malitios; backdoor secundar Gopuram livrat la tinte selectate (cripto). Compromiterea initiala a venit prin software-ul tert Trading Technologies — un atac "double-hop" pe lantul de aprovizionare.

Lesson: Your supplier is compromised through its own supplier. NIS2 Art. 21(2)(e) requires security across the acquisition, development and maintenance life cycle, including indirect dependencies; the CRA, Reg. (EU) 2024/2847, introduces SBOM and active vulnerability reporting for products with digital elements [C11].

Reg. (UE) 2024/2690 — cerinte tehnice si metodologice NIS2 pentru MSP, MSSP si infrastructura digitala · Directly applicable from 17 October 2024; no national transposition required [C3]

For MSPs and MSSPs, this is the reference text operationalising Art. 21(2) NIS2. The 13-section Annex (policy, risk, incidents, continuity, supply chain, ICT acquisition, detection / monitoring / logging, vulnerabilities, hygiene, access control, HR, assets, physical security) is the checklist DNSC will use during inspections [C3][C8]. ENISA published in 2025 a technical implementation guide with evidence examples and mapping to ISO/IEC 27001 and ETSI EN 319401 [C2].

DORA — Reg. (UE) 2022/2554 · Directly applicable from 17 January 2025 [C12]

Once an MSP or MSSP signs a contract with a financial entity (bank, insurer, pension fund, fintech), it automatically falls within DORA Chapter V (Art. 28-30): standardised contractual clauses, customer-side ICT third-party register (template per Reg. (EU) 2024/2956), concentration assessment. Where the provider is designated a Critical ICT Third-Party Provider (CTPP) by the ESAs (EBA + ESMA + EIOPA), it falls under direct European oversight [C12]. The list of designated CTPPs is published annually by the ESAs.

CRA — Reg. (UE) 2024/2847 (Cyber Resilience Act) · In force since 10 December 2024; fully applicable from 11 December 2027; Art. 14 (vulnerability reporting) from 11 September 2026 [C11]

MSPs and MSSPs that develop or redistribute products with digital elements (their own EDR agents, custom RMM tools, commercial integrations) fall under the CRA as manufacturers or importers. Key requirement: mandatory SBOM, reporting of active vulnerabilities to ENISA and the national CSIRT within 24 hours, vulnerability handling across the product's life cycle [C11]. The CRA stacks with NIS2 — it does not replace it.

ISO/IEC 27001:2022 si ISO/IEC 27036 · Voluntary standards; used as baseline for demonstrating compliance with Reg. (EU) 2024/2690 [C2]

Reg. (EU) 2024/2690 requires measures to be aligned with ISO/IEC 27001 and ISO/IEC 27002 [C2]. For the supply chain, ISO/IEC 27036 (Information security for supplier relationships) is the operational reference. In DNSC practice, ISO/IEC 27001 certification significantly reduces the effort of demonstrating compliance, but is not in itself sufficient — the DNSC audit is against the text of Reg. (EU) 2024/2690.

CISA / NCSC-UK Joint Advisory AA22-131A — protejarea MSP · Non-legal document, but an international reference (Five Eyes) [C10]

Joint advisory of 11 May 2022 issued by CISA, FBI, NSA, NCSC-UK, ACSC (Australia), CCCS (Canada) and NCSC-NZ. Concrete recommendations for MSPs and their customers: mandatory MFA on every MSP account with access to the customer environment, deactivation of unused accounts, contractual clauses explicitly identifying ICT responsibilities [C10]. It is the operational reference frequently cited in EU audits and contracts.