NIS2 Names MSPs and MSSPs as Annex I Essential Entities — The Obligations That Cannot Be Delegated to Clients

Why MSPs and MSSPs Are Annex I Essential Entities

The SolarWinds breach of December 2020 did not start with a direct attack on a government network. It started with a malicious update to Orion, a trusted IT management platform used by organisations worldwide. Approximately 18,000 organisations installed that update before the backdoor was detected — months after it had first been deployed. In July 2021, the Kaseya VSA incident followed the same logic: by exploiting a vulnerability in a single remote monitoring and management platform, REvil reached approximately 1,500 downstream organisations across roughly 60 MSPs without touching a single client network directly.

These incidents did not merely demonstrate that MSPs are high-value targets. They demonstrated why MSPs are high-value targets: the trusted access that allows an MSP to maintain, monitor, and respond to client environments is precisely the access an attacker wants. One successful MSP compromise multiplies into dozens or hundreds of simultaneous breaches. This is the structural reasoning behind NIS2’s decision to classify managed service providers and managed security service providers (MSSPs) as Annex I entities — the same tier as hospitals, energy networks, and financial market infrastructure.

This guide covers what Annex I classification means for your registration and penalty exposure, which Article 21 obligations apply differently to the MSP operating model, the specific technical controls CIR 2024/2690 introduces for remote management tooling, how dual notification obligations work when your breach cascades to client environments, and how MSSPs are converting compliance into a service line.

Annex I Classification: Essential or Important?

NIS2 Annex I lists sectors whose entities qualify as essential entities if they meet certain size thresholds. Among those sectors is one titled ICT service management (B2B), which contains two directly relevant subsectors.

Article 6(35) of the directive defines a managed service provider as an entity providing services related to the installation, management, operation, or maintenance of ICT products, networks, infrastructure, applications, or any other network and information system component on the basis of a contract. Article 6(36) defines a managed security service provider as an MSP that specifically delivers cybersecurity risk management activities. Both subsectors sit in Annex I — not Annex II — which means large providers are classified as essential entities regardless of which sector their clients operate in.

For a full overview of NIS2 scope and sector classifications, see the NIS2 scope and size threshold guide.

Criteria	Essential Entity	Important Entity
Employees	250 or more	50 to 249
Annual turnover	Over €50 million	€10 million to €50 million
Balance sheet total	Over €43 million	€10 million to €43 million
Maximum penalty	€10 million or 2% of global annual turnover	€7 million or 1.4% of global annual turnover
Supervisory model	Proactive, ex-ante supervision	Reactive, ex-post supervision

Classification as essential or important is based on the MSP’s own size — not the size of the clients it serves. An MSP with 80 employees and €15 million in annual turnover serving large enterprises is an important entity. It carries all Article 21 obligations; only the penalty ceiling and supervisory intensity differ.

Non-EU MSPs with clients in EU member states must designate a representative in the member state where they serve the largest share of their EU clients and register with that state’s National Competent Authority. The registration obligation is active: entities cannot wait for a regulator to contact them.

Five Article 21 Obligations the MSP Operating Model Cannot Delegate

Article 21 of the NIS2 Directive requires essential and important entities to implement appropriate and proportionate technical, operational, and organisational measures across ten cybersecurity domains. Every entity subject to NIS2 faces these obligations — but the MSP operating model creates implementation requirements that generic entity guidance does not address. Five of the ten measures apply with specific force to providers managing client environments.

Supply chain security — Article 21(2)(d)

This measure covers the security of supply chain relationships with direct suppliers and service providers. For an MSP, this obligation operates in two directions simultaneously. The MSP must assess its own upstream suppliers — RMM vendors, PSA platforms, cloud providers — while also accepting that its clients are legally required to treat the MSP itself as a critical supplier to be assessed. Article 21(2)(d) makes the MSP both auditor and audited. The NIS2 supply chain security guide covers the client-facing assessment process in detail.

Access control and asset management — Article 21(2)(i)

Human resources security, access control policies and asset management describes the obligation in general terms. For an MSP, access control extends to privileged credentials across every managed client environment. A single PSA credential vault may contain administrative access to hundreds of client tenants. Failing to segregate, rotate, and audit that access at the tenant level is an Article 21(2)(i) violation, not a matter of internal IT preference.

Security in system acquisition and maintenance — Article 21(2)(e)

The tools an MSP uses to deliver services — RMM agents, PSA platforms, remote desktop software — are network and information systems subject to the same security requirements as any other system the entity operates. Article 21(2)(e) requires policies covering vulnerability handling and disclosure for these systems. Kaseya VSA CVE-2021-30116, exploited in the July 2021 REvil attack, was an unpatched RMM tool vulnerability. The obligation to assess and patch MSP tooling is not aspirational; it is an explicit Article 21(2)(e) requirement.

Incident handling — Article 21(2)(b)

MSP incident response cannot be treated as an internal IT function. The potential cascade across dozens of client environments means that an MSP’s incident response capability must include multi-client triage, parallel notification workflows, and pre-defined client communication templates. A single incident may simultaneously trigger Article 23 notification obligations to the MSP’s own regulator and to each affected client.

Multi-factor authentication — Article 21(2)(j)

MFA is explicitly required for remote access and privileged accounts. Every administrative session to a client environment conducted over a network — every RMM connection, every remote desktop session, every cloud console login — is covered. This obligation cannot be deferred to clients or made optional for technicians. It applies to the MSP directly, and it applies to every client environment the MSP accesses.

For a full explanation of all ten Article 21 measures, see the NIS2 requirements overview.

Securing Remote Management Tools: What CIR 2024/2690 Requires

Commission Implementing Regulation (EU) 2024/2690, which entered into force on 17 October 2024, translates Article 21’s broad measures into more than 150 specific technical controls. MSPs and MSSPs fall within its scope as digital infrastructure providers. Section 6 of the CIR covers security in network and information systems acquisition, development, and maintenance — which means the security requirements extend to the tools used to deliver the managed service, not just the client systems being managed.

Most competitor guidance on NIS2 for MSPs stops at the Article 21 level. The CIR is where the specific tooling obligations live.

Vendor security assessment before deployment

MSPs are required to evaluate the security posture of RMM and PSA tool vendors before deploying those tools to access client environments. A vendor’s SOC 2 Type II certification or ISO 27001 certificate provides documented evidence for this assessment. The assessment must be reviewed periodically — onboarding evaluation alone does not satisfy the ongoing vendor risk management requirement.

Unique, isolated credentials per client tenant

Shared administrative accounts across client environments fail the Article 21(2)(i) access control requirement. Each client tenant requires its own credential set stored in a segregated vault partition. This applies to both the PSA password vault and to any API keys or service accounts used by the RMM agent in client environments.

Patch management cadence for tooling itself

The vulnerability management requirement under Article 21(2)(e) applies to RMM agents running on client endpoints. When a vendor releases a security patch for its management tooling — as Kaseya was required to do following CVE-2021-30116 — the MSP’s obligation is to deploy it promptly, not at the next scheduled maintenance window. Delayed patching of tooling that carries privileged access to client environments is the documented attack vector, not a theoretical risk.

Logging and monitoring of tool activity

CIR 2024/2690 Section 9 requires logging of administrative actions. Every privileged action performed through the RMM console — software deployment, policy change, remote session initiation — must generate an auditable log entry attributed to an identified operator with timestamps. Logs must be retained according to the regulation’s specified windows and available on request during regulatory supervision.

Outbound connectivity restrictions

Management traffic from RMM consoles should be restricted to the tool vendor’s known IP ranges. This control targets the vector used in the SolarWinds SUNBURST attack: compromised software that communicated with attacker-controlled servers using traffic that appeared legitimate because it originated from a trusted management platform. Network segmentation and allowlisting of management outbound traffic is a proportionate and practical control that directly mitigates this attack class.

Privileged Access Management for Multi-Tenant Environments

CIR 2024/2690 Section 11 specifies access control requirements including controlling privileged accounts and segregating administration systems. For a single-organisation entity, this typically involves managing a bounded population of privileged users. For an MSP with 200 client tenants, it means managing a privilege estate spanning hundreds of administrative accounts across entirely separate organisations simultaneously.

The practical implication is an architecture requirement, not merely a policy requirement.

Just-in-time access provisioning

Rather than maintaining standing administrative access to all client environments, MSPs should implement just-in-time provisioning: access is granted for the duration of a specific ticket or task, then revoked automatically. This limits the window during which compromised credentials can be exploited. The SolarWinds breach persisted undetected for approximately 14 months in part because standing access to numerous environments went unmonitored. JIT access does not eliminate the risk, but it significantly reduces the blast radius of any credential compromise.

Tenant isolation in the credential vault

Multi-tenant PAM deployments must enforce logical separation between client tenants. A technician assigned to Client A should not have visibility into credentials for Client B’s environment, even if both tenants are stored in the same PAM platform. This satisfies Article 21(2)(i) access segregation and provides a forensic boundary if an incident investigation spans multiple clients.

Session recording for privileged access

Every privileged session to a client environment should generate a session recording alongside the access log. This satisfies the audit trail requirement and provides forensic evidence if a subsequent investigation involves that client’s environment — evidence that will be requested if the MSP is subject to supervisory inspection as an essential entity.

PAM Control	Typical Current State	NIS2-Required State	Implementation Effort
Credential isolation per tenant	Shared vault, partial separation	Logical tenant partitions, zero cross-tenant visibility	Medium
JIT access provisioning	Standing access for all engineers	Request-and-approve workflow per ticket	High
Session recording	None or partial (RDP sessions only)	All privileged sessions to client environments	Medium
MFA on all client admin sessions	Enforced for cloud consoles; inconsistent for RDP and RMM	Enforced across all access methods without exception	Low to Medium
Access log retention	30 days in RMM console	Minimum 12 months, available to regulators on request	Low

Dual Notification Obligations: When Your Breach Becomes Your Clients’ Breach

Article 23 of the NIS2 Directive establishes a three-stage notification process for significant incidents. Within 24 hours of becoming aware of a significant incident, the entity must submit an early warning to its national competent authority (NCA) or CSIRT. Within 72 hours, an incident notification including an initial assessment of impact, severity, and potential cross-border effects is required. A final report with full incident description, root cause analysis, and remediation steps follows within one month.

For most NIS2 entities, this framework applies to incidents affecting their own services. For MSPs, it applies with an additional dimension: NIS2 requires that impacted recipients be notified without undue delay. When an MSP incident affects client environments, each affected client must be notified — concurrently with, not after, the regulatory notifications.

In practice, a significant MSP incident triggers obligations across multiple tracks simultaneously:

• The MSP’s own early warning to its CSIRT or NCA within 24 hours
• Direct notifications to each client whose data, service continuity, or network security was affected — without undue delay
• If clients are themselves NIS2 entities, the MSP’s notification to them may trigger those clients’ own 24-hour Article 23 obligations

This cascade demands pre-prepared client notification templates, designated client communication responsibilities within the incident response team, and documented triage criteria for determining which clients are materially affected. An undocumented process at the moment of a multi-client incident — when regulatory deadlines, management liability under Article 20, and reputational exposure converge — is a failure mode that no MSP can afford to reach unprepared.

Article 20 of NIS2 holds management bodies personally responsible for implementing and approving cybersecurity risk management measures. An MSP where the incident response plan does not account for dual notification has a demonstrable gap in the management accountability framework — one that is documentable by supervisory authorities during ex-ante inspection of essential entities.

For full context on NIS2 structure and obligations, see the complete NIS2 directive guide.

MSSPs: Turning NIS2 Compliance into a Service Differentiator

For MSSPs providing SOC-as-a-service, threat detection, or continuous compliance monitoring, NIS2 creates both obligations and commercial opportunities. The compliance burden is real — but so is the structural advantage it creates over providers who have not yet made the same investment.

SOC service integrity

An MSSP whose core service is monitoring client environments for threats must ensure its monitoring infrastructure itself meets Article 21 standards. The MSSP’s SIEM, detection tooling, analyst workflows, and data retention practices are all subject to NIS2 risk management measures. A compromised MSSP SOC is not merely a data breach — it is the simultaneous degradation of security monitoring services for every client. NIS2 supervisors are aware of this systemic risk, and essential-entity supervision of MSSPs reflects it in the proactive inspection regime that applies to Annex I providers.

Compliance evidence as contract value

Clients subject to NIS2 are legally required to conduct supply chain security assessments of their service providers under Article 21(2)(d). An MSSP that is itself NIS2-compliant as an essential entity can provide structured compliance evidence — gap analysis results, policy documentation, incident response capability assessments — that directly satisfies the client’s supply chain assessment obligation. This transforms a regulatory cost into a pre-qualification document that closes procurement cycles faster than any marketing claim.

Differentiation in a commoditised market

Most MSPs offer broadly similar remote monitoring and management capabilities. Demonstrable NIS2 essential-entity compliance — documented Article 21 policy framework, CIR 2024/2690-aligned tooling controls, tested incident response capability — provides a concrete differentiator that clients in finance, healthcare, and public sector procurement increasingly treat as a minimum requirement rather than a bonus. The window to distinguish compliant from non-compliant providers is narrowing as national supervisory authorities increase enforcement activity through 2025 and 2026.

MSSPs that package compliance reporting as a managed service — regular Article 21 posture assessments, Article 23 notification preparedness audits, supply chain assessment assistance for clients — create recurring revenue tied to the client’s regulatory cycle rather than commodity monitoring contracts subject to annual renegotiation.

Frequently Asked Questions

Does NIS2 apply to non-EU MSPs serving EU clients?

Yes, if the MSP meets the size thresholds and provides services to entities established in EU member states. Non-EU MSPs must designate a representative in the EU member state where the largest share of their EU clients are based and register with that state’s NCA. The designated representative is an administrative contact point for supervision — it does not absorb the MSP’s liability.

If my clients are NIS2 entities, does that automatically put me in scope?

Not automatically. Your NIS2 obligations as an MSP or MSSP arise from Annex I classification as an ICT service management (B2B) provider meeting the size thresholds, not from your clients’ classification. However, clients who are NIS2 entities must assess you as part of their Article 21(2)(d) supply chain obligations, which creates indirect contractual pressure regardless of your own registration status.

What is the difference between being a direct NIS2 entity and being part of a client’s NIS2 supply chain?

As a direct NIS2 entity, you are regulated — subject to registration, supervision, Article 21 obligations, and penalties. As part of a client’s NIS2 supply chain, you are not directly supervised by the regulator, but the client is required to contractually impose security requirements on you and assess your compliance periodically. Many MSPs will be both: directly regulated as Annex I entities and contractually assessed by clients who are themselves NIS2 entities.

When must I notify my clients of a security incident?

NIS2 requires notification to impacted recipients without undue delay. In practice, client notification should run concurrently with your 24-hour early warning to your CSIRT — not after regulatory obligations are satisfied. Clients who are themselves NIS2 entities may then face their own 24-hour notification obligation triggered by your notification. Pre-defined client communication templates and designated notification responsibilities within your incident response team are practical necessities, not optional enhancements.

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.

Sources

1. Directive (EU) 2022/2555 of the European Parliament and of the Council (NIS2 Directive) — EUR-Lex: eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32022L2555
2. Kaseya VSA ransomware attack — Wikipedia: en.wikipedia.org/wiki/Kaseya_VSA_ransomware_attack
3. SolarWinds hack explained: Everything you need to know — TechTarget: techtarget.com/whatis/feature/SolarWinds-hack-explained
4. NIS2 Essential vs Important Entities Explained — Legiscope: legiscope.com/blog/nis2-essential-important-entities.html
5. NIS 2 Directive, Article 23: Reporting obligations — nis-2-directive.com: nis-2-directive.com/NIS_2_Directive_Article_23.html
6. Commission Implementing Regulation (EU) 2024/2690 — EUR-Lex: eur-lex.europa.eu/eli/reg_impl/2024/2690/oj
7. NIS2 Technical Implementation Guidance — ENISA: enisa.europa.eu/publications/nis2-technical-implementation-guidance