Cyber Resilience Act and Video Conferencing: Scope and Compliance

Across Europe, regulatory expectations for digital products are changing fast. Security is no longer treated as an optional feature or a competitive differentiator. It's becoming a baseline requirement built into how software is designed, delivered, and maintained.

The Cyber Resilience Act (CRA) is one of the most significant steps in this direction. It strengthens the security of connected products across the EU market by setting clear obligations for manufacturers and software providers. The regulation entered into force on 10 December 2024. Manufacturers will need to start reporting actively exploited vulnerabilities to ENISA from 11 September 2026, and full compliance with all requirements is required by 11 December 2027.

For organisations building or deploying communication platforms, this article explains the regulatory context, outlines what compliance involves, and clarifies which types of products and services actually fall within scope.

Table of contents 

Why cybersecurity matters for video conferencing
What is the Cyber Resilience Act?
CRA compliance: core requirements
Implementation support and compliance readiness
How Digital Samba aligns with CRA principles
Conclusion
FAQ

Why cybersecurity matters for video conferencing

Video conferencing platforms are central to how many organisations operate. They're used in education, healthcare, legal proceedings, and corporate collaboration, which means they handle a substantial amount of sensitive data.

Communication platforms process:

• Audio and video streams
• Personal and sensitive information
• Metadata about participants and interactions

That makes them attractive targets for attackers. The specific challenges include protecting real-time media from interception, preventing unauthorised access to sessions, securing recordings and transcripts, and making sure data is handled in line with applicable regulations. Regulations like the CRA are designed to address these risks systematically, rather than leaving each organisation to work through them on its own.

What is the Cyber Resilience Act?

The CRA is a regulatory framework designed to ensure that digital products are secure throughout their lifecycle. It applies to hardware and software products that are connected to networks, including applications used in enterprise and consumer environments.

The regulation shifts responsibility towards manufacturers and software providers. Rather than relying on users or organisations to secure the systems they buy, it requires that products are built securely from the start and maintained with ongoing attention.

The regulation is built around four core principles:

• Security by design and by default. Security controls must be integrated from the earliest design stages and enabled automatically, rather than bolted on later or left optional.
• Continuous vulnerability management. Organisations must actively monitor, identify, and address vulnerabilities throughout the product's entire lifecycle, not just at launch.
• Transparency in how products handle security risks. Users and stakeholders should have clear information about how risks are identified, disclosed, and managed.
• Accountability across the product lifecycle. Responsibility for security doesn't end at deployment. It extends through updates, support periods, and eventual retirement of the product.

European digital policy has been moving in this direction for some time, treating trust, transparency, and data protection as baseline requirements rather than optional extras.

CRA scope and coverage

What the CRA covers (and what it doesn't)

This is where many summaries of the CRA go wrong, so it's worth being direct.

The CRA is a product regulation. It targets 'products with digital elements', meaning hardware and software sold as discrete products and placed on the EU market. It is not a services regulation.

Pure SaaS platforms are generally excluded from CRA scope. A video conferencing service delivered entirely via a browser or API, with no local installation, falls outside the regulation as written. The European Commission's stated reason for this is that pure SaaS providers are already covered by NIS2, a separate directive focused on cybersecurity obligations for digital service providers and operators of essential services.

The one exception is narrow: a cloud-based service falls within CRA scope when it is essential to the functioning of a hardware or embedded product, and it was developed by the manufacturer of that product. Think of a smart device that can't work without its companion cloud service. That cloud service is within scope because it's inseparable from the product itself. A standalone video conferencing SaaS doesn't meet that definition.

So the CRA is most directly relevant to vendors selling software products with local installation or hardware components. For organisations that are simply deploying a third-party SaaS tool, the more applicable frameworks are NIS2 and GDPR.

That said, the CRA's principles (secure-by-design development, lifecycle security, vulnerability management) represent good practice regardless of which regulation applies. And for any organisation that does develop software products with digital elements, the obligations below will apply from December 2027.

Products the CRA does cover

For products that fall within scope, the regulation applies broadly:

• Software applications delivered locally or via the cloud that are integral to a product with digital elements
• Connected devices and IoT products: physical devices with embedded software that connect to networks, such as smart sensors, cameras, or wearables
• Components integrated into larger systems, including individual software modules or libraries that form part of a broader product

Software lifecycle obligations

The CRA takes a lifecycle view of security. Obligations don't end when a product ships.

Manufacturers must embed security considerations throughout development, from initial architecture through to testing and deployment. Products must be monitored for newly discovered vulnerabilities. Identified weaknesses need to be patched promptly. And manufacturers must clearly state how long a product will receive security updates.

Supply chain considerations

The regulation also sets expectations around supply chain security. Manufacturers are expected to have visibility into the components their software relies on, assess third-party libraries for security risks and maintenance status, and ensure that their suppliers follow recognised security practices.

One important nuance here: non-commercial free and open-source software is exempt from the CRA. Projects that are freely accessible, modifiable, and redistributable but not part of a commercial offering fall outside the regulation's scope. However, when open-source components are used in a commercial product, the manufacturer of that product remains responsible for the security of those components. So the exemption applies to the open-source project itself, not to everyone who uses it.

CRA compliance: core requirements

For manufacturers of in-scope products, achieving compliance means aligning internal processes with a set of defined security expectations. These requirements aren't purely technical; they also cover governance, documentation, and operational practices.

• Secure development practices. Manufacturers are expected to implement secure development methodologies: threat modelling during design, secure coding standards, code reviews and testing procedures, and security integrated into CI/CD pipelines. The aim is to reduce vulnerabilities before products reach the market.

• Vulnerability handling. A central requirement is the ability to detect, manage, and disclose vulnerabilities. This means establishing a coordinated vulnerability disclosure process, monitoring for newly discovered threats, responding within defined timeframes, and communicating clearly with users and stakeholders.

• Documentation. The regulation puts a premium on transparency through documentation. Manufacturers must maintain technical documentation describing security features, instructions for secure configuration and use, and records of risk assessments and mitigation measures. This supports both internal accountability and external verification.

• Risk management. Risk management under the CRA is continuous. It means identifying potential threats and attack vectors, assessing likelihood and impact, implementing mitigations, and reviewing assessments over time.

CRA certification and conformity expectations

Certification vs self-assessment

Not all products need third-party certification. The CRA uses a risk-based approach:

• Default products can follow a self-assessment process.
• Higher-risk products (Class I) may use self-assessment if harmonised standards are applied; otherwise, third-party assessment is required.
• The highest-risk products (Class II) require mandatory third-party assessment by a notified body.

Market access and penalties

Compliance is tied directly to market access. Products that don't meet CRA requirements from December 2027 can be restricted from distribution within the EU, face scrutiny from regulators, and carry reputational risk.

The financial penalties are significant. Violations of the essential cybersecurity requirements or the main manufacturer obligations can result in fines of up to EUR 15 million or 2.5% of worldwide annual turnover, whichever is higher. Violations of other obligations carry fines of up to EUR 10 million or 2% of global turnover.

For organisations in regulated sectors, this makes alignment with CRA requirements a practical business concern, not just a compliance exercise.

Conformity labelling

The CRA introduces labelling to signal conformity. These labels tell customers and procurement teams that a product meets the security requirements, support informed purchasing decisions, and make it easier to compare products on a common standard.

Implementation support and compliance readiness

Preparing for CRA compliance requires both technical and organisational readiness. Practical steps include conducting a gap analysis against the requirements, reviewing development and deployment processes, mapping software dependencies and supply chain risks, setting up vulnerability management workflows, and updating documentation and governance frameworks.

For many organisations, external expertise can speed this up. Codific provides structured guidance on CRA implementation strategies, helping organisations translate requirements into actionable steps. Their current compliance resources are available at complycra.eu/cyber-resilience-act-compliance/.

How Digital Samba aligns with CRA principles

Digital Samba is a European video conferencing platform. As a pure SaaS service, the CRA does not automatically apply to it in the same way it would to a manufacturer selling a product with digital elements. Formal conformity assessment and CE marking will only be legally required from December 2027 for products that fall within scope, and no such assessment has been completed at this stage.

What Digital Samba's platform reflects is a development approach that is closely aligned with the CRA's underlying principles: security built in from the start, continuous maintenance, and transparency about how data is handled.

• Privacy-first architecture with European hosting. All data is processed within EU-based infrastructure under European jurisdiction, which supports strict data residency requirements and reduces exposure to conflicting legal frameworks.
• Encryption at multiple layers, including end-to-end. Beyond standard WebRTC transport encryption, Digital Samba implements application-layer end-to-end encryption, so media streams and associated data remain inaccessible to intermediaries, including infrastructure providers.
• Secure development and continuous delivery. The platform follows an iterative release cycle with frequent updates, allowing rapid response to emerging vulnerabilities, consistent with the CRA's expectations for ongoing security maintenance.
• Transparent control over data-generating features. Organisations can choose whether to enable recordings, transcripts, and other data outputs, which supports data minimisation principles and makes compliance easier to manage.
• Role-based access control and secure session management. Granular permissions and authentication mechanisms ensure only authorised users can access sessions and features.
• Operational visibility and configuration. Through its dashboard and API, Digital Samba provides visibility over room configurations, participant behaviour, and feature usage, which supports documentation and audit readiness.

These practices reflect how a video conferencing platform can put the CRA's core concepts (security by design, continuous vulnerability management, lifecycle accountability) into practice. For teams building on top of a video platform, choosing a provider that already follows these principles makes it easier to meet their own security and compliance requirements.

Conclusion

The Cyber Resilience Act changes how digital security is regulated across Europe, and the obligations it introduces are real and, from December 2027, enforceable. For manufacturers of connected products, compliance means building security in from the start, maintaining it over time, and documenting it properly.

For organisations deploying communication platforms, the situation is less straightforward. Pure SaaS platforms fall under NIS2 rather than the CRA, and the two regulations work alongside GDPR rather than replacing it. Understanding which framework applies to your situation is the first step to acting on it.

Security must be built into design, supported through ongoing processes, and documented clearly. That's true whether the obligation comes from the CRA, NIS2, or both. By working with technology partners who already take this approach, organisations can reduce both their security risk and the complexity of meeting the frameworks that govern them.

FAQ

References

1. European Commission. (n.d.). Cyber Resilience Act.
2. Cyber Resilience Act. (n.d.). The CRA explained.
3. European Cyber Resilience Act. (n.d.). Overview and implications.
4. Codific. (n.d.). Cyber Resilience Act compliance guide.