NIS2 and Video Conferencing: Secure Communication Requirements

The crisis call is usually the first thing that matters when an incident starts, and often the last thing anyone has security-reviewed. Under NIS2, that gap is an audit finding. If your organisation is an essential or important entity, the Directive names secured video communication explicitly: the same encryption, access control and resilience expectations that cover the rest of your estate now cover the platform your incident team runs on, and a serious failure of that platform can itself become reportable.

Table of contents

1. What is NIS2?
2. Why NIS2 covers video communication
3. Is your video conferencing provider itself covered by NIS2?
4. The secure-communication requirements for video conferencing
5. NIS2 vs CRA vs DORA: which applies to your video tool?
6. Checklist: is your video conferencing tool NIS2-ready?
7. Penalties for non-compliance
8. How Digital Samba supports NIS2 secure communication
9. FAQ

What is NIS2?

NIS2 is Directive (EU) 2022/2555, the EU's revised cybersecurity law, formally adopted on 14 December 2022 and published in the Official Journal on 27 December 2022 (European Parliament and Council of the European Union, 2022a). It replaced the original 2016 NIS Directive, widened the list of covered sectors from 7 to 18, and required Member States to transpose it into national law by 17 October 2024, with obligations applying from the following day.

The Directive sets a baseline of cybersecurity risk-management measures and incident-reporting duties for 'essential' and 'important' entities across two groups of sectors. The first group covers energy, transport, banking, financial market infrastructure, health, drinking water, waste water, digital infrastructure, ICT service management, public administration, and space: 11 sectors in total. The second group covers postal and courier services, waste management, chemicals, food, manufacturing of critical products, digital providers, and research organisations: another seven, bringing the total to 18. 'Digital providers' here means online marketplaces, search engines and social networking platforms, a narrower category than the digital infrastructure operators in the first group.

Which category an organisation falls into isn't just a matter of which list it sits on. Within the first group, size decides it. Article 2 borrows the EU's standard company-size definitions, and they don't work the way a single 'employees or turnover' test would. Headcount is its own condition, and the two financial figures are alternatives to each other. An organisation counts as medium-sized if it has fewer than 250 staff and either turnover of no more than €50 million or a balance sheet total of no more than €43 million, and as large once it passes those ceilings. Below the small-enterprise floor, fewer than 50 staff with turnover or a balance sheet total of no more than €10 million, an entity generally falls outside NIS2 altogether. Article 3 then applies those size categories within the first group: large organisations are classed as essential, medium-sized ones as important. The two limbs interact awkwardly at the margins, so a borderline organisation should test itself against the definitions rather than reading across from a single figure.

Entities in the second group are treated differently: every one of them counts as important by default, regardless of size.

There's a distinction here that matters more than it sounds: NIS2 is a directive, not a regulation. The Article numbers cited throughout this piece aren't themselves the law you have to comply with. A directive sets a target that each Member State transposes into its own national legislation, and it's that national transposition act, not the Directive text, that a regulator or auditor will apply to you. Transposition has been uneven: several Member States were still working through it well past the October 2024 deadline. NIS2 also runs on a self-identification model: once you've worked out where you stand, you're expected to register your status with your national competent authority rather than wait to be told. Confirm both that authority and which national act applies to you before treating anything else in this article as settled.

Two things distinguish NIS2 from GDPR, which many compliance teams already know well. First, it is about the security of network and information systems rather than personal data specifically, although the two regimes overlap wherever video calls carry personal data. Second, it introduces direct, personal accountability for management bodies (Article 20), alongside fines that scale with global turnover (Article 34).

Why NIS2 covers video communication

Article 21(2)(j) is explicit: alongside requiring multi-factor or continuous authentication, it obliges entities to implement, 'where appropriate', secured voice, video and text communications and secured emergency communication systems. Video calls are where incident response teams coordinate during a live ransomware event, where board members discuss a breach before it is disclosed, and where clinicians, engineers or public officials exchange sensitive operational details. If that channel is compromised, the confidentiality of everything discussed on it is compromised too.

A video conferencing outage can, in some cases, become the 'significant incident' that triggers NIS2's reporting clock in its own right, though the bar in Article 23(3) is a high one: it takes severe operational disruption or financial loss to the entity itself, or considerable material or non-material damage to other people, and it's most likely to be met where the video channel is central to the entity's regulated service (a telehealth platform, say, rather than a manufacturer whose staff simply use video to talk to each other). This is why video conferencing has become a named control area under NIS2, not just a background security line item. It also explains why auditors now ask how meeting platforms are provisioned, as well as how laptops are patched.

Is your video conferencing provider itself covered by NIS2?

Before asking whether your video tool meets NIS2 requirements, check whether your provider is itself an in-scope entity. Annex I of the Directive lists digital infrastructure, and separately, ICT service management (B2B), as sectors covered regardless of the buyer's industry. Cloud computing service providers, data centre operators, content delivery network providers, and managed service and managed security service providers are named explicitly, and Commission Implementing Regulation (EU) 2024/2690 sets out technical and methodological requirements that bind several of these categories directly. A handful of categories, including DNS service providers and qualified trust service providers, are treated as essential entities regardless of size. Whether a given vendor counts as a 'managed service provider' or meets the cloud computing service provider definition isn't always obvious from the outside, and it's worth reading a focused legal analysis of that boundary rather than guessing (Kemp IT Law, 2025).

A video conferencing platform that runs its own infrastructure, rather than reselling someone else's, will often meet the definition of a cloud computing service provider once it crosses the Article 2 size thresholds set out above, with large providers essential and medium-sized ones important in this sector. In practice this means your vendor may be independently obligated under NIS2, which is worth confirming during due diligence. It's useful context rather than compliance credit, though: there's no NIS2 certification scheme to point to the way you might point to a vendor's ISO 27001 certificate, and your vendor's own status doesn't reduce the supply-chain due diligence Article 21 requires of you as the buyer.

The secure-communication requirements for video conferencing

Article 21(2) sets out 10 categories of risk-management measures that essential and important entities must apply, in a proportionate way, based on their size and risk exposure. Several map directly onto how a video conferencing tool is configured and used.

Encryption of audio and video streams

For video, this needs some precision, because 'encrypted' gets used loosely across the industry. Article 21(2)(h) requires policies on the use of cryptography and, 'where appropriate', encryption. WebRTC-based platforms encrypt signalling with TLS and media streams with DTLS-SRTP by default. This is transport encryption: the connection between each device and the server is protected, but the media server itself decrypts and re-encrypts streams as it routes them. That gives the provider technical access to plaintext audio and video during the call. End-to-end encryption (E2EE) is a separate, stronger property: keys are generated on the participant's device and never leave it, so the infrastructure (signalling servers, media servers, and hosting providers) only ever handles ciphertext it cannot read.

NIS2 doesn't mandate E2EE for every call. Article 21(2)(h) sets an 'appropriate' and proportionate standard, so the right control depends on what's being discussed. For routine internal meetings, transport encryption is often sufficient. For board discussions, legal consultations, incident-response calls, and anything classed as a significant incident under Article 23, E2EE closes the gap that transport encryption leaves at the server. That comes with a trade-off worth knowing before you switch it on: because the server never sees decrypted media, it can't produce a recording, transcript, or any other content-level record of that session. Metadata, such as timestamps and who joined or left when, still gets logged, but if your incident-response process depends on the vendor supplying session content for Article 23 reporting, agree with the vendor in advance what evidence will and won't survive E2EE, and pick the control accordingly for that particular call.

Access control and multi-factor authentication

Point (j) of Article 21(2), the same point that covers secured voice, video and text communications, also names multi-factor or continuous authentication explicitly; the related access-control and human-resources security duties sit in point (i). For video conferencing this translates into role-based permissions that separate hosts, co-hosts, and participants; a lobby or waiting room so unauthenticated users cannot join a live session unchecked; and single sign-on (SSO) with multi-factor authentication (MFA) enforced at the identity-provider level rather than left to individual users. Meeting links that can be guessed, reused indefinitely or joined without any host approval are a recurring finding in NIS2 gap assessments, precisely because they undercut an otherwise solid access-control policy elsewhere in the organisation.

Resilience, availability and business continuity

A video platform needs redundancy across regions or data centres, so a single outage doesn't remove the organisation's ability to communicate at the exact moment an incident demands coordination. This matters most during a ransomware event, when email and internal chat may be compromised or untrusted, and a resilient, independently hosted video channel becomes the fallback communication method the crisis team actually relies on. Article 21(2)(c) covers business continuity, including backup management and disaster recovery, and point (a) requires risk-analysis and information-system security policies more broadly.

Incident handling and reporting

A breach or extended outage of the video conferencing tool used for board, clinical or operational communication can meet the threshold for a 'significant incident' if it causes severe operational disruption, the same bar described earlier in this article. Article 23 sets a three-stage reporting timeline for significant incidents: an early warning within 24 hours of becoming aware, a fuller incident notification within 72 hours, and a final report within one month of that 72-hour notification. Entities need to know, in advance, whether their vendor will support timely evidence, such as logs, timestamps, and affected-session data, for that reporting cycle. Waiting until an incident to ask a vendor for this information is a common and avoidable failure point.

Supply-chain and third-party security

Article 21(2)(d) and Article 21(3) require entities to assess the cybersecurity practices of direct suppliers, including the quality of their products and secure development procedures. Your video conferencing vendor is a supplier in this sense, and due diligence should extend to their sub-processors (hosting providers, CDN operators, and TURN/STUN relay infrastructure, the servers that carry media when a direct connection between devices can't be established), not just the vendor's own front door. Financial-sector readers should note this is more than a parallel standard. DORA, the Digital Operational Resilience Act, is designated by its own Article 1(2) as a sector-specific Union act for the purposes of NIS2's Article 4, and that provision switches off NIS2's Articles 21 and 23 for entities within DORA's scope. That means DORA's own rules replace NIS2's risk-management measures, including the supply-chain assessment described here, and its incident-reporting duties, rather than adding a second layer on top of them. DORA also adds its own resilience-testing regime and third-party oversight, with no direct NIS2 equivalent. Entities outside DORA's scope remain under NIS2.

Management accountability

Management accountability isn't one of the ten Article 21(2) measures covered above. It rests on Article 20, which governs who signs those measures off and who answers for them. A board or senior manager who signs off on continuing to use a video tool that lacks MFA, or that stores recordings outside agreed jurisdictions, is making a risk-management decision they're now personally accountable for. Article 20 requires management bodies to approve the Article 21 risk-management measures, oversee their implementation, and undergo training themselves. For essential entities, though not important ones, the stakes go further: Article 32(5) requires Member States to give their competent authorities the power to temporarily ban an individual from holding managerial responsibility at CEO or legal-representative level for serious or repeated non-compliance. The Directive excludes public administration entities from this particular power. Otherwise it isn't a national option: the Directive requires the power to exist, even though each Member State implements the procedure itself.

NIS2 vs CRA vs DORA: which applies to your video tool?

NIS2, the Cyber Resilience Act (CRA) and DORA get confused with each other because they overlap in subject matter, and because NIS2 and DORA were adopted on the same day. They govern different things.

A useful rule of thumb: NIS2 asks whether the organisation manages risk well; the CRA asks whether the product was built securely; DORA asks whether a financial entity's operations, including its ICT suppliers, can withstand disruption. A regulated bank buying a video conferencing product could, in principle, touch all three.

Checklist: is your video conferencing tool NIS2-ready?

A vendor-neutral way to assess any platform is to work through the following, evaluating each on its own evidence rather than a vendor's marketing claims. Most of it maps to Article 21, with incident-reporting support tracking Article 23 and the last item sitting outside NIS2 altogether, for the reason given below. Treat it as a menu to weigh against your own risk assessment and size, not a uniform minimum every entity has to clear in full.

• Encryption. Is media protected only in transit (TLS/DTLS-SRTP), or is end-to-end encryption available? Under what conditions does it activate, and who controls the keys?
• Access control and authentication. Is MFA available through SSO? Are waiting rooms and host approval enabled by default? Can permissions be scoped by role rather than granted uniformly?
• Resilience. What redundancy exists across regions? What's the published or contracted uptime commitment? How does the vendor communicate during its own incidents?
• Incident-reporting support. Will the vendor supply timestamped logs and session data quickly enough to meet your 24-hour and 72-hour NIS2 deadlines, and is this written into the contract rather than assumed?
• Supply chain. Where is data hosted, who are the named sub-processors, and are those sub-processors themselves independently assessed?
• Data residency and jurisdiction. Not a NIS2 requirement, but it comes up in the same procurement conversation: does the platform keep EU meeting data, recordings, and metadata within the EU, and does this match your own data-sovereignty obligations under GDPR and any sector-specific rules?

Running a vendor through this list and documenting your reasoning, including what you judge not applicable and why, produces a defensible record for the management-body sign-off that Article 20 requires. It's also close to the working definition of secure video conferencing that NIS2 auditors will look for during a review.

Penalties for non-compliance

Article 34 sets floor levels that Member States must meet, though national laws can go higher. Essential entities face administrative fines of up to €10 million or 2 per cent of total worldwide annual turnover, whichever is higher; important entities face up to €7 million or 1.4 per cent of turnover (European Parliament and Council of the European Union, 2022a). These aren't one-off penalties layered on top of normal supervision: essential entities are subject to proactive, ex-ante oversight, meaning national authorities can request evidence of compliance without a prior incident, while important entities are supervised reactively, typically after a breach or complaint. Essential entities also carry the personal-liability exposure described above under Management accountability: a possible temporary ban on management responsibility under Article 32(5) for serious or repeated non-compliance. The exact fine ceilings, enforcement approach, and personal-liability provisions vary by Member State, so confirm the specifics that apply to your organisation with your compliance or legal function.

How Digital Samba supports NIS2 secure communication

By default, calls on the Digital Samba video conferencing API and SDK use the transport-layer protections built into WebRTC: TLS for signalling and DTLS-SRTP for media. We also offer optional end-to-end encryption for sessions where that stronger guarantee is warranted. Keys are generated locally on each participant's device using the Web Crypto API and are never transmitted to or stored on our servers. Media is protected with AES-128 in counter mode with HMAC-SHA256, so once enabled, our infrastructure only ever forwards ciphertext it cannot read. This gives security and compliance teams a genuine choice to make under Article 21(2)(h), rather than a single fixed encryption posture. E2EE is a per-session setting, not our default state, so decide upfront, as with any vendor, which sessions need it and which need us to keep recording or transcription capability available instead.

On access control, we support role-based permissions, waiting rooms, and API-driven authentication that integrates with an organisation's existing identity and SSO setup, so MFA enforcement can sit at the identity-provider layer as Article 21(2)(j) expects. As a REST API and embeddable SDK rather than a fixed consumer application, our platform is built to be integrated into an entity's own governance, logging, and access-management tooling, which supports the kind of evidence trail that both Article 21 risk management and Article 23 incident reporting call for.

Data residency itself is a GDPR and sovereignty question rather than a NIS2 requirement, but it's usually part of the same due-diligence conversation. Our production infrastructure runs in the Netherlands, with backup infrastructure in Germany; overflow capacity at peak demand includes a Swiss provider, whose location rests on an adequacy decision rather than EU or EEA residency. GDPR-aligned data handling is built into our architecture rather than added afterwards.

We don't hold a direct ISO 27001 or SOC 2 certification at the time of writing. Our controls are documented rather than certified: Digital Samba's information security management system uses ISO 27001:2022 as a reference framework, and we're working towards formal certification against it. Where certifications matter to your procurement process, ask any vendor, including us, for their current status and their sub-processors' certifications directly, rather than relying on general marketing claims.

For teams building a full NIS2 evaluation, our WebRTC security guide and our end-to-end encryption explainer go into the underlying mechanics in more depth, and our article on data sovereignty covers the data-sovereignty side of the same due-diligence process.

FAQ

Does NIS2 apply to video conferencing?

Yes, indirectly and directly. Indirectly, because essential and important entities must secure the tools their staff use for voice, video and text communication under Article 21(2)(j). Directly, because a video conferencing provider that runs its own cloud infrastructure at scale may itself be an in-scope digital infrastructure or ICT service provider.

What does NIS2 Article 21 require for video communication?

Article 21(2) lists 10 categories of proportionate risk-management measures, several of which apply directly to a video platform: cryptography and encryption policy, access control and multi-factor authentication, business continuity and resilience, incident handling, and supply-chain security assessment of the vendor itself.

Is a video conferencing provider an essential or important entity under NIS2?

It depends on how the service is delivered and the provider's size. A provider that operates its own hosting infrastructure can fall under the 'cloud computing service provider' or 'ICT service management' categories in Annex I, classed as essential once it exceeds the medium-sized ceilings, meaning 250 staff or more, or turnover above €50 million together with a balance sheet total above €43 million, and important below that but above the small-enterprise floor. A provider that simply resells another company's infrastructure is assessed differently, so this should be confirmed per vendor.

Does NIS2 require end-to-end encryption for video calls?

No. Article 21(2)(h) requires 'appropriate' use of cryptography and encryption, not a specific technical standard. Transport encryption (TLS and DTLS-SRTP) is the default for WebRTC-based platforms and is adequate for many use cases; end-to-end encryption is a stronger, additional control that entities should apply where the sensitivity of the discussion, such as board matters, incident response, and regulated data, justifies it.

What is the difference between NIS2, DORA and the Cyber Resilience Act for video tools?

NIS2 governs how an in-scope organisation manages cybersecurity risk and reports incidents. For the financial entities within its scope, DORA replaces NIS2's risk-management and incident-reporting obligations rather than sitting alongside them, and adds its own resilience-testing and third-party oversight regime. The Cyber Resilience Act governs the security of the software or hardware product itself, placing obligations on the manufacturer rather than the buyer. A regulated financial institution buying a video conferencing product could be affected by all three, depending on its own status and the vendor's.

Who must comply with NIS2?

Essential and important entities across the 18 sectors listed in Annexes I and II of Directive (EU) 2022/2555, generally determined by sector and by the size thresholds in Article 2 (broadly, medium-sized entities are important and larger ones essential, where medium-sized means fewer than 250 staff with turnover up to €50 million or a balance sheet total up to €43 million; organisations below the small-enterprise floor are usually out of scope), with certain categories, such as DNS service providers and qualified trust service providers, in scope regardless of size.

What are the penalties for NIS2 non-compliance?

Under Article 34, essential entities face fines of up to €10 million or 2 per cent of global annual turnover, whichever is higher; important entities face up to €7 million or 1.4 per cent of turnover. Member States can set higher ceilings in national law. Article 20 adds personal accountability for management bodies, and for essential entities specifically, Article 32(5) allows competent authorities to impose temporary management bans in cases of serious or repeated non-compliance.

This article provides general information and does not constitute legal advice. Confirm your organisation's specific NIS2 obligations, entity classification and reporting duties with your compliance or legal function.

Sources

1. European Parliament and Council of the European Union. (2022a). Directive (EU) 2022/2555 of 14 December 2022 on measures for a high common level of cybersecurity across the Union (NIS 2 Directive). Official Journal of the European Union, L 333.
2. European Commission. (2024). Commission Implementing Regulation (EU) 2024/2690 laying down rules for the application of Directive (EU) 2022/2555 as regards technical and methodological requirements. Shaping Europe's Digital Future.
3. Kemp IT Law. (2025). Navigating NIS 2: a guide to applicability for 'managed service providers'.
4. European Parliament and Council of the European Union. (2024). Regulation (EU) 2024/2847 of 23 October 2024 on horizontal cybersecurity requirements for products with digital elements (Cyber Resilience Act).
5. European Parliament and Council of the European Union. (2022b). Regulation (EU) 2022/2554 of 14 December 2022 on digital operational resilience for the financial sector (DORA).