Germany NIS2 Telecom Compliance: The TKG §166 Gaps NIS2 Closes (and How to Fix Them)

German telecom operators are in an unusual position under NIS2. Almost every other sector was handed a brand-new compliance regime through the BSI-Gesetz (BSIG). Telecom wasn’t — Germany routed most of it through a law that already existed. The Telekommunikationsgesetz (TKG) has required a security officer, a security concept, and incident reporting to the Bundesnetzagentur since 2021, years before NIS2 was transposed. That head start is real, but it’s partial, and the parts it doesn’t cover are exactly where compliance teams get caught out.

This guide maps precisely what TKG §166 already gives you, what NIS2 adds on top, which regulator you actually report to, and where Germany’s own technical catalog stands in for the EU implementing regulation that telecom is not bound by.

Does This Apply to Your Company?

In plain terms: if you operate a public telecommunications network or offer a publicly available telecommunications service in Germany, NIS2 Article 2(2)(a) puts you in scope regardless of size — a broadband ISP with a dozen employees is captured on the same legal basis as a national carrier.

Entity type	NIS2 tier	Basis
Operators of public telecom networks (any size)	Important, or Essential if large	Article 2(2)(a) — in scope regardless of size
Providers of publicly available telecom services (any size)	Important, or Essential if large	Article 2(2)(a)
Large network operators (≥250 staff or >€50M turnover and >€43M balance sheet)	Essential (besonders wichtige Einrichtung)	Standard Annex I large-enterprise threshold

Germany’s three largest network operators — Deutsche Telekom, Telefónica Deutschland, and 1&1 — clear the large-enterprise threshold by a wide margin on headcount and revenue alone, so they land in the Essential tier through the ordinary size test, independent of the size-regardless clause that exists mainly to pull small and micro operators into scope. If your organisation is a smaller regional network operator or a specialised telecom service provider, don’t assume the size-regardless language only matters to the majors — it’s the reason you’re in scope too, even below the normal important-entity thresholds.

Why Telecom Doesn’t Just Follow BSIG

Most NIS2 guidance assumes every regulated entity registers with BSI, implements the ten measures under BSIG §30, and reports incidents through BSI’s portal. Telecom operators do none of that directly. §28(5) BSIG explicitly exempts entities that operate a public telecommunications network or provide publicly accessible telecommunications services from BSIG §§30, 31, 32, 35, 36, 38, 39, 61 and 62 — the sections covering risk-management measures, incident reporting, and most of BSI’s supervisory and enforcement toolkit.

Instead, Germany routed NIS2’s substance into the TKG itself. The ten Article 21(2)-equivalent measures listed in BSIG §30 — risk analysis, incident handling, business continuity, supply chain security, secure system acquisition and development, effectiveness assessment, staff training, cryptography, personnel/access control, and multi-factor authentication — were transplanted almost identically into a new §165(2a) TKG. The Bundesnetzagentur, not BSI, remains your primary point of contact for the technical and organisational side of compliance. BSI stays involved only through the parallel incident-reporting channel under §168 TKG (below) and through joint work on the security requirements catalog. One notable gap in the carve-out: §33 BSIG (the general registration duty) is not on the exempted list, so don’t assume telecom is exempt from every BSI-facing obligation — confirm your registration status directly with BNetzA and BSI rather than assuming either one covers it.

Gap Analysis: TKG §166 Baseline vs. What NIS2 Adds

TKG §166 has required a Sicherheitsbeauftragter (security officer), an EU-based contact person, and a Sicherheitskonzept (security concept) submitted to BNetzA since the 2021 TKG came into force — network operators file it immediately on starting operations, and BNetzA can demand it from service providers on request, then reviews it at least every two years. That’s a real head start. But the original §166 concept was drafted to describe networks operated, threats faced, and technical measures in place — it was never written with NIS2’s more granular sub-measures in mind.

Requirement	Current state (TKG 2021 baseline)	Required state (post-NIS2)	Effort to close
Security governance	Sicherheitskonzept describing threats and measures generally (§166)	Documented risk analysis + IT-security concept as a standalone, auditable artefact (§165(2a) / §30 BSIG measure 1)	Low–Medium — reframe existing concept, don’t rebuild it
Supply chain security	Not addressed in the original §166 concept	Documented supplier/vendor risk assessment covering direct suppliers	High — net-new register and contractual review
Cryptography policy	Not addressed	Formal concepts and processes for cryptographic use	Medium — most operators have practices, few have them as policy
MFA / continuous authentication	Not addressed	Multi-factor or continuous authentication plus secured voice/video/text channels	Medium–High depending on legacy OSS/BSS estate
Effectiveness assessment	BNetzA’s own biennial review of the Sicherheitskonzept	An internal, recurring self-assessment procedure the entity runs itself, not just BNetzA’s check	Medium — process design, not new controls
Incident notification content	Report an "erheblicher Sicherheitsvorfall" to BNetzA and BSI	Same trigger and timeline, but now explicitly framed inside the wider NIS2 all-hazards incident-handling measure	Low — mostly a documentation-alignment exercise

The pattern across every row: TKG already gave German telecoms a reporting relationship and a governance artefact. What it didn’t give them was the specific control vocabulary — supply chain, cryptography, MFA, effectiveness testing — that NIS2 demands and that most Sicherheitskonzepte have never itemised. Compliance officers who put the two documents side by side tend to find their existing concept covers roughly a third of the ten measures explicitly; the rest exist informally in practice but were never written down as a named policy.

One Incident, Two Regulators

The reporting mechanic itself doesn’t change with NIS2 — it was already a two-authority process under §168 TKG, and that provision continues to apply instead of BSIG’s general incident-reporting section (which, per §28(5), telecom is exempted from).

Stage	Deadline	Recipient(s)
Early notification	Immediately, no later than 24 hours after becoming aware	Bundesnetzagentur and BSI
Full report	Immediately, no later than 72 hours	Bundesnetzagentur and BSI
Final report	Within 1 month of resolution (interim progress report first if still ongoing)	Bundesnetzagentur and BSI

That timeline will look familiar to anyone who has read NIS2 Article 23 — it’s the same 24-hour/72-hour/one-month cadence used across every other sector. The practical difference for telecom is the destination: one filing, two inboxes, and (per §168 TKG) a parallel duty to tell affected users what protective steps they can take, which most non-telecom NIS2 sectors don’t carry as a standing obligation.

BNetzA’s New Technical Catalog vs. CIR 2024/2690

A common assumption is that Commission Implementing Regulation (EU) 2024/2690 — the detailed technical Annex that gives NIS2 its granular controls — applies to telecom the way it applies to cloud or DNS providers. It doesn’t. CIR 2024/2690’s binding scope covers 11 specific digital-infrastructure entity types (DNS providers, TLD registries, cloud, data centre, CDN, managed service and managed security providers, online marketplaces, search engines, social platforms, and trust services) — electronic communications providers aren’t on that list.

Germany didn’t leave telecom without an equivalent technical benchmark, though — it updated its own. BNetzA’s Katalog von Sicherheitsanforderungen under §167 TKG went out for a revised draft in November 2025 (consultation closed 16 January 2026, updating the prior version from 2020), and for the first time it splits obligations into three hazard tiers: Normal (fewer than 10 staff and under €2M turnover/balance sheet), Elevated (up to 50 staff or up to €10M), and Increased — which covers everyone above those thresholds plus 5G network operators and CER-designated critical-infrastructure operators, regardless of headcount. Each tier layers on top of the one below it, so an Increased-tier carrier inherits every Normal- and Elevated-tier control plus its own additional set. In effect, this catalog is doing for German telecom what CIR 2024/2690 does for cloud and DNS providers — just through a national instrument rather than an EU one, and with 5G-specific obligations CIR was never written to anticipate.

Governance: Article 20 Still Applies

The BSIG carve-out in §28(5) is scoped to risk-management measures, reporting, and BSI’s supervisory toolkit — it doesn’t touch NIS2 Article 20’s management-body accountability requirement, which sits at the Directive level and isn’t sector-carved. Telecom leadership approves and oversees risk-management measures and can be held to the same standard of diligence as management at any other essential or important entity. A Sicherheitskonzept signed off without board-level visibility satisfies §166 TKG’s submission requirement but doesn’t satisfy Article 20’s governance expectation — those are two separate obligations that happen to attach to the same document.

Compliance Checklist and Key Dates

• Confirm your tier now: map your entity against the Normal/Elevated/Increased hazard classification once BNetzA finalises the revised catalog (post-16 January 2026 consultation) — the tier determines which controls apply, not just your entity’s essential/important status.
• Audit your existing Sicherheitskonzept against the ten §165(2a) measures — most gaps concentrate in supply chain, cryptography, and MFA, per the table above.
• Verify your registration status with both BNetzA and BSI directly — §33 BSIG‘s registration duty is not part of the telecom carve-out, and BSI’s own sector FAQ is thin enough on this point that relying on assumption is the wrong move.
• Confirm incident-reporting distribution lists include both BNetzA and BSI — a report to only one authority does not satisfy §168 TKG.
• Track the TKG reform planned for 2026, which is expected to align telecom’s obligations more closely with the standard BSIG essential/important-entity categories over time.

On penalties: NIS2 Article 34 sets the Directive-wide ceiling — up to €10 million or 2% of worldwide turnover (whichever is higher) for essential entities, and €7 million or 1.4% (whichever is higher) for important entities. Because §28(5) BSIG also exempts telecom from BSIG’s own enforcement sections, exactly which fine schedule a German regulator applies to a telecom-specific violation — TKG’s own administrative-fine provisions or the BSIG schedule transposing Article 34 — is a live question this article won’t resolve by picking one side. Confirm the applicable mechanism with legal counsel or BNetzA directly before treating either figure as settled for your entity.

Frequently Asked Questions

Does having a TKG §166 Sicherheitskonzept mean I’m already NIS2-compliant?
No. It satisfies the governance-documentation half of one measure. The gap-analysis table above shows the sub-measures — supply chain, cryptography, MFA, effectiveness assessment — that most existing concepts don’t address at all.

Do I register with BSI, Bundesnetzagentur, or both?
Bundesnetzagentur is your primary regulator for the security-concept and technical-catalog side. §33 BSIG’s registration duty isn’t in the telecom carve-out list, so don’t assume BNetzA’s existing licensing records substitute for it — confirm directly with both authorities.

Is CIR 2024/2690 relevant to my organisation at all?
Not as a binding requirement — telecom isn’t one of the 11 entity types it covers. It’s useful only as a reference point for how granular EU-level technical annexes get; BNetzA’s own §167 TKG catalog is the instrument that actually binds you.

What changes when the 2026 TKG reform lands?
Expect closer alignment between telecom’s hazard tiers and the standard BSIG essential/important-entity categories — but the reform hadn’t been finalised at the time of writing, so treat specifics as directional, not fixed.

This article provides general information only and does not constitute legal or regulatory advice. Requirements may vary by jurisdiction and organisation type. Consult a qualified legal professional or compliance specialist for advice specific to your situation.

Sources

• NIS2 Directive (EU) 2022/2555, Article 2 — nis-2-directive.com
• § 166 TKG 2021 — gesetze-im-internet.de
• § 168 TKG 2021 — gesetze-im-internet.de
• § 30 BSIG 2025 — gesetze-im-internet.de
• § 28 BSIG 2025 — gesetze-im-internet.de
• § 33 BSIG 2025 — gesetze-im-internet.de
• "NIS-2 Sektorspezifische FAQ" — BSI (bsi.bund.de)
• "Der überarbeitete Katalog von Sicherheitsanforderungen der Bundesnetzagentur" — BBH (bbh-blog.de)
• CIR 2024/2690 Annex — Advisera (advisera.com)

For the EU-wide version of this comparison, see our guide on EECC Article 40 vs. NIS2 Article 21 for telecom operators. For Germany’s general BSI supervision model outside telecom, see Germany’s NIS2 Competent Authority and how Germany’s BSI selects NIS2 fines.