Euro 7 Anti-Tampering zieht Cybersicherheit in den Typgenehmigungs-Geltungsbereich. Die meisten Kontrollen existieren bereits in Ihrem R155-CSMS — neu ist die emissionsbezogene Beweismittel-Sicht darauf.
Euro 7 wird üblicherweise als Emissionsregulierung diskutiert. Diese Beschreibung ist korrekt, aber unvollständig. Bei softwaredefinierten Fahrzeugen hängt die Compliance zunehmend davon ab, ob emissionsrelevante Software, Kalibrierungswerte, Monitoring-Logik, Umweltdaten und Serviceprozeduren über den gesamten Fahrzeuglebenszyklus hinweg vertrauenswürdig sind.
Damit ist Euro 7 ebenso eine Anti-Tampering- und Software-Governance-Aufgabe wie eine Emissions-Engineering-Aufgabe.
Die Verordnung schließt Anti-Tampering-, Security- und Cybersecurity-Systeme ausdrücklich in den Typgenehmigungsrahmen ein. Ihre Durchführungsregeln erweitern die operative Bedeutung von On-Board-Monitoring, Umweltinformationen des Fahrzeugs, sicherem Datenaustausch, Dauerhaltbarkeit und Beweismitteln. Die praktische Frage für Hersteller lautet nicht mehr nur: "Hat das Fahrzeug während eines Tests den Grenzwert eingehalten?" Sie lautet auch: "Können wir nachweisen, dass die Software und Parameter, die dieses Ergebnis beeinflussen, autorisiert, rückverfolgbar und geschützt geblieben sind?"
Dieser Leitfaden erklärt, wie OEMs und Lieferanten Euro 7 in ein Engineering- und Governance-Programm übersetzen können. Er konzentriert sich auf emissionsrelevante Software und Daten, statt allgemeine UNECE R155- oder ISO/SAE 21434-Leitlinien zu wiederholen.
Warum Euro 7 einen neuen Cybersicherheits-Workstream erzeugt
Moderne Emissionsleistung hängt von Code und Konfiguration ab. Motor-, Abgasnachbehandlungs-, Batterie-, Brems-, Energiemanagement- und Monitoringfunktionen nutzen programmierbare Logik, die sich über Entwicklung, Produktion, Service und teils über Over-the-Air-Updates verändert. Eine Kalibrierungsänderung kann das Emissionsverhalten verändern, ohne dass eine physische Komponente getauscht wird. Eine kompromittierte Diagnose-Credential kann geschützte Parameter offenlegen. Eine Schwachstelle in der Datenpipeline kann die Zuverlässigkeit von Informationen untergraben, die Behörden oder Nutzern präsentiert werden.
Euro 7 erweitert daher die Assurance-Grenze über das Auspuffende hinaus. Hersteller benötigen Vertrauen in fünf vernetzten Bereichen:
- Die auf dem Fahrzeug installierte Software und Kalibrierung sind für diese Variante zugelassen.
- Geschützte Parameter lassen sich nicht über unautorisierte Werkzeuge, Konten oder Update-Pfade verändern.
- Monitoring- und Umweltdaten sind authentisch, vollständig und der korrekten Fahrzeugkonfiguration zuordenbar.
- Reparaturen und autorisierte Modifikationen bleiben möglich, ohne eine unkontrollierte Umgehung zu schaffen.
- Beweismittel überdauern Software-Updates, Lieferantenwechsel, Serviceaktivitäten und lange Fahrzeuglebenszeiten.
Diese Anforderungen erstrecken sich über Emissionen, Cybersicherheit, funktionale Sicherheit, Diagnose, Qualität, Homologation, Recht, Aftersales und Lieferantenmanagement. Euro 7 als Dokument eines einzigen Compliance-Teams zu behandeln, erzeugt Lücken genau an den Stellen, an denen Software organisatorische Grenzen überschreitet.
Zeitplan und Planungsimplikationen von Euro 7
Regulation (EU) 2024/1257 gilt in Phasen. Sie gilt für neue M1- und N1-Fahrzeugtypen ab dem 29. November 2026 und für neue M1- und N1-Fahrzeuge ab dem 29. November 2027. Schwerlast- und Anhängerkategorien folgen ab dem 29. Mai 2028 für neue Typen und dem 29. Mai 2029 für neue Fahrzeuge, mit spezifischen Bestimmungen für Kleinserienhersteller.
Diese Termine sind nahe genug, dass Architektur- und Beweismittelentscheidungen vor der finalen Homologationsphase getroffen werden müssen. Ein Hersteller, der wartet, bis das Typgenehmigungspaket zusammengestellt wird, kann feststellen, dass er nicht rekonstruieren kann, welche Kalibrierung, welcher Software-Build, welche Diagnose-Zugriffspolitik oder welche Lieferantenkontrolle zum Zeitpunkt eines Tests aktiv war.
Eine praktische Planungsabfolge:
- Programmklassifizierung: Fahrzeugtypen, Systeme, Komponenten und separate technische Einheiten identifizieren, die von den gestaffelten Terminen betroffen sind.
- Asset-Discovery: emissionsrelevante Software, Kalibrierungssätze, Monitoringfunktionen, Datenkanäle, Servicewerkzeuge, Signierschlüssel und Backends auflisten.
- Kontroll-Review: aktuelle Schutzmaßnahmen mit Euro 7 Anti-Tampering- und Secure-Data-Erwartungen vergleichen.
- Beweismittel-Design: festlegen, was bei Release, Produktion, Service, Update und Test aufgezeichnet werden muss.
- Pilot: den Ansatz an einem Antriebsstrang oder einer elektrifizierten Plattform nachweisen, bevor er über Marken und Regionen skaliert wird.
Das Ziel ist kein zweites Cybersecurity-Programm. Das Ziel ist, dem bestehenden Software-, Cybersicherheits- und Typgenehmigungs-Betriebsmodell der Organisation eine emissionsbezogene Assurance-Sicht hinzuzufügen.
Was sollte als emissionsrelevantes digitales Asset behandelt werden?
Ein zu enges Asset-Inventar ist einer der häufigsten Fehler. Teams listen oft nur das Motorsteuergerät auf und hören damit auf. Die tatsächliche Assurance-Kette kann Folgendes umfassen:
- Ausführbare Software in Antrieb, Abgasnachbehandlung, Energiemanagement, Thermomanagement, Bremsen und Batterieregelung.
- Kalibrierungsdateien, Kennfelder, Schwellenwerte, Adaptionswerte, gelernte Parameter und Diagnoseroutinen.
- On-Board-Diagnose- und On-Board-Monitoring-Logik.
- Daten des Environmental Vehicle Passport und die Schnittstellen, die zur Anzeige oder Übertragung verwendet werden.
- Software-Kennzeichnungen, Variantencodierung, Bootloader-Konfiguration und Secure-Boot-Richtlinien.
- Update-Pakete, Manifeste, Signing-Infrastruktur, Deployment-Freigaben und Rollback-Kontrollen.
- Werkstattwerkzeuge, Engineering-Werkzeuge, Händler-Credentials, Serviceprozeduren und Remote-Diagnosedienste.
- Lieferanten-Binaries, Kalibrierungs-Lieferungen, Testberichte und Konfigurationserklärungen.
- Backend-Dienste, die Monitoring- und Dauerhaltbarkeitsdaten empfangen, verarbeiten, speichern oder melden.
- Audit-Logs, die zeigen, wer was wann, warum und unter welcher Freigabe geändert hat.
Jedes Asset braucht einen Eigentümer, eine Quelle der Wahrheit, einen genehmigten Änderungspfad, eine Aufbewahrungsregel und eine Verknüpfung zu den Fahrzeugkonfigurationen, in denen es verwendet wird. Ohne diese Beziehungen kann eine technisch starke Sicherheitskontrolle operativ versagen, weil niemand ihren Geltungsbereich bestimmen kann.
Die wichtigsten Euro 7 Tampering-Szenarien
Die Euro 7 Bedrohungsanalyse sollte mit plausiblen Geschäfts- und Engineering-Szenarien beginnen, nicht mit einer generischen Liste von Cyberangriffen.
Unautorisierte Kalibrierungsänderung
Ein Angreifer, eine Werkstatt, ein Flottenbetreiber oder ein Insider ändert emissionsrelevante Parameter, um die Leistung zu steigern, Monitoring zu deaktivieren, Verschleiß zu verschleiern oder Reparaturkosten zu vermeiden. Die Modifikation kann einen offengelegten Diagnose-Service, ein durchgesickertes Engineering-Credential, ein geklontes Werkzeug, einen verwundbaren Bootloader oder ein manipuliertes Update-Paket nutzen.
Monitoring-Unterdrückung oder -Verfälschung
On-Board-Monitoring wird deaktiviert, Schwellenwerte werden geändert, Fehlerzustände ohne Autorisierung gelöscht oder Daten werden verändert, bevor sie das Display, das Backend oder das Beweismittelpaket für die Genehmigung erreichen. Das Fahrzeug kann weiterbetrieben werden, während sein Umweltzustand falsch dargestellt wird.
Varianten- und Software-Mismatch
Ein gültiges Software- oder Kalibrierungspaket wird auf der falschen Hardware, dem falschen Antrieb, der falschen Marktvariante oder Fahrzeug-Identifikationsnummer installiert. Es wird nichts böswillig verändert, aber die Konfigurationsintegrität geht verloren, und das zugelassene Emissionsverhalten gilt nicht mehr.
Unautorisierter Servicezugriff
Eine legitime Reparaturfähigkeit wird missbraucht. Credentials werden geteilt, Händlerkonten werden kompromittiert, Zugriffsrechte sind zu breit, oder Servicewerkzeuge können Funktionen über die Rolle des Technikers hinaus ausführen. Das Risiko ist besonders hoch, wenn dasselbe Credential über große Teile einer Flotte hinweg gültig ist.
Manipulation der Beweismittelkette
Testergebnisse, Genehmigungsdaten, Software-Kennungen oder Monitoring-Exporte werden geändert, unvollständig übertragen oder mit der falschen Baseline assoziiert. Das Fahrzeug ist möglicherweise konform, der Hersteller kann es aber nicht zuverlässig nachweisen.
Lieferantenwechsel ohne Impact-Review
Ein Tier-1 ändert Software, Kalibrierung, eine Bibliothek, eine Diagnoseroutine oder einen Produktionsprozess, ohne den Euro 7 Impact-Workflow des OEM auszulösen. Die Änderung kann lokale Tests bestehen, während sie Annahmen im fahrzeugübergreifenden Genehmigungsfall ungültig macht.
Diese Szenarien sollten nach Fahrzeugtyp und Architektur bewertet werden. Derselbe Diagnose-Service kann ein sehr unterschiedliches Risiko haben, je nachdem, ob er nur über ein kontrolliertes Werkstattwerkzeug oder remote über ein Telematik-Backend erreichbar ist.
Ein Kontrollmodell rund um Autorisierung, Integrität und Provenienz aufbauen
Ein effektives Euro 7 Kontrollmodell sollte leichter auditierbar sein als eine Sammlung isolierter Sicherheitsfunktionen. Strukturieren Sie Kontrollen entlang von fünf Zielen.
1. Jede sensitive Aktion autorisieren
Definieren Sie, wer oder was emissionsrelevante Informationen lesen, schreiben, zurücksetzen, neu flashen, kalibrieren oder exportieren darf. Die Autorisierung sollte den Akteur, den Fahrzeugzustand, die Werkzeug-Identität, den Standort, den Zweck und die Zielfunktion berücksichtigen.
Gute Praxis umfasst Least-Privilege-Rollen, kurzlebige Credentials, Mehrparteien-Freigabe für hochwirksame Änderungen, Trennung zwischen Entwicklungs- und Service-Privilegien und explizite Sperrung von Funktionen, die in der Produktion nicht gebraucht werden.
2. Software- und Parameter-Integrität schützen
Nutzen Sie Secure Boot, authentifizierte Updates, Code-Signing, geschützte Kalibrierungs-Container, Anti-Rollback-Maßnahmen und Integritätsprüfungen, die zum System passen. Schützen Sie den gesamten Pfad, nicht nur das finale Firmware-Image. Ein signiertes Paket hilft nicht, wenn das Manifest, das Varianten-Mapping, der Signing-Workflow oder die Installationsentscheidung manipuliert werden können.
3. Verlässliche Identität und Konfiguration etablieren
Jeder Test- und Betriebsdatensatz sollte einem Fahrzeug, einem ECU, einer Softwareversion, einem Kalibrierungssatz und der relevanten Hardwarekonfiguration zuordenbar sein. Die Softwarekennzeichnung muss Austausch, Servicekampagnen und Updates überdauern.
Hier treffen sich Konfigurationsmanagement und Cybersicherheit. Eine Release-Baseline sollte ein abfragbares Objekt sein, kein Dateiname in einem gemeinsamen Ordner.
4. Vertrauenswürdige Logs und Beweismittel bewahren
Zeichnen Sie sicherheitsrelevante Ereignisse wie Parameteränderungen, Softwareinstallation, Zugriffsversuche, Diagnose-Sessions, Signaturprüfung, Monitoring-Konfiguration und Genehmigungsentscheidungen auf. Logs sollten zeitsynchron, zugriffsgeschützt, gegen stille Veränderung geschützt und für den geforderten Lebenszyklus aufbewahrt werden.
Der Beweismittel-Datensatz sollte den Grund für eine autorisierte Änderung enthalten. Eine technisch gültige Modifikation ohne geschäftliche Begründung oder Freigabereferenz ist schwer zu verteidigen.
5. Abweichungen erkennen und darauf reagieren
Definieren Sie, wie unautorisierte oder unerwartete Zustände erkannt werden. Erkennung kann Software-Attestation-Prüfungen, Kalibrierungsvergleich, anomales Diagnoseverhalten, ungültige Signaturen, unerwartete Monitoring-Lücken oder Inkonsistenzen zwischen Fahrzeug- und Backend-Daten umfassen.
Response-Pläne sollten Eindämmung, Untersuchung, Wiederherstellung, Kundenkommunikation, Lieferanten-Eskalation und Neubewertung der Genehmigungs-Beweismittel abdecken.
Programmierbare Parameter steuern, ohne legitime Reparatur zu blockieren
Anti-Tampering-Kontrollen dürfen konforme Reparatur nicht unmöglich machen. Das schafft ein Policy-Problem: Die Organisation muss autorisierte Änderungen von unautorisierter Manipulation über viele Akteure und Umgebungen hinweg unterscheiden.
Ein praktikables Modell klassifiziert Parameter und Funktionen nach Sensitivität:
- Public Read: Informationen, die ohne nennenswertes Risiko offengelegt werden können.
- Authenticated Read: Daten, die verifizierten Service- oder Engineering-Rollen zugänglich sind.
- Controlled Write: Parameter, die unter einer genehmigten Prozedur geändert werden können.
- Restricted Write: hochwirksame Änderungen, die erhöhte Credentials, spezifische Fahrzeugzustände und protokollierte Autorisierung erfordern.
- Factory oder Engineering Only: Funktionen, die im normalen Service deaktiviert oder kryptografisch unzugänglich sind.
Dokumentieren Sie für jede Klasse die erlaubten Werkzeuge, Rollen, Vorbedingungen, Logging-, Freigabe- und Validierungsanforderungen. Nutzen Sie eine zentrale Policy, damit Marken und Lieferanten keine widersprüchlichen Zugriffsmodelle erfinden.
Die schwierigsten Fälle sind Ausnahmen: Feldreparaturen, regulatorische Tests, Retrofits, Motorsport- oder Spezialkonfigurationen und Notfall-Serviceaktionen. Ausnahmen sollten designt sein, nicht improvisiert. Sie brauchen Zeitlimits, Geltungsbereichsgrenzen, Rückverfolgbarkeit und einen Prozess zur Wiederherstellung des genehmigten Zustands.
Software-Updates mit dem Euro 7 Genehmigungsfall verknüpfen
Jedes Software-Update, das Emissionen, Energieverbrauch, Batterie-Dauerhaltbarkeit, Bremsstaub, Monitoring oder Umweltinformationen beeinflussen kann, sollte eine strukturierte Impact-Bewertung auslösen.
Die Bewertung sollte beantworten:
- Welche Funktionen, Parameter und Fahrzeugvarianten sind betroffen?
- Verändert das Update ein zuvor genehmigtes Verhalten oder eine Testannahme?
- Werden neue Angriffspfade oder Diagnose-Fähigkeiten eingeführt?
- Welche Verifizierungs- und Validierungsaktivitäten müssen wiederholt werden?
- Verändert das Update die erzeugten oder übertragenen Umweltdaten?
- Welcher Rollback- oder Recovery-Pfad existiert, falls das Deployment fehlschlägt?
- Welche Genehmigungs-, Compliance- und Lieferantendaten müssen aktualisiert werden?
Das Update-Paket sollte mit seinen Anforderungen, Quellcode-Änderungen, Kalibrierungsänderungen, Cybersecurity-Kontrollen, Testergebnissen, Freigaben und der ausgerollten Population verknüpft bleiben. Diese Rückverfolgbarkeit ist auch dann wertvoll, wenn keine formale erneute Genehmigung erforderlich ist, weil sie eine disziplinierte Steuerung der genehmigten Konfiguration belegt.
Lieferanten-Governance für Euro 7 Software und Kalibrierung
OEM-Beweismittel sind nur so stark wie die dahinterstehenden Lieferanteninformationen. Vertragliche Schnittstellen sollten mehr als ein Lieferdatum und eine Prüfsumme definieren.
Für emissionsrelevante Lieferungen sollten Sie Lieferanten verpflichten, bereitzustellen:
- Eindeutige Software- und Kalibrierungs-Kennungen.
- Eine Beschreibung geschützter Parameter und Diagnosefunktionen.
- Änderungshistorie und Impact-Klassifizierung.
- Nachweise zur Umsetzung von Sicherheitskontrollen.
- Verifikationsergebnisse für Anti-Tampering- und Zugriffskontrollanforderungen.
- Bekannte Einschränkungen, akzeptierte Abweichungen und Restrisiken.
- Verpflichtungen zu Schwachstellen-Meldung und Incident-Eskalation.
- Unterstützung bei Felduntersuchung und Konfigurations-Rekonstruktion.
- Sub-Lieferantenverpflichtungen, soweit relevant.
Der OEM sollte auch Akzeptanzkriterien definieren. Eine Lieferantenerklärung, dass Software "sicher" ist, ist nicht testbar. Ein nützliches Akzeptanzkriterium identifiziert die Kontrolle, die Testmethode, das erwartete Ergebnis, das Beweismittel-Format, den Eigentümer und die Gültigkeitsdauer.
Lieferanten-Beweismittel sollten programmübergreifend wiederverwendbar sein, während programmspezifischer Kontext erhalten bleibt. Wiederverwendung senkt Kosten, aber blinde Wiederverwendung kann Konfigurationsunterschiede verbergen. Plattform, Hardware-Revision, Funktionsumfang und Kalibrierungs-Geltungsbereich müssen explizit sein.
Das Euro 7 Beweismittelpaket
Ein verteidigbares Beweismittelpaket sollte einem Prüfer ermöglichen, von einer regulatorischen Erwartung zur tatsächlichen Fahrzeugkonfiguration und dem dahinterliegenden Engineering-Nachweis zu gelangen.
Ein praktisches Paket umfasst:
- Geltungsbereich und Fahrzeugtyp-Anwendbarkeit.
- Inventar emissionsrelevanter digitaler Assets.
- Architektur- und Datenfluss-Sichten.
- Bedrohungs- und Missbrauchsszenarien mit Fokus auf Tampering.
- Genehmigte Zugriffs- und Parameter-Governance-Richtlinien.
- Software- und Kalibrierungs-Baseline-Daten.
- Beweismittel für sichere Updates und Rollback.
- Design der Diagnose-Zugriffe und Testergebnisse.
- Monitoring-, Logging- und Anomalie-Erkennungs-Beweismittel.
- Lieferantenerklärungen und Verifikations-Artefakte.
- Change-Impact-Daten und Release-Freigaben.
- Incident-, Abweichungs- und Korrekturmaßnahmen-Historie.
- Beweismittel-Provenienz: Autor, Reviewer, Datum, Version und Quellsystem.
Das Paket sollte nicht vor der Genehmigung von Grund auf zusammengestellt werden. Es sollte aus aktuellen Engineering-Daten generiert werden. Das reduziert sowohl Audit-Aufwand als auch das Risiko, widersprüchliche Versionen der Wahrheit zu präsentieren.
Eine 90-Tage-Implementierungs-Roadmap
Tage 1-30: Geltungsbereich und Verantwortlichkeiten etablieren
Wählen Sie ein Fahrzeugprogramm. Identifizieren Sie betroffene Systeme, Eigentümer, Lieferanten, Werkzeuge und Genehmigungs-Meilensteine. Erstellen Sie das Inventar digitaler Assets und kartieren Sie aktuelle Software-, Kalibrierungs-, Diagnose-, Logging- und Update-Prozesse.
Tage 31-60: Die größten Risikolücken schließen
Priorisieren Sie remote- oder skalierbare Tampering-Pfade, uneingeschränkte Parameter-Schreibvorgänge, schwache Service-Identitäten, nicht rückverfolgbare Kalibrierungsänderungen und Beweismittel, die nicht an eine Release-Baseline gebunden werden können. Definieren Sie Kontrollanforderungen und Lieferantenaktionen.
Tage 61-90: Die Beweismittelkette nachweisen
Wählen Sie eine repräsentative Änderung, etwa ein Kalibrierungs-Update oder eine Monitoring-Software-Revision. Verfolgen Sie sie von der Anfrage über Umsetzung, Security-Review, Test, Freigabe, Deployment und Reporting. Erzeugen Sie die Euro 7 Beweismittel-Sicht ohne manuelle Dokumentsuche.
Am Ende des Piloten sollte die Organisation wissen, was skaliert werden kann, wo Werkzeugintegration nötig ist und welche Verantwortlichkeiten zwischen Emissions- und Cybersecurity-Teams geklärt werden müssen.
Kennzahlen, die zeigen, dass das Programm wirkt
Nützliche Kennzahlen konzentrieren sich auf Kontroll- und Beweismittelqualität statt auf Dokumentvolumen:
- Anteil emissionsrelevanter Software und Parameter mit benannten Eigentümern.
- Anteil sensitiver Schreibfunktionen mit expliziter Autorisierungs-Policy.
- Anteil der Releases mit vollständiger Software-Kalibrierung-Fahrzeug-Rückverfolgbarkeit.
- Zeit, um die genehmigte Konfiguration für eine VIN oder Variante zu rekonstruieren.
- Anteil der Lieferantenänderungen, die eine dokumentierte Impact-Bewertung auslösen.
- Anzahl hochwirksamer Parameter ohne verifizierten Anti-Tampering-Test.
- Alter der jüngsten Beweismittel für kritische Kontrollen.
- Zeit von der erkannten Abweichung zur Identifikation der betroffenen Flotte.
- Anzahl ungelöster Unterschiede zwischen Engineering-, Produktions-, Service- und Genehmigungs-Baselines.
Ein Dashboard sollte Teams ermöglichen, von der Kennzahl zu den zugrundeliegenden Beweismitteln zu navigieren. Ein grüner Prozentsatz ohne rückverfolgbare Datensätze liefert falsche Sicherheit.
Wie ein vernetztes Beweismittel-Modell hilft
Euro 7 schafft Beziehungen, die Tabellen schlecht abbilden: Software gehört zu einem ECU; ein ECU wird in mehreren Varianten verbaut; ein Parameter beeinflusst eine Funktion; eine Kontrolle schützt den Parameter; ein Test verifiziert die Kontrolle; ein Release ändert die Software; ein Lieferant verantwortet einen Teil der Implementierung; ein Genehmigungs-Datensatz gilt für eine bestimmte Baseline.
Ein vernetztes Cybersecurity- und Compliance-Modell macht diese Beziehungen abfragbar. Teams können fragen, welche Fahrzeugtypen eine Kalibrierung nutzen, welche Kontrollen sie schützen, welche Tests aktuell sind und welche Releases sie verändert haben. ThreatZ kann dieses Betriebsmodell unterstützen, indem es Architektur, Risiken, Kontrollen, Tests, Lieferanten, Software-Datensätze, Vorfälle und Berichte verknüpft, statt ein separates Euro 7 Dokument-Silo zu schaffen.
Ein praktischer Ausgangspunkt ist ein emissionsrelevantes System und ein realer Change-Workflow. Ziel ist es, vertrauenswürdige Konfiguration und Beweismittel vom Engineering bis zum Feldbetrieb zu demonstrieren.
Häufig gestellte Fragen
Ist Euro 7 eine Cybersecurity-Regulierung?
Euro 7 ist eine Emissions- und Fahrzeug-Dauerhaltbarkeits-Regulierung, schließt aber Anti-Tampering-, Security- und Cybersecurity-Systeme ausdrücklich ein. Bei softwaregesteuertem Emissionsverhalten werden Cybersecurity-Kontrollen Teil davon, wie Hersteller programmierbare Parameter, Monitoring, Daten und Genehmigungs-Integrität schützen.
Erfüllt UNECE R155-Compliance automatisch die Euro 7 Anti-Tampering-Anforderungen?
Nein. R155 bildet eine wichtige Cybersecurity-Management-Grundlage, aber Euro 7 hat einen anderen regulatorischen Zweck und Beweismittelkontext. Organisationen sollten Governance, Bedrohungsanalyse, Zugriffskontrolle, sichere Updates und Monitoring-Fähigkeiten wiederverwenden und dabei eine emissionsspezifische Anwendbarkeits- und Assurance-Sicht schaffen.
Welche Teams sollten Euro 7 Software-Anti-Tampering verantworten?
Die Verantwortung sollte über ein definiertes Governance-Modell geteilt werden. Emissions- oder Homologations-Teams bleiben für die regulatorische Compliance verantwortlich, während Cybersecurity-, Software-, Kalibrierungs-, Diagnose-, Aftersales-, Qualitäts- und Lieferantenteams spezifische Kontrollen und Beweismittel verantworten.
Sollte jeder Kalibrierungsparameter denselben Schutz erhalten?
Nein. Nutzen Sie eine risikobasierte Klassifizierung. Parameter, die reguliertes Verhalten, Monitoring, Sicherheit oder Beweismittel-Integrität wesentlich beeinflussen können, brauchen stärkere Autorisierung, Logging und Verifikation als wenig wirksame oder reine Leseinformationen.
Was ist der beste erste Pilot?
Wählen Sie ein System mit programmierbaren emissionsrelevanten Parametern, mehreren Lieferanten und einem realistischen Service- oder Update-Pfad. Verfolgen Sie eine genehmigte Änderung Ende-zu-Ende und testen Sie, ob die aktuelle Organisation nachweisen kann, wer sie autorisiert hat, was installiert wurde, wie sie validiert wurde und wo sie ausgerollt ist.
Maßgebliche Referenzen
- Regulation (EU) 2024/1257 - Euro 7
- EUR-Lex Euro 7 Technische Anforderungen und Zertifizierungsübersicht
- Commission Implementing Regulation (EU) 2025/1706