EU Cyber Resilience Act Guide for Managed Service Providers with On-Premises Software
Important — Class I or Class II; RMM tools with broad system access likely Class II
Managed service providers (MSPs) who develop and distribute their own on-premises software products — including remote monitoring and management (RMM) tools, professional services automation (PSA) software, backup agents, and security management platforms — are manufacturers under the CRA and must comply with all applicable obligations. MSP tooling occupies a privileged position in customer IT environments, making it a high-value target for supply chain attacks. The CRA's security requirements are particularly pertinent for MSP software given the cascading risk that a compromise of MSP tooling poses across the entire customer base.
CRA Scope and Classification for MSP Software Products
MSPs who develop and commercially distribute software installed on customer systems — including RMM agents, backup clients, security monitoring sensors, patch management agents, and PSA integrations — are manufacturers of products with digital elements under Article 3(1). The CRA applies to each distinct software product placed on the EU market, regardless of whether it is sold as a standalone licence or bundled within a managed service offering. Classification for MSP tooling requires particular attention: RMM agents with broad administrative access to customer systems — including the ability to execute commands, deploy software, and access configuration data across managed endpoints — are strong candidates for Class II Important Products under Annex III, given the systemic risk they present. The 2021 Kaseya VSA attack, which compromised MSP tooling to deploy ransomware across thousands of customer organisations, illustrates exactly the risk profile that Annex III captures.
Technical Security Obligations: MSP Tooling Attack Surface
MSP software agents installed on customer endpoints represent one of the highest-privilege, most widely-deployed software categories in enterprise IT. Annex I requirements for MSP software manufacturers include: implementing authenticated and encrypted communications between agents and management consoles, with certificate validation preventing man-in-the-middle interception; eliminating shared agent authentication credentials — each managed device should authenticate individually; enforcing code signing on all software components and updates deployed through the MSP platform; implementing least-privilege principles for agent operation, requesting only the permissions required for each specific function; providing comprehensive audit logging of all agent actions on managed endpoints; and supporting a mechanism for customers to verify the integrity of the software installed on their endpoints. The SBOM must cover the agent software, its update mechanism, and all third-party libraries embedded in the agent.
CVD Policy Under Article 13: Supply Chain Implications
Article 13 requires a published CVD policy. For MSP software vendors, the CVD programme carries amplified importance because a single vulnerability in RMM or backup software can be exploited across thousands of customer environments simultaneously. The CVD policy must: establish a dedicated security reporting channel monitored continuously; specify accelerated response timelines for vulnerabilities that could enable supply chain attacks (authentication bypass, remote code execution, privilege escalation); define the process for coordinating with national CSIRTs when a vulnerability has multi-customer impact; and establish how customers are notified of available security updates with appropriate urgency. Because MSP customers are themselves IT service providers with their own security obligations to end clients, the CVD policy's customer notification obligations cascade through multiple layers. MSPs providing NIS2-regulated services must also align their CVD programme with their NIS2 incident reporting obligations.
Article 14 Incident Reporting: Multi-Customer Impact Scenarios
For MSP software vendors, Article 14's 24-hour notification obligation takes on particular urgency when a vulnerability is exploited because exploitation typically affects not one customer but potentially thousands. The notification to the relevant national CSIRT must communicate the potential scale of impact — the number of MSPs using the software and the number of end-customer environments potentially exposed. This scale information is critical for the CSIRT to make appropriate decisions about broadcasting alerts and activating coordinated response. Vendors must have mechanisms to rapidly identify the number and location of active deployments to support this notification. The 24-hour window for an MSP supply chain incident is extremely tight given the response coordination required — pre-positioned incident response resources and pre-written notification templates are essential.
Conformity Assessment for MSP Platform Software
RMM tools and other MSP software qualifying as Class II Important Products require notified body assessment. For MSP vendors developing software distributed to EU MSP partners who then deploy to end customers, the original software developer is the manufacturer for CRA purposes. The notified body assessment must cover the full software development lifecycle, including: secure coding practices; build pipeline integrity controls preventing supply chain compromise; software signing and update delivery security; vulnerability management procedures; and incident response capability. Class I MSP software may use self-declaration, but the technical file requirements are identical in scope to Class II, differing only in who performs the assessment. ISO 27001 and SOC 2 Type II certifications provide supporting evidence but do not substitute for CRA-specific conformity documentation.
CVD Portal handles your CRA Article 13 obligations automatically.
Public CVD submission portal, 48-hour acknowledgment tracking, Article 14 deadline alerts, and CSAF advisory generation. Free forever for Managed Service Providers with On-Premises Software.
Start your free portalFrequently asked
We develop our RMM software and sell it exclusively to other MSPs who then use it to serve their clients. Who is the manufacturer for CRA purposes?+
You are the manufacturer for CRA purposes — you develop and commercially distribute the software product. The MSPs who purchase and use your software are end users for CRA purposes, not manufacturers (unless they modify the software substantially). Your CRA obligations — Annex I security requirements, CVD policy, Article 14 notification, CE marking — apply to your RMM product regardless of the distribution channel. Your MSP customers benefit from your CRA compliance as it provides them with evidence for their own supply chain security obligations under NIS2 and any customer procurement requirements.
Our RMM agent is updated automatically and frequently — sometimes daily. Do we need to compile a new technical file with each update?+
The technical file must be maintained and kept current throughout the product support period — you do not need to compile a new complete file for every update, but you must update the SBOM, security testing evidence, and vulnerability management documentation to reflect significant changes. Your secure development lifecycle documentation should describe how security is maintained across update cadences. For frequent automated updates, the technical file should document the CI/CD pipeline security controls — code signing, SBOM regeneration, automated vulnerability scanning — that ensure each update meets Annex I requirements. Material changes to security-relevant product architecture or functionality should be documented as amendments to the technical file.
One of our MSP customers was breached using a zero-day in our backup agent. Are we liable under the CRA?+
The CRA does not create a private liability regime — market surveillance authorities can impose corrective measures and penalties, but the regulation does not establish a customer claim against the manufacturer for breach damages. However, if you were aware of the vulnerability and failed to issue a security update without undue delay, or failed to notify the CSIRT under Article 14, you would face regulatory enforcement. If a zero-day was genuinely unknown to you and was not the result of inadequate security testing, your liability under the CRA is limited to your obligations once you become aware of it — you must then notify, patch, and communicate to customers promptly. Your technical documentation demonstrating that security testing was conducted according to the CRA technical file requirements provides important evidence of diligence.
Compliance checklists for your products
Key CRA articles for Managed Service Providers with On-Premises Software
Need a CVD policy template for Managed Service Providers with On-Premises Software?
Download a free CRA-compliant vulnerability disclosure policy and deploy it in minutes.