SMS server: what it takes to build one, and when to buy instead
6 November 2026
If you are looking for an SMS server, you are usually one of two people: someone who wants to run the software themselves, or someone
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.
In practice, meeting these obligations can be challenging in scenarios where standard IP-based communication channels are degraded or deliberately isolated—for example as a result of DDoS attacks, ransomware incidents, or failures of core infrastructure services such as DNS or Active
Directory. This article examines how additional Out–of–Band (OOB) communication channels, including solutions such as SMSEagle, can enhance the resilience of incident reporting processes under such conditions.
Article 23 requires entities covered by the Directive to report incidents that have a significant impact on the provision of their services. Pursuant to paragraph 3, an incident is deemed significant where it has caused, or is capable of causing, serious operational disruption, financial losses, or substantial harm to service recipients.
The reporting process set out in paragraph 4 comprises three stages:
Importantly, the Directive does not prescribe a specific technical reporting channel. What matters is the ability to demonstrate that actions were taken without undue delay and in a manner proportionate to the nature and severity of the incident.
In high-severity incident response scenarios, organisations frequently deploy containment measures that temporarily restrict the availability of IP-based networks. Common examples include:
Under such circumstances, a reporting process that relies exclusively on IP-based communication may exhibit reduced operational resilience, increasing the risk of delays in meeting Article 23 obligations. While this does not in itself constitute a breach of the Directive, it represents an area of operational risk that may be scrutinised by supervisory authorities during post-incident assessments.
One way to mitigate this operational risk is to deploy additional Out-of—Band communication channels that do not depend on the same infrastructure as IP networks. A practical example is the use of GSM/LTE networks through on-premises SMS gateways.
OOB channels can play a supporting role, particularly in:
It should be clearly emphasized that OOB communication does not replace formal reporting channels to CSIRTs, which are defined by national implementing measures. Rather, it can support the timely activation and coordination of those formal processes
Article 23(2) imposes an obligation to inform service recipients about incidents and the mitigation measures they may take. Where standard communication channels—such as websites or email—are unavailable, alternative means of communication may enable this obligation to be fulfilled “without undue delay”.
In this context, OOB channels, alongside voice communication and manual procedures, may constitute one of several tools supporting timely and effective customer notification, depending on the organisation’s business model and risk profile.
The NIS2 Directive places strong emphasis on the ability to document both the sequence of events and the actions taken in response to an incident. From an audit perspective, this typically includes:
Together, these elements form a coherent evidentiary record subject to assessment by auditors and supervisory authorities.
Timestamps generated by independent communication channels—such as those provided by GSM operator networks—may serve as a supplementary evidentiary element, supporting the reconstruction of the incident timeline, provided they are consistent with documented procedures and Incident Response processes. On their own, however, they are not determinative of compliance with reporting obligations.
SMSEagle addresses these requirements by providing an independent out-of-band communication channel based on GSM/LTE networks. The solution does not rely on Internet connectivity or the organisation’s internal IP infrastructure.
In practice, it enables:
As a result, the SMSEagle hardware SMS Gateway may support the implementation of selected NIS2 requirements, in particular by strengthening communication capabilities relevant to incident handling (Article 21(2)(b)), business continuity and crisis management (Article 21(2)(c)), and secure emergency communication (Article 21(2)(j)).
Compliance with Article 23 of the NIS2 Directive requires not only an understanding of legal obligations, but also organisational processes that remain effective under adverse and degraded conditions. The Directive does not mandate specific technical solutions; instead, it expects entities to demonstrate the timeliness, adequacy, and proportionality of their response.
The deployment of additional Out-of-Band communication channels, including GSM-based solutions, can form one component of a broader strategy for risk management and reporting continuity. Such measures should complement organisational procedures, voice communication, and alternative decision-making pathways, and be properly embedded within the overall information security management framework.
If you are looking for an SMS server, you are usually one of two people: someone who wants to run the software themselves, or someone
Integrating an SMS gateway means connecting your software to it, so the software can send text messages and receive replies automatically. There are four main ways to do it: a ready-made plugin, an API, Email to SMS and SMPP.
Zabbix 8.0 adds push notifications and a mobile app. Here is what the architecture depends on, where it breaks, and why SMS and voice alerts still belong in your escalation chain.
