NIS2 Secure Communications: The Half of Article 21(2)(j) Most Programmes Skip

Between February and June 2026, Sophos tracked a campaign it calls STAC4749. The attackers set up Microsoft Teams accounts on IT-themed domains, called employees pretending to be the helpdesk, and talked them into opening a Quick Assist session. At least three of those intrusions ended in Chaos ransomware. One went from the first Teams call to encrypted files in under 17 hours.

Now ask what those organisations used to coordinate their response. Teams. Outlook. The same tenant the attacker had already walked into.

That is the problem NIS2 secure communications requirements exist to solve. Article 21(2)(j) is the measure that covers it, and it is the half of that article most compliance programmes never implement.

Article 21(2)(j) has two halves, and most programmes only build one

The directive's wording is short: "the use of multi-factor authentication or continuous authentication solutions, secured voice, video and text communications and secured emergency communication systems within the entity, where appropriate."

Everyone reads the first clause. MFA gets budget, a project, and a line in the board report. We covered why MFA alone no longer passes an audit earlier this year.

The second clause gets ignored. It contains two separate obligations: secure your everyday voice, video and text channels, and have an emergency communication system that still works when the everyday channels do not.

"Where appropriate" is not an opt-out. It is a risk-based qualifier. If you decide a control is not appropriate, the decision has to be written into the risk assessment with reasoning. An auditor treats silence as a gap, not as a decision.

Article 21 — 10 NIS2 Cybersecurity Measures
🛡️
Article 21
10 Cybersecurity Measures
📊Governance & Strategy
1Risk analysis & information security policies
6Effectiveness assessment of security measures
🚨Incident & Continuity
2Incident handling & notification
3Business continuity & disaster recovery
🔗Supply Chain & Systems
4Supply chain security
5Security in network & information systems development
🔐Technical Controls
8Cryptography & encryption
10Multi-factor authentication & secure communications
👥People & Assets
7Cyber hygiene & training
9HR security & access control

The implementing regulation scatters the requirement across five sections

Commission Implementing Regulation (EU) 2024/2690 is the detailed rulebook for digital infrastructure, ICT service management and digital providers. That means MSPs and MSSPs fall under it directly. National authorities in other sectors use it as the reference for what "appropriate" looks like.

There is no section in it called "secure communications". Look for one and you will conclude the obligation is thin. It is not. It is spread out:

Point 3.5.3 requires incident response communication plans and procedures: with the CSIRT or competent authority, among your own staff, and with external stakeholders.

Point 4.1.2(c) requires the business continuity and disaster recovery plan to list key contacts and internal and external communication channels.

Point 4.2.4(d) requires at least partial redundancy of "appropriate communication channels", alongside redundancy of systems, facilities and personnel.

Point 4.3.2(b) requires the crisis management process to define communication means with competent authorities, for both obligatory reports and non-obligatory exchanges.

Point 6.7.2(i) and (k) require trusted, isolated channels between systems, and an implementation plan for modern e-mail communication standards.

Point 11.7 covers the MFA half.

The practical consequence: an auditor will not ask "do you have secure communications?" They will ask for your incident response procedure, your BC/DR plan and your crisis management process, and look for the communication channel in each one. If the answer in all three is "email and Teams", the finding writes itself.

Your incident response runs on the system the attacker is inside

Assume compromise. That is not paranoia, it is documented behaviour.

Microsoft and CISA both describe how Octo Tempest, better known as Scattered Spider, searches a victim's Slack, Teams and Exchange Online for conversations about its own intrusion, and joins incident response calls to learn how defenders are hunting it. In June 2026, DragonForce affiliates were seen routing command-and-control traffic through legitimate Microsoft Teams relays so it blended in with normal collaboration traffic.

If the attacker holds a privileged Entra ID account, every channel that authenticates against Entra ID is theirs to read. That includes the "backup" Teams channel you created for the crisis team.

An emergency communication system passes three tests:

Separate identity. It does not authenticate through your primary identity provider. If SSO gets you into it, a compromised SSO gets the attacker into it.

Separate infrastructure. It is not hosted in the same tenant, on the same domain, or behind the same DNS you may need to take down.

Pre-provisioned and rehearsed. The contact list exists offline, the accounts exist before the incident, and the channel has been used in a test. Point 4.1.4 requires BC/DR plans to be tested at planned intervals. The emergency channel is part of that plan, so it is part of that test.

In practice this is not expensive. A Signal or Threema group on MDM-managed devices with accounts that are not tied to corporate SSO. A printed contact card in the crisis binder. A break-glass mailbox with a different provider. The cost is not the tooling. The cost is the discipline to keep it current.

One more detail that gets missed: the 24-hour early warning under Article 23 has to reach your CSIRT even when your mail server is the thing that is down. The contact details you gave the national entity register at registration are what the CSIRT will use to call you back. If that is a mailbox in the compromised tenant, you have a reporting problem on top of a security problem. The incident handling procedure should name the fallback route to the CSIRT explicitly.

NIS2 Incident Reporting Timeline
24h
⚡Early Warning
Notify the competent authority (CSIRT/NCA) within 24 hours of becoming aware of a significant incident.
Step 1
72h
📋Incident Notification
Submit a detailed notification within 72 hours with an initial assessment of severity, impact and indicators of compromise.
Step 2
1mo
📊Final Report
Deliver a comprehensive final report within one month covering root cause, remediation taken and cross-border impact.
Step 3
24h
⚡Early Warning
Notify the competent authority (CSIRT/NCA) within 24 hours of becoming aware of a significant incident.
72h
📋Incident Notification
Submit a detailed notification within 72 hours with an initial assessment of severity, impact and indicators of compromise.
1mo
📊Final Report
Deliver a comprehensive final report within one month covering root cause, remediation taken and cross-border impact.

NIS2 secure communications is a configuration standard, not a product purchase

Teams, Google Meet and Zoom all encrypt in transit. Nobody fails an audit because their video calls are unencrypted. The question the regulation is really asking is: who can reach your people, over which channels, and under what controls?

Map that to concrete settings and the picture becomes clear.

External access. STAC4749 and the Black Basta campaign before it both depended on external Teams accounts being able to message and call employees. Restricting external federation to an allow-list of partner domains, or blocking external chat and calls for most users, removes the entry point. Point 6.7.2(c) already requires you to prevent network communication not needed for operations. This is the collaboration-layer version of that rule.

Email authentication. Point 6.7.2(k) asks for an implementation plan for "internationally agreed and interoperable modern e-mail communications standards". ENISA's technical implementation guidance from June 2025 points to SPF, DKIM and DMARC for sender authentication and MTA-STS or DANE for transport encryption. A DMARC record at p=none is monitoring, not protection. Auditors have learned the difference.

Approved tools by classification. Your cryptography policy under Article 21(2)(h) should state which messaging and conferencing tools are approved for which asset classification level. A board discussing an incident over WhatsApp on personal phones is a finding, because there is no policy that permits it and no control that governs it.

Meeting hygiene. Lobby enabled, authenticated join for internal meetings, host-only screen sharing and recording, and a rule that nobody on a crisis call is anonymous.

Voice. SIP trunks and VoIP over TLS and SRTP, and, for sites where it matters, emergency call capability that does not depend on the corporate network being up.

None of this requires buying a new product. All of it requires someone to own the configuration and to be able to export the evidence.

What an auditor will actually ask for

Supervisory authorities have started requesting evidence packages rather than policy statements. We covered the general evidence checklist two weeks ago. For Article 21(2)(j), expect these eight items:

The communication section of the incident response procedure, naming primary and fallback channels with owners.
The key contacts and channels section of the BC/DR plan, dated within the current review cycle.
A redundancy statement for communication channels under point 4.2.4(d).
A test record showing the emergency channel was used during an exercise.
An export of the Teams or Google Workspace external access configuration.
DNS records for DMARC, MTA-STS and, where used, DANE.
The approved communications tools list, tied to asset classification levels.
The risk assessment entries justifying any "not appropriate" decisions.

If you can produce all eight in a day, you are done with this measure. If you can produce three, you know where the gap analysis starts.

For MSPs, this measure applies twice

An MSP is an ICT service management entity under Annex I of NIS2. CIR 2024/2690 applies to it directly. That is your own obligation.

Then there is the client side. Every client's supply chain security policy under point 5.1 is supposed to evaluate the cybersecurity practices of its service providers. Your ability to communicate with a client during an incident, over a channel that is not the client's compromised tenant and not your compromised tenant, is one of those practices.

Run this scenario: your RMM or your M365 tenant is compromised. Forty clients need to hear about it within hours. Your email is the thing that is compromised. What is the list, where does it live, and who has it on a phone that does not sync with corporate SSO?

If there is no answer, that is the first item on your own remediation plan. The Netherlands' Cyberbeveiligingswet has been in force since 15 August 2026, and the RDI supervises ICT service management directly. Germany's BSI and Belgium's CCB have been doing so for longer. The double obligation for MSPs is no longer theoretical in any of those markets.

NIS2 Penalty Escalation — Beyond the Fine
!
Trigger event
Non-Compliance Detected or Incident Occurs
A supervisory authority identifies a compliance gap or an organisation fails to meet NIS2 requirements
Authorities can impose▼
Non-Monetary Penalties
1
Compliance orders with binding deadlines
2
Mandatory security audits at your expense
3
Public disclosure of violations
4
Binding instructions on specific security measures
Escalates to▼
Operational & Personal Consequences
1
Suspension of certifications or operating licences
2
Temporary ban on management functions for individuals
3
Public naming of responsible natural persons
Trigger
Non-monetary
Operational / personal

Where to start this month

This is not a project with a steering committee. It is four tasks.

Pick the emergency channel and provision it. Separate identity, separate infrastructure, contact list stored offline.

Write it in. Add the channel to the incident response procedure under 3.5.3 and to the key contacts section of the BC/DR plan under 4.1.2(c).

Close the front door. Restrict external federation in Teams. Move DMARC to p=reject once the reporting confirms your legitimate senders.

Test it. The first message of your next tabletop exercise goes out over the emergency channel only. If nobody sees it, you have learned something important at a convenient time.

If you want to know where Article 21(2)(j) sits alongside the other nine measures for a specific client, the NIS2Certify quick scan covers all ten in about ten minutes and gives you a prioritised gap list to work from.