NIS2 for Automotive Suppliers: What Germany’s NIS2UmsuCG Means for Tier-1s and Tier-2s

On 6 December 2025, Germany’s NIS2 implementation act — the NIS2UmsuCG, promulgated in the Federal Law Gazette a day earlier (BGBl. 2025 I Nr. 301) — entered into force and recast the BSI-Gesetz, the statute behind the Federal Office for Information Security (BSI). With it, an officially estimated 29,850 German companies came under direct federal cybersecurity supervision — and vehicle and parts manufacturing is named in the annex of regulated sectors. If your company builds ECUs, harnesses, sensors, or embedded software in Germany — or owns a German subsidiary that does — NIS2 is now your law too.

This post covers who is affected, the registration timeline — including what happens if you missed the deadline, as many companies did — the duties in §30 and §32, and the question we hear most from engineering leaders: how does this relate to UNECE R155, ISO/SAE 21434, and TISAX, and how much existing work can be reused?

Why a Vehicle-Cybersecurity Company Is Writing About an IT-Security Law

Agnile’s day job is Automotive Cybersecurity — Threat Analysis and Risk Assessment, building out the Cybersecurity Management System, and Type Approval evidence under UNECE R155. NIS2 is none of those things. It is a horizontal IT-security law that regulates organizations, not vehicles. Vehicles are deliberately left out: product-level cybersecurity of the car runs through Type Approval under Regulation (EU) 2019/2144, which applies UNECE R155 — and the EU’s Cyber Resilience Act exempts type-approved vehicles for exactly that reason.

The reason to write about it anyway is that a Tier-1 or Tier-2 supplier is one legal entity with two attack surfaces. The first is the product — the ECU, its software, its vehicle interfaces. The second is the organization that engineers and builds the product: the plants, the enterprise IT, and the engineering network where TARA reports, signing keys, diagnostic tooling, and OEM interface documents live. UNECE R155 reaches the first surface, indirectly, through the requirements OEMs cascade down the supply chain — the mechanics are described in our UNECE R155 compliance roadmap. NIS2 reaches the second surface directly, with your German legal entity as the addressee. “Our products are regulated under R155” is therefore not an argument against NIS2 applicability; the two regimes regulate different objects and simply meet inside the same company.

Who Is Affected: Anlage 2, NACE C29/C30, and the Size Thresholds

The recast BSIG defines its scope through sector annexes plus size thresholds. Automotive manufacturing falls under Anlage 2, which lists regulated sectors by their NACE Rev. 2 statistical classification. Divisions C29 (Herstellung von Kraftwagen und Kraftwagenteilen — the manufacture of motor vehicles and motor-vehicle parts) and C30 (other transport equipment) are both included. The size threshold is low by automotive standards: 50 or more employees, or more than EUR 10 million in annual turnover or balance-sheet total. Entities that meet it are, as a rule, classified as wichtige Einrichtungen(important entities) — the second of the law’s two supervision tiers, alongside besonders wichtige Einrichtungen (particularly important entities).

The official estimate puts the affected population at roughly 29,850 entities across all sectors — 8,250 particularly important and 21,600 important entities. A mid-sized Tier-2 machining supplier with 60 employees clears the threshold just as a multi-site Tier-1 does. Important entities carry the same substantive §30 duties as the higher tier; the difference is supervisory intensity — the BSI acts when there is cause rather than through routine audits.

For global groups, the analysis is entity by entity. A German GmbH of a US, Japanese, or Indian Tier-1 that meets the sector and size tests is in scope on its own account, regardless of where the parent sits — and groups with several German entities may owe several registrations. This is worth an afternoon with your legal team now, not after a BSI letter arrives.

The Registration Timeline — and the Deadline Most Companies Missed

§33 BSIG required in-scope entities to register with the BSI within three months of the duties applying — 6 March 2026. That deadline has lapsed, and compliance lagged far behind it: by the end of May 2026 only about 18,500 of the estimated 29,850 affected entities had registered.

The BSI responded with an administrative grace period — a Nachfrist — announced by letter on 12 June 2026 and running until 31 July 2026. Two things matter about it. It was supervisory forbearance, not a change in the law — the statutory deadline had already passed. And it was tied to a date; that date does not reset the underlying duty.

Missed the Deadline?

If you are reading this after 31 July 2026 and your entity is still unregistered, the obligation has not expired — registration under §33 is a continuing duty, and registering late remains both legally required and materially better than staying dark. What changes after the grace period is the BSI’s posture: it can issue binding supervisory orders, demand evidence of compliance, and pursue fines. For registration violations the recast BSIG provides fines of up to EUR 500,000. Registration is the cheapest part of NIS2 compliance — an online notification, not an audit — and the wrong place to accumulate legal risk. Register first, then work the substantive gaps.

The Core Duties: §30 Risk Management and §32 Incident Reporting

Registration is the entry ticket; the substance sits in two paragraphs. §30 BSIG requires proportionate technical and organizational risk-management measures for the entity’s network and information systems. The catalogue follows the European NIS2 baseline: risk analysis and security policies, incident handling, business continuity and backups, supply-chain security, secure acquisition and development, training and cyber hygiene, cryptography, access control, and multi-factor authentication. For a manufacturing company this explicitly includes the production side — plant networks and OT systems are network and information systems in the law’s sense, not just office IT.

§32 BSIG adds staged reporting of significant incidents to the BSI: an early warning within 24 hours of becoming aware, a fuller notification within 72 hours, and a final report once the incident is worked through. Ransomware in a plant, a compromised engineering fileshare, or an attack on a logistics system can all qualify. The law also places approval and oversight duties on management personally — the days of delegating cybersecurity entirely to the IT department are, legally speaking, over.

NIS2 vs UNECE R155 vs ISO/SAE 21434 vs TISAX

Automotive suppliers now answer to four cybersecurity frameworks that are routinely confused with one another. The clean way to separate them is by regulated object: one regulates the organization, one the vehicle type, one the engineering process, and one is a customer-driven assessment of information security.

One reading of this table is worth making explicit: NIS2 is the only regime in the set that puts a state supervisory authority directly over the supplier’s organization — R155 gates the OEM’s market access, while ISO/SAE 21434 and TISAX are enforced through contracts and customer demands. And ISO/SAE 21434 is the only one that tells engineers how to work, which is exactly why the reuse question matters.

Reusing Your CSMS: Where ISO/SAE 21434 Work Maps Onto §30

Suppliers that have built a Cybersecurity Management System for their OEM customers already operate a good share of what §30 demands — under a different name and with a product scope. Three overlaps carry most of the weight.

Incident response. An ISO/SAE 21434-conformant organization runs incident response for product-security events — triage, analysis, remediation, and notification to affected OEM customers under its Cybersecurity Interface Agreements. §32 adds a second reporting channel with hard clocks: the BSI at 24 and 72 hours. The efficient answer is one incident process with two output channels, not two teams. Align the severity definitions, put the §32 deadlines into the existing escalation procedure, and make sure a plant OT incident triggers the same machinery as a product vulnerability.

Vulnerability handling. The continual cybersecurity activities of ISO/SAE 21434 Clause 8 — monitoring, vulnerability analysis, and Vulnerability Management — are a direct counterpart to the incident-handling and risk-analysis measures §30 expects. A single intake and triage pipeline can serve both scopes; the delta is coverage of enterprise and production assets alongside product components.

Supplier management.Clause 7 of ISO/SAE 21434 already forces a supplier to assess the cybersecurity capability of its own sub-suppliers and to formalize responsibilities in interface agreements. §30’s supply-chain security measure asks the same discipline of the entity’s IT and service providers. The questionnaires, capability criteria, and contract clauses your CSMS team wrote for Tier-2s extend naturally to IT vendors, and evidence collected for TISAX or ISO 27001 slots into the same file.

The practical sequence we recommend: register (if not already done), run a gap analysis of §30 against your existing CSMS and information-security management, and close the gaps from the overlap zones outward. Teams that want the product-side foundation first will find the full clause map in our ISO/SAE 21434 guide.

Where Agnile Fits

Agnile works the vehicle side of this picture — Threat Analysis and Risk Assessment, CSMS build-outs, and UNECE R155 Type Approval evidence. NIS2 does not change that scope, but it raises the value of doing shared processes once: incident response, Vulnerability Management, and supplier interfaces built for ISO/SAE 21434 are the same muscles §30 exercises. If your team wants the two regimes to reinforce rather than duplicate each other, that is a conversation worth having early.