What does NIS2 require for incident-response access?

NIS2 requires in-scope essential and important entities to cover incident-response access through two of the ten risk-management measure categories in Article 21(2): (b) incident handling, and (j) the use of multi-factor or continuous authentication, secured voice/video/text communications, and secured emergency-communication systems. Neither clause names a specific product or architecture — NIS2 sets outcomes, not implementations — but together they're commonly read as requiring that the tools and accounts used to respond to and communicate about an incident are themselves properly authenticated and secured, not treated as a lower-security exception because they're "just for emergencies."

The directive and who it covers

NIS2 (Directive (EU) 2022/2555) and the UK's parallel NIS Regulations 2018 (as amended) impose security and incident-reporting obligations on operators in specific high-criticality sectors — energy, transport, banking, health, digital infrastructure, and others listed in Annex I and Annex II — above a size threshold (broadly, medium-sized: at least 50 staff or at least €10 million turnover for the "important" category). Entities outside those sectors and below that threshold aren't directly in scope, even if they handle sensitive operations, though they can still be relevant to an in-scope customer's own supply-chain obligations.

Article 21(2): the measures that touch incident-response access

Article 21(2) lists ten categories of risk-management measures in-scope entities must implement. Three are most directly relevant to how staff access systems during and around an incident:

• (b) Incident handling — the core requirement to have a defined process for detecting, managing, and recovering from incidents, which implicitly requires the access needed to act on that process.
• (d) Supply-chain security — assessing whether suppliers, including any vendor providing incident-communications or emergency-access tooling, apply equivalent risk-management measures.
• (j) MFA, secured communications, and secured emergency-communication systems — the clause most specific to this question: strong authentication and secured channels for the tools used to coordinate a response, not just the systems being protected.

The reporting cascade this access needs to support

Article 23 sets a three-stage timeline for in-scope entities reporting a significant incident to their competent authority or CSIRT: an early warning within 24 hours of becoming aware, an incident notification within 72 hours with an initial impact assessment, and a final report within one month covering root cause, impact, and mitigations. Meeting those windows depends on responders actually being able to reach the systems and information needed to assess the incident quickly — which is the practical link between Article 21(2)'s access-related measures and Article 23's reporting clock. A team that can't authenticate into its own incident-response tooling quickly isn't going to make a 24-hour early warning either.

What this means for suppliers

Article 21(2)(d)'s supply-chain requirement means an in-scope entity has to assess vendors providing critical or important functions — which can include incident-communications and emergency-access tools — for equivalent risk-management measures. In practice this looks like standard supplier due diligence: how is access authorized (ideally not a single shared credential or admin override), is MFA enforced, is data encrypted, and does the vendor commit to notification timing that lets the entity meet its own Article 23 cascade.

How Glassbreak fits this picture

Glassbreak is not directly in scope under NIS2 or the UK NIS Regulations — it's below the size threshold and not in an Annex I or II sector — but is a supplier to customers who are, and its Article 21(2) coverage plus Article 23-aligned customer-notification commitments are published in full at /trust/nis2. MFA is enforced for administrative and customer-facing accounts, and emergency-communication surfaces are end-to-end encrypted rather than treated as a lower-security fallback channel — the cryptographic detail is on the security page. Customers weighing EU-specific regulatory alignment alongside NIS2, including DORA for financial entities, can see the combined posture at data residency for DORA & NIS2. For the DORA-specific version of this question, see how DORA affects emergency access to ICT systems.

This page describes NIS2's requirements at a general level to help with vendor evaluation; it isn't legal advice, and an entity's specific in-scope status and obligations should be confirmed against the directive and with qualified counsel.