3,136 subscribers

Endpoint Software, Security Agents and the Cyber Resilience Act: What Changes for Vendors and Customers?

3,136 subscribersSubscribed

Antonio Ieranò

Information & Cybersecurity Strategist | Digital Sovereignty • AI Governance • Complex Systems | Author, Researcher & Occasional Philosopher | Views stubbornly my own. 🧠

October 6, 2026

The Cyber Resilience Act is often discussed in relation to connected devices, IoT products or consumer hardware. But its scope is broader. It also matters for software.

In particular, it matters for software installed on operating systems: endpoint agents, antivirus, EDR, XDR, VPN clients, device management tools, DLP agents and insider risk monitoring components.

These products are not just “IT tools”. In many cases, they are software products with digital elements, distributed in the EU market, connected to devices, networks, cloud services, update infrastructure or management consoles.

That makes them highly relevant under the CRA.

When does the CRA apply to software?

A useful starting point is this: the CRA applies to products with digital elements made available on the EU market, where their intended or reasonably foreseeable use includes a direct or indirect data connection to a device or network.

That includes software products and software components placed on the market separately.

So the question is not simply: “Does this run on Windows, macOS or Linux?”

The better questions are:

Is this software made available on the EU market?

Is it provided commercially, licensed, bundled or otherwise supplied as part of a digital product or solution?

Does it connect directly or indirectly to a device, network, cloud service, API, update server or management console?

Does it receive updates, configuration or policy from a remote system?

Does it collect telemetry, logs, metadata, behavioral signals or security events?

Does it require elevated privileges on the operating system?

Is it part of a cybersecurity, data protection, endpoint management or IT control function?

If the answer to several of these questions is yes, the product should be assessed carefully under the CRA.

This is especially relevant for endpoint security software.

Antivirus, EDR, XDR, endpoint DLP and insider threat management agents are strong candidates for CRA analysis. They are installed locally, connected remotely, updated over time and often operate with significant privileges. If vulnerable, they can become a systemic risk rather than just another application defect.

The endpoint DLP and insider risk example

Consider an endpoint agent installed on corporate laptops to prevent data loss and detect risky user behavior.

Such an agent may monitor file movement, removable media activity, uploads, application usage, browser behavior, user actions and other signals linked to data protection or insider risk.

This type of software has a dual relationship with the CRA.

From the vendor side, the agent may be a software component placed on the market as part of a broader security platform. It may depend on a management console, remote policies, cloud analytics, update services and telemetry pipelines. In that case, the vendor should assess whether the product falls within CRA scope and, if so, address secure-by-design requirements, vulnerability handling, security updates, technical documentation, support periods, user instructions and incident or vulnerability reporting obligations.

From the customer side, the same agent does not automatically make the organization “CRA compliant”. It is not a magic compliance layer. But it can become an important control within the customer’s security and product governance program.

For a company that develops or sells digital products, such an agent may help protect source code, product documentation, credentials, secrets, customer data, engineering workstations and sensitive information connected to the product lifecycle.

In other words: for the vendor, it may be the product in scope. For the customer, it may be one of the controls supporting a broader CRA readiness program.

Vendor side: what must be provided?

For vendors, the CRA is primarily a product cybersecurity obligation.

A vendor placing endpoint software, security agents or connected software components on the EU market should be able to provide a clear position on the CRA status of the product.

Customers should not have to rely on vague statements such as “we are secure” or “we take compliance seriously”. They need product-level evidence.

At a minimum, vendors should be ready to provide:

A clear statement on whether the product is considered in scope of the CRA.

The vendor’s role: manufacturer, importer, distributor or another relevant economic operator.

The product classification and rationale.

The EU declaration of conformity, where applicable.

CE marking, where applicable.

The declared support period.

The security update policy.

The vulnerability disclosure policy.

A channel for vulnerability reporting.

A description of the vulnerability handling process.

Information on how actively exploited vulnerabilities and severe incidents are handled and notified.

User instructions and secure configuration guidance.

Supported platforms and system requirements.

Documentation on required privileges and operating system permissions.

Information on remote connections, update mechanisms and management consoles.

A description of data collected, processed, stored or transmitted.

Information on relevant third-party components, dependencies or SBOM-related artefacts where applicable or contractually agreed.

Contractual commitments on support, patching, security notifications and incident cooperation.

For endpoint products with elevated privileges, vendors should be even more explicit. They should explain what the agent installs, how it updates, how communications with the console are secured, how authentication and certificates are managed, what data remains local, what data is sent remotely and how emergency fixes are delivered.

Customer side: what must be verified?

Customers are not usually responsible for the vendor’s CRA conformity. But they are responsible for procurement, configuration, governance and operational risk.

A customer buying endpoint software, antivirus, EDR, XDR, DLP or insider risk tooling should verify the vendor’s CRA position before relying on the product in a regulated or product-critical environment.

The customer should check whether the software may fall within the CRA scope, whether the vendor has taken a clear position, and whether the available documentation is sufficient for internal risk, procurement and audit needs.

Key customer checks include:

Has the vendor stated whether the product is in scope of the CRA?

Has the vendor identified its role and responsibilities?

Is there a declaration of conformity where applicable?

Is the support period clear?

Are security updates available throughout the declared support period?

Is there a vulnerability disclosure process?

Are patching and notification timelines contractually clear?

Are supported operating systems and versions documented?

Are secure configuration instructions available?

Are admin roles, privileges and access controls well defined?

Are logs and audit trails available and exportable?

Are data flows, telemetry and remote processing clearly documented?

Are third-party dependencies and critical components visible enough for risk assessment?

Does the product fit the customer’s own incident response process?

Can the customer evidence that the product was selected, configured and governed appropriately?

The customer does not need to redo the vendor’s conformity assessment. But the customer should avoid blind procurement.

This is particularly important when the customer is itself a manufacturer of digital products. In that scenario, endpoint security tools are part of the environment that protects product development, maintenance, vulnerability handling and incident response.

Where the line should be drawn

The cleanest way to separate responsibilities is this:

The vendor is responsible for the conformity of the product it places on the market.

The customer is responsible for selecting, configuring and governing the product appropriately within its own environment.

The vendor must design, document, maintain and update the product securely.

The customer must verify that the vendor provides sufficient evidence, that the product is fit for purpose, and that its internal use does not create unmanaged risk.

Buying a security product does not transfer CRA compliance to the customer.

But choosing and governing the right security products can become part of the customer’s evidence that cybersecurity risks are being managed across the product lifecycle.

A practical rule

For software installed on operating systems, start with this practical assumption:

If the software is commercially distributed in the EU, installed on endpoints or enterprise systems, connected to remote services, updated over time and used for a relevant digital or cybersecurity function, it should be assessed under the CRA.

This is especially true for endpoint security software such as antivirus, EDR, XDR, endpoint DLP and insider threat management agents.

The CRA makes one thing clear: software security is no longer only an internal engineering matter. It is becoming a product accountability issue.

For vendors, that means evidence, lifecycle management and vulnerability handling.

For customers, it means better questions, stronger procurement and clearer governance.

The most useful question is no longer:

“Are you compliant?”

It is:

“What is your CRA position for this product, what obligations do you assume as the vendor, and what evidence can you provide?”