JBoss EAP 7 im Extended Life Cycle: Was das konkret bedeutet
Seit Juni 2025 läuft JBoss EAP 7 im Extended Life Cycle Support. Was sich ändert, was nicht mehr kommt und was das finanziell bedeutet.
Was der Extended Life Cycle Support konkret ändert
Seit Juni 2025 befindet sich JBoss EAP 7 im Extended Life Cycle Support (ELS). Das Ende ist auf Oktober 2027 datiert. Danach gibt es keine Patches mehr, keinen Red Hat Support, keine CVE-Fixes.
Der ELS klingt nach einer komfortablen Verlängerung. In der Praxis ist es ein abgestuftes Auslaufmodell mit konkreten Einschränkungen.
Im normalen Maintenance-Support erhält JBoss EAP 7 noch Bug-Fixes, Security-Patches und qualifizierte Updates für Drittkomponenten. Im ELS werden nur noch kritische Sicherheitslücken gepatcht - und auch das nur, wenn Red Hat intern entscheidet, dass der Aufwand vertretbar ist. Neue Features, Performance-Verbesserungen oder Kompatibilitätsarbeit für aktuelle Java-Versionen finden nicht mehr statt. Wer auf EAP 7 mit Java 17 oder Java 21 arbeiten will, bewegt sich auf nicht-unterstütztem Terrain.
Das bedeutet: Zwischen “es läuft” und “es ist supported” klafft eine wachsende Lücke.
Die Zeitlinie im Detail
Die relevanten Daten für Planungszwecke:
| Phase | Zeitraum |
|---|---|
| Full Support EAP 7.x | bis November 2023 |
| Maintenance Support EAP 7.x | November 2023 bis Mai 2025 |
| Extended Life Cycle Support | Juni 2025 bis Oktober 2027 |
| End of Life | ab November 2027 |
Wer heute plant, hat bis Oktober 2027 knapp 28 Monate im ELS-Fenster. Das klingt nach viel Zeit. Tatsächlich sind Enterprise-Migrationen von Middleware-Plattformen selten unter 12 bis 18 Monate zu realisieren, wenn man Abhängigkeiten, Tests und Staging-Prozesse einrechnet. Wer jetzt anfängt zu planen, startet nicht früh.
JBoss EAP 8, der logische Nachfolger, basiert auf WildFly 27+ und unterstützt Jakarta EE 10. Das ist eine API-Migration, kein Drop-in-Upgrade. Deployment-Deskriptoren, proprietäre Red-Hat-Erweiterungen und bestimmte Konfigurationsformate haben sich geändert.
Was Red Hat im ELS noch liefert und was nicht
Die Supportmatrix ist entscheidend für die Risikobewertung. Im Extended Life Cycle Support gilt laut Red Hat Lifecycle Policy:
- Kritische CVEs (CVSS 9.0+): werden gepatcht, aber nach Red Hats eigenem Zeitplan
- Wichtige CVEs (CVSS 7.0-8.9): werden bewertet, Patches sind nicht garantiert
- Moderate und Low CVEs: werden nicht mehr gepatcht
- Configuration issues, Bugs, Performance: kein Fix mehr
- Neue Zertifizierungen (z.B. neue JDBC-Treiber, neue JDKs): keine
Das bedeutet für Unternehmen in regulierten Umgebungen: Jede CVE-Meldung gegen JBoss EAP 7 muss manuell bewertet werden. Wer einen Vulnerability-Scanner gegen seine Middleware richtet, wird Funde sehen, für die es keinen offiziellen Patch gibt. Das ist ein Auditproblem, kein theoretisches Risiko.
2024 wurden gegen WildFly/JBoss über 30 CVEs gemeldet. Nicht alle sind kritisch - aber mehrere hatten CVSS-Werte zwischen 7.0 und 8.9, also im Bereich, für den es im ELS keine garantierten Fixes gibt.
Die Kostenstruktur des Extended Life Cycle
ELS ist kein kostenloser Verlängerungsservice. Red Hat berechnet für Extended Life Cycle Support einen Aufpreis auf das bestehende Abonnement. Der genaue Multiplikator variiert je nach Vertragsgröße und Verhandlungsstand, liegt aber typischerweise bei 1,5x bis 2x des normalen Wartungspreises pro Jahr.
Für Organisationen mit mehreren Dutzend JBoss-Instanzen summiert sich das. Gleichzeitig zahlen sie für einen Service, der den Scope gegenüber dem Vollsupport deutlich reduziert. Das ist keine Situation, die man ohne Plan durchsitzen sollte.
Hinzu kommen indirekte Kosten: Jede CVE, die nicht automatisch gepatcht wird, erfordert internen Assessment-Aufwand. Wenn Mitigationen manuell implementiert werden müssen, steigt der Betriebsaufwand. Wenn Auditoren Findings dokumentieren, entstehen Remediationskosten.
Was das für Compliance-Anforderungen bedeutet
KRITIS-Betreiber, NIS2-pflichtige Organisationen und ISO-27001-zertifizierte Unternehmen haben gemeinsam, dass sie “state of the art” Sicherheitsmaßnahmen nachweisen müssen. Ein Middleware-Stack im Extended Life Cycle ist kein automatischer Compliance-Verstoß - aber er ist begründungspflichtig.
Konkret: Wenn ein Auditor fragt, warum JBoss EAP 7 im Einsatz ist, reicht “es läuft stabil” nicht als Antwort. Gefragt wird nach dem Patch-Status, nach offenen CVEs, nach dem Plan für unser End-of-Life-Datum.
Wer keine strukturierte Antwort auf diese Fragen hat, riskiert Findings, die weit teurer sind als die Migration selbst. Mehr dazu im Artikel JBoss EAP 7: “Es läuft ja noch” - die gefährliche Fehleinschätzung.
Die richtige Reaktion auf den ELS-Status
Der ELS ist kein Panikmoment, aber er ist ein klarer Planungsauftrag. Die sinnvolle Reaktion:
- Inventory: Wie viele EAP-7-Instanzen laufen, auf welchen Systemen, mit welchen Applikationen?
- Dependency-Mapping: Welche Java-Version, welche Libraries, welche proprietären Subsysteme sind im Einsatz?
- Risikoklassifizierung: Welche Instanzen sind kritisch (Produktion, Außenschnittstellen, regulierte Daten)?
- CVE-Monitoring einrichten: Aktive Überwachung der Red Hat Security Advisories für EAP 7.
- Migrationsplanung starten: Nicht als theoretisches Projekt, sondern mit Ressourcenzuweisung.
Wer diese fünf Schritte noch nicht gegangen ist, sitzt auf Risiko - und zahlt trotzdem für Support.
Wie realistisch eine Migration bei Teams ist, die bereits im Tagesgeschäft ausgelastet sind, beschreibt der Artikel Migration wenn das Team am Limit ist.
Die konkreten Ausstiegsoptionen - Migration zu EAP 8, Containerisierung, oder alternativer Stack - sind im Artikel Die drei Ausstiegswege aus JBoss EAP 7 beschrieben.
FAQ
Ab wann gibt es keine Patches mehr für JBoss EAP 7?
Im Extended Life Cycle Support (seit Juni 2025) gibt es nur noch Patches für kritische CVEs nach Red Hats eigenem Zeitplan. Ab November 2027 endet jegliche Patch-Versorgung vollständig.
Was kostet der Extended Life Cycle Support?
Red Hat berechnet für ELS typischerweise das 1,5- bis 2-fache des normalen Abonnementpreises pro Jahr. Genaue Zahlen hängen vom Vertrag ab - aber der Scope ist gegenüber dem Vollsupport deutlich reduziert.
Ist JBoss EAP 7 im ELS noch compliant-fähig?
Grundsätzlich ja, aber mit steigendem Begründungsaufwand. Audits fragen nach offenen CVEs, Patch-Status und EOL-Planung. Ohne strukturierte Antworten entstehen Findings - unabhängig davon, ob die Software selbst stabil läuft.
Was ändert sich technisch von EAP 7 auf EAP 8?
EAP 8 basiert auf Jakarta EE 10 statt Java EE 8. Das bedeutet geänderte Namespace-Pakete (jakarta.* statt javax.*), neue Konfigurationsformate und keine Unterstützung mehr für mehrere veraltete Subsysteme. Es ist kein Drop-in-Upgrade.
Bis wann muss eine Migration abgeschlossen sein?
Spätestens vor Oktober 2027. Enterprise-Middleware-Migrationen brauchen erfahrungsgemäß 12 bis 18 Monate. Wer heute noch nicht begonnen hat zu planen, hat wenig Puffer.
Eine strukturierte Migration oder Härtung lässt sich mit dem richtigen Vorgehen auch bei begrenzter interner Kapazität umsetzen. Die SPAS Overview von Lennlay zeigt, wie das in der Praxis aussieht.