NIS2 and Supply Chain Risk Reduction: How to Mitigate Communication-Related Threats

The NIS2 Directive (EU 2022/2555) introduces a fundamental shift in the approach to cybersecurity risk management. An organisation’s responsibility no longer ends at its own infrastructure—it now explicitly extends to suppliers and service providers whose services are critical to business continuity.

Introduction

In practice, supply chain risk reduction means limiting critical dependencies on third parties. The objective is to design systems and processes in such a way that a failure or cyber incident affecting a supplier does not prevent the organisation from activating its core incident response and crisis management procedures.

Example: if an organisation relies on a cloud-based service to send alerts and notifications, a volumetric DDoS attack may disrupt connectivity to that service. From the perspective of NIS2, the issue is not the use of a cloud service itself, but the absence of an alternative communication channel, which may make it impossible to initiate emergency procedures when they are needed most.

Article 21 of NIS2 – the legal foundation

Article 21 of NIS2 explicitly identifies supply chain security as a mandatory element of cybersecurity risk management. The Directive lists it as one of the minimum measures that organisations are required to implement:

“supply chain security, including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers”
Article 21(2)(d) NIS2

The provisions go further than formal supplier relationships. Article 21 makes it clear that organizations must carry out a substantive risk assessment of those relationships:

“entities shall take into account the vulnerabilities specific to each direct supplier or service provider and the overall quality of their cybersecurity practices”
Article 21(3) NIS2

In the context of communications, this means that the more intermediaries are involved in delivering a message (for example: platform → aggregator → subcontractor → operator), the harder it becomes to:

  • maintain transparency,
  • demonstrate effective control over the process,
  • limit the impact of a failure at any single point in the chain.

Key communication risks identified in audits

During NIS2 compliance assessments, three communication-related risk areas are most commonly highlighted:

Lack of transparency
It is often unclear who exactly participates in message delivery and where data is processed, including logs, alert content, and timestamps.

Cascading risk
A failure or incident affecting a single supplier may simultaneously impact many customers, disrupting entire service ecosystems.

Complete dependence on IP-based networks
Most modern communication tools require internet access and identity services. In the event of a severe incident—such as ransomware—where network isolation becomes necessary, these tools may become unusable.

Example: an alarm system technically “exists”, but triggering it requires logging into a SaaS panel via SSO. Once the network is isolated, the organisation loses the ability to notify incident response teams

Managing dependency on suppliers

The NIS2 Directive does not require organisations to abandon external suppliers. It does, however, require the implementation of risk-proportionate measures. In the context of crisis communication, this most commonly means:

  • shortening intermediary chains in critical processes,
  • building alternative, independent communication channels,
  • ensuring control over data and logs so that actions and timelines can be demonstrated.

In practice, many organisations retain cloud services for day-to-day communication while designing critical alerting channels to be more autonomous and resilient.

Standards and risk assessment (Articles 22 and 25)

Article 22 enables EU-level coordinated risk assessments of critical ICT supply chains. While it does not impose direct implementation obligations on individual entities, it reinforces the expectation of mature dependency management.

Article 25 strengthens the audit perspective by encouraging the use of recognised technical standards. For organisations, this sends a clear signal: audits focus not only on what has been implemented, but on whether those measures can be clearly described, documented, and defended as appropriate to the identified risk.

“Member States shall encourage the use of European and international standards and technical specifications relevant to the security of network and information systems”
Article 25 NIS2

The role of local (on-premise) solutions: the SMSEagle example

Locally deployed (on–premise) solutions such as SMSEagle hardware gateway align naturally with supply chain risk reduction strategies by limiting reliance on external, multi-layered communication services and restoring control over a critical alerting channel.

In practical terms, this provides:

A shortened dependency chain
Alert communication flows directly from the organisation’s infrastructure to the cellular operator’s network, without cloud platforms, aggregators, or additional subcontractors. Fewer links mean lower cascadingfailure risk and greater process transparency.

Resilience to external outages
A local SMS gateway operates independently of internet availability, DNS services, identity systems, or SaaS management panels. As a result, the alerting channel remains functional even in scenarios where the organisation deliberately isolates its IP network as part of incident response.

Control over data and evidentiary records
Delivery logs, timestamps, and confirmation data remain within the organisation’s infrastructure. This simplifies accountability and supports the creation of coherent audit documentation.

Example: during a cybersecurity incident, an organisation decides to disconnect part of its IT infrastructure from external networks. Business systems, email, and collaboration tools are unavailable, but the local SMS gateway continues to operate, allowing immediate notification of on-call engineers or duty officers. As a result, the incident response procedure can be activated without delay despite IP-level restrictions.

Conclusion

The NIS2 Directive clearly shifts cybersecurity responsibility beyond organisational boundaries, making supply chain security a core component of risk management. Article 21 explicitly requires organisations to assess supplier relationships not only in formal terms, but in terms of vulnerabilities, cybersecurity maturity, and impact on operational continuity. Risks arising from over-reliance on third parties can no longer be treated as “supplier issues”—they constitute genuine operational risk.

In crisis communication, the most significant risk factors remain the length and complexity of intermediary chains and complete dependence on IP-based and cloud services. The more entities involved in message delivery, the greater the likelihood that a single external incident will prevent the activation of response procedures at a critical moment.

It is precisely in this area that locally deployed solutions such as SMSEagle provide tangible value. By shortening dependency chains, eliminating cloud intermediaries, and ensuring independence from the public internet, they help preserve a reliable alerting channel even during severe incidents and network isolation scenarios. At the same time, full control over data and logs supports accountability and audit readiness. As a result, SMSEagle should be viewed not merely as a technical tool, but as part of a mature, NIS2-aligned approach to managing communication risk within the supply chain.

Software Updates

NIS2 24h Incident Reporting: Ensuring Process Continuity When IP Networks Are Unavailable

The NIS2 Directive (EU) 2022/2555 replaces the 2016 regulatory framework, introducing harmonised cybersecurity governance requirements for essential and important entities across the European Union. One of its key operational provisions is Article 23, which defines the timelines and scope for reporting cybersecurity incidents to the relevant competent authorities and CSIRT teams.

Read More »