Die European Payment Initiative (EPI) hat am 17.07.2026 die Security Requirements v1.2 veröffentlicht. Die neue Version betrifft insbesondere Governance, Application Security und Nachweisführung, also Bereiche, die sich direkt auf Umsetzung und Audit-Vorbereitung auswirken.
Wir begleiten EPI-Teilnehmer als akkreditierter External Security Evaluator in Sicherheitsbewertungen und in der Audit-Vorbereitung. Unser Kollege Phillip Meyer hat daher die neue Version daraufhin geprüft, was sich für Sie konkret ändert. Dies ist besonders wichtig, da EPI ab dem 1. August 2026 nur noch Security Evaluations auf der Grundlage von Version 1.2 akzeptieren wird.
Das Wichtigste in Kürze:
- DORA statt EBA Guidelines: EPI verankert die Anforderungen stärker in einer verbindlichen EU‑Regelung mit Fokus auf IKT‑Risikomanagement und Incident Handling.
- Mehr AppSec: Mobile Security wird eigenständiger. Hinzu kommt eine Control für APIs & Web Applications, die diesen Bereich erstmals als eigenständigen Prüfbereich strukturiert und mit Referenz auf OWASP ASVS fachlich vertieft.
- Key Management wird flexibler: Nicht mehr ausschließlich HSM, sondern auch gleichwertig abgesicherte Software‑Lösungen (praktisch relevant für Cloud‑Betrieb).
- Vulnerability Management wird präziser geregelt: CVSS v4.0 und feste Prüfintervalle konkretisieren die Anforderungen.
- Supply Chain Sicherheit: Version Pinning für Dependencies wird explizit verpflichtend.
- Zertifikatsvalidierung: Mehr Umsetzungsoptionen für mobile Anwendungen erlaubt EPI nun neben Pinning alternativ auch Certificate Transparency Monitoring.
Regulatorischer Bezug: DORA ersetzt die EBA Guidelines
EPI verweist in Version 1.2 nicht mehr auf die EBA Guidelines, sondern auf die DORA-Verordnung. Damit rücken verbindliche Anforderungen stärker in den Fokus, insbesondere zu IKT-Risikomanagement, Third Party Riskmanagement und Incident Handling & Reporting.
Was das für Sie heißt: Richten Sie Ihr ISMS und Ihr Risikomanagement‑Framework so aus, dass Sie Anforderungen zu Drittparteien und Incidents nicht nur erfüllen, sondern konsistent steuern und belastbar nachweisen.
Application Security: Neue Struktur, neue Prüfschwerpunkte
Control 8.0: Mobile Application Security: Mobile Security steht in v1.2 klarer als eigenständige Control. Das erhöht das den Bedarf an spezifischen Nachweisen, z. B. Architektur, Security Controls und Tests, getrennt von Secure Development im Allgemeinen.
Neue Control 9.0: APIs & Web Applications (inkl. OWASP ASVS): EPI ergänzt eine neue Control für APIs & Web Applications und referenziert OWASP ASVS als Standard für prüfbare technische Security Controls und Secure‑Development‑Anforderungen.
Was das für Sie heißt: Sie benötigen ein konkretes Prüf- und Nachweisraster, das sich je Anwendung anwenden lässt, zum Beispiel:
- ASVS-Level pro Anwendung festlegen
- Controls testbar machen (Definition, Testfall, Ergebnis, Nachweis)
- Verifikation wiederholbar organisieren (nicht als Einmal-Aktion)
Key Management: Mehr Spielraum, aber mit Nachweis der Schutzwirkung
Die Version 1.2 lässt neben HSM auch Software‑basierte Lösungen zu, sofern Sie gleichwertig abgesichert wird (z. B. Hardening, Zugriffskontrolle, Logging, kein Offenlegen von Schlüsselmaterial).
Gerade in Cloud-Umgebungen arbeiten viele Teams mit Managed Services zur Schlüsselverwaltung (z.B. AWS KMS, Azure Key Vault). Die neue Version eröffnet hier zusätzliche Umsetzungsoptionen.
Was das für Sie heißt: Sie gewinnen Flexibilität. Für die Bewertung ist aber entscheidend, dass Sie die Schutzwirkung Ihrer Lösung nachvollziehbar belegen, insbesondere Betrieb, Rollen, Logs, Key Lifecycle und technische Härtung.
Vulnerability Management: CVSS v4.0 und klare Taktung
EPI stellt auf CVSS v4.0 um. Damit ändert sich die Bewertungslogik für Schwachstellen. Bewertungen lassen sich nicht mehr direkt mit CVSS v3.1 vergleichen und können sich im Einzelfall deutlich verschieben. In der Folge sollten bestehende Bewertungslogiken, Schwellwerte und die Unterstützung durch eingesetzte Tools überprüft werden. Beispiel: Wird eine Schwachstelle unter CVSS v3.1 ab einem Wert von 7,0 als hoch eingestuft, kann es unter CVSS v4.0 zu Verschiebungen kommen, sodass auch Findings diesen Schwellwert erreichen, die zuvor darunter lagen.
Zusätzlich konkretisiert v1.2 das Vulnerability Management durch feste Prüfintervalle für Scans und Pentests sowie klare Schwellenwerte. Monatliche Schwachstellenscans und jährliche Pentests werden damit verbindlicher vorgegeben.
Was das für Sie heißt: Stellen Sie Tooling, Bewertungslogik und Release‑Gates so auf, dass Sie CVSS v4.0 konsistent verarbeiten und Findings nachvollziehbar priorisieren.
Supply Chain Sicherheit: Version Pinning wird verbindlich
EPI verschärft in v1.2 den Umgang mit Software‑Abhängigkeiten: Dependencies müssen auf konkrete Versionen gepinnt werden. Ziel sind reproduzierbare Builds, kontrollierte Updates und weniger Risiko durch ungeprüfte Versionssprünge.
Was das für Sie heißt: Für die Umsetzung und den Nachweis benötigen Sie verbindliche Regeln im CI/CD-Setup, zum Beispiel Lockfiles, Freigabe-Gates und einen definierten Update-Prozess, der Dependency-Updates kontrolliert und reproduzierbar macht.
Zertifikatsvalidierung: Certificate Tranparency Monitoring als Alternative
Version 1.2 hält am Grundprinzip einer starke Zertifikatsvalidierung fest, lässt aber mehr Umsetzungswege zu: Neben Certificate Pinning akzeptiert EPI auch Certificate Transparency (CT) Monitoring als Alternative. CT beschreibt ein Protokoll zum öffentlichen Logging von TLS‑Zertifikaten, um CA‑Aktivität auditierbar zu machen und verdächtige Zertifikate schneller zu erkennen.
Was das für Sie heißt: Entscheidend ist, dass Sie die gewählte Lösung nachvollziehbar belegen, zum Beispiel durch dokumentierte Monitoring- und Reaktionsprozesse sowie entsprechende Nachweise.
Was Sie jetzt konkret vorbereiten sollten
Die neuen EPI Security Requirements schärfen regulatorische Erwartungen, erweitern technische Prüfpunkte und erhöhen die Anforderungen an nachvollziehbare Nachweise. Mein Rat an betroffene Unternehmen ist, jetzt gezielt zu prüfen, wo Governance, Secure Development und Kontrollnachweise nachgeschärft werden müssen, bevor daraus Zeitdruck im Audit entsteht.
Phillip Meyer, Managing Security Consultant, usd AG
Unser Tipp - starten Sie mit diesen vier Punkten:
- DORA‑Mapping: Verankern Sie DORA‑Bezüge in Controls, Policies und Nachweisen
- ASVS als Prüfmaßstab: Definieren Sie ASVS‑Level je Anwendung und bauen Sie Tests/Nachweise darauf auf.
- CVSS v4.0‑Umstellung: Passen Sie Tools/Prozesse an, inklusive Severity‑Schwellen und Reporting.
- Dependency‑Governance: Erzwingen Sie Version Pinning über CI‑Gates und definieren Sie einen kontrollierten Update‑Prozess.
Sie möchten wissen, wie gut Sie auf die EPI Security Requirements v1.2 vorbereitet sind? Wir begleiten Sie bei der Bewertung, Audit-Vorbereitung und Umsetzung. Kontaktieren Sie uns.
