Who should read this: Telecom providers, network operators, communications security teams, compliance officers.
The NIS2 Directive brings encryption to the centre of cybersecurity strategy for Europe’s critical infrastructure. For telecommunications providers and publicly available electronic communications services, encryption is no longer optional; it is a foundational security requirement. But the Directive’s approach to encryption is nuanced. Rather than imposing a blanket mandate, it recognises that encryption technologies protect different things and operate at different layers of network infrastructure. This post unpacks how NIS2 treats encryption, when it becomes mandatory, and why even those not subject to direct requirements should treat it as essential.
The European Union has long recognised encryption as a cornerstone of digital rights and security. The NIS2 Directive reinforces this through Recital 98, which emphasises that “the use of encryption technologies, in particular end-to-end encryption as well as data-centric security concepts, such as cartography, segmentation, tagging, access policy and access management, and automated access decisions, should be promoted.” This framing is deliberate. Encryption is positioned not as a technical detail to be delegated to engineers, but as a policy priority reflecting Europe’s commitment to both security and privacy.
For providers of public electronic communications networks and publicly available electronic communications services, a category that includes most telecom operators and major internet service providers, NIS2 takes a conditional but firm stance. The Directive states that “where necessary, the use of encryption, in particular end-to-end encryption should be mandatory.” This creates a spectrum of obligation. The word “where necessary” gives regulators and competent authorities flexibility to assess context, threat landscape, and technical feasibility. But the default expectation is clear: encryption is the baseline, not the exception.
When Does Encryption Become Mandatory?
The NIS2 framework does not prescribe a single moment at which encryption switches from optional to compulsory. Instead, competent authorities in each Member State will make proportionate judgments based on the services being offered, the sensitivity of data involved, and the risk of harm if communications are intercepted or modified. For a major mobile network operator handling millions of users’ personal data and communications, the bar for “necessity” is extraordinarily low. For a smaller internet service provider serving a regional market, the assessment might differ, though the presumption remains that encryption is needed.
Several factors push most telecom services towards mandatory encryption. First, telecommunications carry sensitive personal data by definition. Calls, messages and online traffic reveal intimate details of people’s lives: medical information, financial data, family communications. End-to-end encryption ensures that not even the service provider can access this data. This dual benefit (protecting users and protecting the provider from liability) makes encryption practically mandatory for any service handling such content.
Second, the Directive acknowledges that encryption must be reconciled with legitimate law enforcement and national security powers. Recital 98 explicitly states that “the use of end-to-end encryption should be reconciled with the Member States’ powers to ensure the protection of their essential security interests and public security, and to allow for the prevention, investigation, detection and prosecution of criminal offences in accordance with Union law.” This is not a loophole that weakens encryption. Rather, it recognises that encryption technologies and state authorities operate in the same regulatory ecosystem. The Directive’s critical caveat is that this reconciliation “should not weaken end-to-end encryption, which is a critical technology for the effective protection of data and privacy and the security of communications.” Encryption remains strong; it is the legal framework around it that must adapt.
Beyond Encryption: Data-Centric Security Concepts
Many organisations narrow encryption to a single technology, typically TLS for web traffic or IPsec for networks. NIS2 takes a broader view. Recital 98 references “data-centric security concepts, such as cartography, segmentation, tagging, access policy and access management, and automated access decisions.” These terms describe architectural patterns that work alongside encryption.
Cartography means mapping data flows and understanding where sensitive information lives within your systems. Segmentation involves dividing your network so that a breach in one area cannot automatically spread to all others. Tagging applies metadata to data so that systems can enforce rules based on sensitivity or regulatory requirements. Access policy and management define who can reach what data under what conditions. Automated access decisions extend this to machines making real-time decisions about whether to allow a transaction based on policy.
Together, these create defence in depth. Encryption secures data in transit and at rest. Data-centric concepts ensure that even if an attacker penetrates your perimeter, they face multiple layers of control before accessing sensitive information. For telecom providers, this means layering end-to-end encryption with internal controls that prevent your own operations staff from casually accessing user communications, and systems that flag anomalous access patterns in real time.
Implementation Across Telecom Infrastructure
The Directive acknowledges that not all services are identical, nor should encryption be applied identically everywhere. However, the expectation is that providers assess their services and apply encryption where it protects communications or data from unauthorised access.
For consumer-facing services (mobile networks, fixed broadband, email), the mandate is strongest. These services handle personal communications and data by definition. Encryption should be the default. This includes both encryption between user devices and the provider’s infrastructure (transport security) and, where technically and commercially feasible, end-to-end encryption for sensitive services like messaging or voice calls.
For business services and enterprise connectivity, the situation is more complex. Some enterprise customers have their own security infrastructure and may not want provider-imposed encryption if it prevents their own security monitoring. However, NIS2 requires that entities handle “cybersecurity risk-management measures” proportionate to risks. For most enterprises, accepting telecom provider encryption strengthens rather than weakens their overall posture, provided they control the encryption keys.
For network operations and inter-provider connections, encryption protects the internet’s backbone from interference, eavesdropping or manipulation. Secure routing and encrypted control channels are foundational. The Directive’s emphasis on promoting “secure routing standards” in Recital 99 reinforces that operators should treat network operations infrastructure itself as a sensitive security domain.
Encryption and the Wider Security Ecosystem
Encryption is not a silver bullet. Its effectiveness depends on proper key management, regular software updates to close vulnerabilities in cryptographic libraries, and systematic removal of weak cryptographic algorithms. NIS2’s broader framework, including incident reporting obligations, vulnerability disclosure, and security risk assessments, creates the governance structure that makes encryption meaningful.
For example, if a telecom provider deploys strong encryption but fails to patch known vulnerabilities in its encryption software, the encryption becomes a false sense of security. Conversely, if a provider implements continuous patching but uses outdated, weak encryption algorithms, regulatory compliance becomes merely symbolic. NIS2 addresses this by requiring entities to manage cybersecurity risks holistically, not as isolated controls.
Encryption also requires transparency with users. When you encrypt user communications, users need to understand what is encrypted, what is not, who holds encryption keys, and what happens if keys are lost. This is why Recital 104 requires that “providers of public electronic communications networks or of publicly available electronic communications services should implement security by design and by default, and inform their service recipients of significant cyber threats and of measures they can take to protect the security of their devices and communications, for example by using specific types of software or encryption technologies.” Encryption is most powerful when users understand it and can make informed choices about their communications.
Preparing for Encryption Under NIS2
If you are a telecom provider or operate a communications service, NIS2 encryption obligations should already be on your roadmap. The question is not whether to encrypt, but how to do so proportionately, cost-effectively, and in ways that balance security, user experience, and business requirements.
Start by mapping where sensitive data flows through your infrastructure. Identify services where interception or modification would cause harm, both to your users and to your liability profile. Work with your regulators early; many competent authorities will publish guidance on what they consider “necessary” encryption for different service categories. This avoids the costly scenario of deploying one encryption architecture only to be told it is insufficient.
Invest in key management. Encryption is only as strong as the process that generates, stores, rotates and destroys encryption keys. Poor key management is a common reason encryption fails. Similarly, build processes to retire weak cryptographic algorithms and upgrade to stronger ones as threats evolve and standards change.
Finally, treat encryption as part of a broader security culture. Train staff on why encryption matters, how it is implemented, and what happens when it breaks. Include encryption in incident response drills. Ensure that vulnerability disclosure processes cover cryptographic libraries. Encryption is a technical control, but it is embedded in organisational practice.
Key Takeaways
- NIS2 requires providers of public electronic communications networks and publicly available communications services to use encryption, particularly end-to-end encryption, “where necessary” as determined by competent authorities.
- Encryption must be mandatory in practical terms for most consumer and business telecom services because the data they carry (personal communications, financial information, health data) is inherently sensitive.
- NIS2 recognises that strong encryption can coexist with law enforcement and national security powers, provided encryption itself is not weakened; the legal and regulatory framework adapts instead.
- Beyond encryption algorithms, the Directive emphasises data-centric security concepts: cartography, segmentation, tagging, access policy and automated access decisions.
- Encryption is only effective when combined with robust key management, timely software patching, user awareness, and integration into the wider security risk management programme.
