Managed Service Providers (MSPs) are explicitly classified as essential entities under NIS2 — placed in the ICT service management sector of Annex I. This makes MSPs one of the highest-obligation categories under the directive. The reason is clear: a compromised MSP has access to the systems of dozens or hundreds of customers, making the systemic risk disproportionately large.
This article covers what NIS2 requires from MSPs specifically and what compliance looks like in practice.
Why MSPs Were Specifically Added to NIS2
NIS1 did not specifically cover MSPs. The gap was exposed in high-profile supply chain attacks — including the Kaseya attack (2021), which compromised an MSP platform and spread ransomware to over 1,500 businesses through a single attack vector.
NIS2 closed this gap. MSPs providing managed services to essential or important entities are:
- Classified as essential entities under Annex I
- Subject to proactive supervision and regular audits
- Required to meet the highest NIS2 security standards
- Personally accountable at the management body level
What Counts as an MSP Under NIS2?
The directive uses the term "managed service providers" and "managed security service providers" as a category under ICT service management. The definition covers:
- Providers of ongoing management of IT infrastructure (networks, systems, endpoints) for customer organisations
- Providers of remote monitoring and management (RMM) services
- Help desk and IT support service providers with privileged access to customer systems
- Managed security service providers (MSSPs) offering monitoring, SOC, or incident response services
- Cloud service management companies managing third-party cloud environments for customers
The key indicator: you have privileged access to customer systems and networks.
Security Requirements for MSPs
As essential entities, MSPs must implement all Article 21 security measures, applied to the specific risks of managed services:
Access and Identity Management
MSP technicians have privileged access to customer environments. This creates specific requirements:
- MFA required for all technician access to customer systems — no exceptions
- Just-in-time (JIT) privileged access — credentials granted on demand, not standing
- All privileged access sessions logged, with activity monitoring
- Customer access credentials stored in a privileged access management (PAM) vault — not in spreadsheets, email, or standard password managers
- Immediate access revocation when technician leaves or customer relationship ends
Segregation of Customer Environments
- Customer environments must be logically segregated — a breach in one customer environment must not cascade to others
- Management plane segregation — RMM and monitoring platforms must be configured to prevent one customer admin from viewing or accessing another customer's data
- No shared credentials between customer environments
RMM Platform Security
The RMM platform is the most critical attack vector for MSP-related supply chain attacks:
- MFA on all RMM platform accounts — including customer portals
- Regular security audits of RMM platform configurations
- Monitor for anomalous access patterns (bulk script deployment, unusual data access)
- Maintain current patch status for all RMM agents
Vulnerability Management
MSPs must maintain patch currency across customer environments:
- Defined SLAs for critical patch deployment (typically within 72 hours for critical patches)
- Documented patch exception process for systems that cannot be patched
- Regular vulnerability scanning of all managed customer environments
Incident Response and Reporting
When an MSP suffers a security incident, the notification obligation covers the MSP's own national CSIRT and also notification to affected customers.
Specific MSP incident scenarios:
RMM platform compromise: If an attacker gains access to the MSP's RMM platform, this is a major incident affecting all customers potentially. Immediate customer notification is required alongside CSIRT notification.
Technician account compromise: If a technician's credentials are compromised, all customer environments to which that technician had access must be treated as potentially affected. Customer notification begins immediately.
Customer environment breach through MSP access: If an attacker uses MSP access to breach a customer, both the MSP and the customer have NIS2 notification obligations.
Build specific runbooks for each of these scenarios. They will be evaluated in supervisory authority audits.
Supply Chain Security: Your Vendors, Your Responsibility
As an MSP, you have a supply chain of your own:
- Your RMM vendor
- Your PSA (Professional Services Automation) vendor
- Security tool vendors
- Cloud platforms
Your customers' NIS2 compliance programmes hold you responsible for the security of these suppliers. Maintain a documented risk assessment for each critical vendor, and ensure your own supplier contracts include security obligations.
Customer Contracts: What Needs to Change
NIS2 creates new commercial obligations for MSPs. Existing contracts with NIS2 in-scope customers should be reviewed and updated to include:
- Security incident notification within 24 hours of discovery
- Minimum security standards aligned with NIS2 Article 21
- Right for the customer to audit the MSP's security practices
- Sub-processor/sub-contractor disclosure
- Contractual commitment to maintain NIS2-required security measures
Some enterprise customers will renegotiate MSP contracts proactively. Being ahead of this with a NIS2-ready contract addendum is a commercial advantage.