Well-Architected Review

Aktuelle Trends, Insights und praxisnahe Tipps

Fundiertes Fachwissen aus der Praxis für Sie zusammengefasst

Strategische Leitfäden und Insights aus der Praxis

Kerberos Authentifizierung Änderungen 2026

2026 verschärft Microsoft die Standards für Kerberos in Active Directory: Die veraltete RC4-Verschlüsselung wird schrittweise deaktiviert. Ziel ist es, bekannte Risiken zu reduzieren und die Sicherheitslücke CVE-2026-20833 zu adressieren. Mit den Sicherheitsupdates des ersten Halbjahres im Jahr 2026 wird das Standardverhalten am Key Distribution Center (KDC) phasenweise angepasst. Ohne saubere Vorbereitung kann das zu Authentifizierungsfehlern und Zugriffsproblemen führen.

Der Artikel gibt Ihnen einen kompakten Überblick und zeigt, wie Sie Ihr Unternehmen rechtzeitig dafür prüfen und vorbereiten können.

Was wird sich bei Kerberos ändern?

Um die Änderung einordnen zu können, lohnt sich ein Blick ins Jahr 2022: Damals hat Microsoft ein grundlegendes Standardverhalten definiert. Microsoft steuert die zulässigen Kerberos-Verschlüsselungsalgorithmen über zwei Registry-Einträge: Der eine steuert das domänenweite Standardverhalten (DefaultDomainSupportedEncTypes) und der andere (msds-SupportedEncryptionTypes) steuert das Verhalten dezidiert für Computer und Serverdienste. Mit den Updates aus 2022 und 2026 ändert sich jeweils der implizite Standardwert von DefaultDomainSupportedEncTypes. Wenn man einen anderen Wert möchte, muss man ihn explizit setzen. Der KDC orientiert sich immer dann an DefaultDomainSupportedEncTypes, wenn msds-SupportedEncryptionTypes entweder nicht gesetzt oder 0 entspricht. Beide Werte bestimmen den genutzten Verschlüsselungsalgorithmus für die Kerberos Anmeldung. Das Key Distribution Center ist die Steuerzentrale für das Active Directory und übernimmt die Rolle eines Türstehers, der den Einlass kontrolliert.

Vereinfacht gesagt: vor 2022 akzeptierte der KDC entweder RC4 oder AES – je nachdem, was angefragt wurde. Seit 2022 gilt implizit ein Default von 0x27. Ab 2026 wird der Standardwert auf 0x18 gesetzt.

Wert	Übersetzung	Bewertung
0x18	AES-128, AES-256	✅
0x27	DES, RC4, AES-256-SK	❌
0x1C	RC4, AES-128, AES-256	⚠️
0x1F	DES, RC4, AES-128, AES-256	❌

Supported encryption type

Wird der Standard auf 0x18 gesetzt, können ältere Systeme oder alte Konfiguration scheitern, wenn Sie auf RC4 angewiesen sind. Der KDC erlaubt nur Algorithmen, die effektiv erlaubt sind.

Betriebssystem	DES_CBC_CRC	DES_CBC_MD5	RC4_HMAC_MD5	AES128_HMAC_SHA1	AES256_HMAC_SHA1
Windows 2003, Windows XP und älter	Supported	Supported	Supported	No support	No support
Windows Vista	Supported	Supported	Supported	Supported	Supported
Windows 2008	Supported	Supported	Supported	Supported	Supported
Windows 2008R2	Deactivated	Deactivated	Supported	Supported	Supported
Windows 7	Deactivated	Deactivated	Supported	Supported	Supported
Windows 2012	Deactivated	Deactivated	Supported	Supported	Supported
Windows 2012R2	Deactivated	Deactivated	Supported	Supported	Supported
Windows 10	Deactivated	Deactivated	Supported	Supported	Supported
Windows 2016	Deactivated	Deactivated	Supported	Supported	Supported
Windows 2022	Deactivated	Deactivated	Supported	Supported	Supported
Windows 11	Deactivated	Deactivated	Supported	Supported	Supported
Windows 2025	No support	No support	Deactivated	Supported	Supported

Supported Windows versions

Die automatische Umsetzung wird über den im Januar 2026 eingeführten Wert RC4DefaultDisablementPhase gesteuert. Je nachdem, wie dieser eingestellt ist, werden RC4 Versuche zugelassen, blockiert oder protokolliert.
Bei aktiviertem RC4DefaultDisablementPhase wird AES zum Standard und setzt damit DefaultDomainSupportedEncTypes implizit auf den Wert 0x18. Bei einem aktivierten Audit Wert werden Meldungen generiert, die die fehlende Unterstützung kenntlich machen.
Eine vorzeitige Überprüfung Ihrer Umgebung ist daher dringendst zu empfehlen. Nach Abschluss der Umstellung wird RC4 für Kerberos in einer Active Directory Umgebung deaktiviert und daher erstmal nicht mehr nutzbar sein.

Microsoft unterteilt die Umstellung in drei Phasen:

Visualisierung der drei Update Phasen für Kerberos Änderung

Phase 1 (Audit Phase)

Die erste Phase ist die Audit Phase. In dieser Phase werden zusätzliche Telemetriedaten und Events eingeführt, um Probleme zu identifizieren, bevor die Durchsetzung greift. Ziel ist es, die RC4-Abhängigkeiten sichtbar zu machen und erforderliche Anpassungen rechtzeitig umzusetzen. Optional kann die Deaktivierung von RC4 bereits in dieser Phase manuell vorgezogen werden. Eine vorzeitige Deaktivierung sollte dennoch unbedingt vorab geprüft werden, da sie ansonsten zu Authentifizierungsabbrüchen und damit zu Dienstunterbrechungen führen kann. Für die Auswertung der Events bietet sich eine zentrale Stelle zur Protokollanalyse an (bspw. über Windows Eventlog Forwarding oder SIEM). Die Event ID’s 201-209, 4768-4769 sind zu prüfen.

Phase 2 (Enforcement with manual rollback)

In der zweiten Phase wird der Standard von RC4 auf AES automatisch gesetzt. Diese Umstellung kann noch rückgängig gemacht werden. Diese Phase ist die letzte Phase, in der Administratoren noch die Flexibilität haben, RC4DefaultDisablementPhase zurückzudrehen. Bevor es zur dritten Phase geht, sollte sichergestellt werden, dass kein Gerät mehr auf RC4 angewiesen ist, da ansonsten die Authentifizierung fehlschlägt.

Phase 3 (Enforcement)

Die dritte Phase ist die letzte Phase. In dieser Phase gibt es kein einfaches Entrinnen mehr. Die Durchsetzung greift ein und deaktiviert RC4. Eine Reaktivierung über RC4DefaultDisablementPhase ist dann nicht mehr möglich. Wenn Sie diese Phase überstanden haben und Ihre Serverdienste weiterhin laufen, haben Sie gute Arbeit geleistet.

Hintergrund: Kerberos AES und RC4

Beides sind weitverbreitete Verschlüsselungsalgorithmen. RC4 war lange Bestandteil von vielen Softwares, da es im Vergleich zu AES effizienter und eine größere Abwärtskompatibilität gewährleistet.

Der Rivest Cipher 4 (RC4) Verschlüsselungsalgorithmus ist kryptografisch unsicher und kann durch sogenannte „Roasting Attacken“ wie dem Kerberoasting ausgenutzt werden. Hierbei fordert ein Angreifer ein Kerberos Ticket an und „brute forced“ offline das Passwort des Authentifizierungstickets. Gelingt es, das Passwort zu knacken, sind u.a. weitergehende Ticket-Manipulation wie dem Silver Ticket möglich, um sich Zugriff auf Dienste zu verschaffen.

Muss ich bei Kerberos handeln?

Sie müssen handeln, wenn Sie eine Active Directory oder Hybrid-Umgebung nutzen. Sobald sich ein Legacy Gerät im Netzwerk befindet und das Update eingespielt wird, schlägt die Kerberos Authentifizierung fehl und es kommt zu einem Fallback zu NTLM. Bei NTLM gibt es ganz andere Angriffsvektoren, die zu beheben sind. Wenn Sie NTLM bereits erfolgreich unterbunden haben, schlägt die Anmeldung grundlegend fehl. Ggf. müssen Sie regulatorische Anforderungen (wie NIS2, DORA, ISO/IEC 27001 etc.) nachkommen und wollen daher beim Audit glänzen. Das können Sie nur, wenn Sie RC4 deaktivieren und AES die Bühne geben.

Was sollte ich jetzt machen?

Um obiges kurz und knapp zusammenzufassen, hier eine Handlungsempfehlung zu der bevorstehenden technischen Umstellung seitens Microsofts. Es ist wichtig, dass Sie sich unbedingt vorab ein Bild Ihrer Umgebung machen. Die Umstellung findet automatisch statt und kann im schlimmsten Fall den Zugriff auf Serverdienste einschränken.

Prüfen, ob Domain Function Level auf mind. Windows Server 2008 ist. Wenn drunter → unbedingt handeln.
Prüfen, ob Legacy Systeme benutzt werden. Unter Legacy Systemen zählen Windows Server 2003 / Windows XP und älter → unbedingt handeln.
Prüfen, ob Service Accounts (normale User & gMSA) genutzt werden → normale User durch gMSA ersetzen. RC4 bei gMSA ausschalten.
Jeder Domain Controller ist auf dem gleichen Windows Update Stand von Januar 2026.
Auf den Domain Controller sind die Events ID 201-209 im SYSTEM LOG zu prüfen.

Bei Fragen oder Anregen zum Thema Active Directory oder Kerberos Authentfizierung stehen wir Ihnen gerne beratend zur Seite. Wir freuen uns auf Ihre Kontaktaufnahme.

Was die Abkündigung von SAP Build Apps für Sie bedeutet

SAP hat angekündigt, SAP Build Apps als eigenständiges Standalone‑Produkt zum 30. September 2026 einzustellen.

Für viele Unternehmen ist das mehr als eine übliche Produktabkündigung. Bestehende Anwendungen lassen sich nicht einfach „umstellen“. Sie müssen neu gedacht und in vielen Fällen manuell neu aufgebaut werden.

Genau deshalb ist eine Build Apps Migration kein reines Technikprojekt. Sie ist eine geplante Transition, die mehrere Ebenen betrifft: das Applikationsportfolio, die Architektur, den Betrieb und nicht zuletzt die benötigten Skills.

Dieser Artikel ordnet die Entscheidung der SAP ein, beschreibt die wichtigsten technischen Konsequenzen und zeigt realistische Handlungsoptionen auf. Dazu zählen der Wechsel in das neue SAP Build Angebot, ein Neubau mit SAPUI5 und CAP sowie der Einsatz von Drittanbieter‑Plattformen.
Die Zielgruppe sind IT‑Leitungen, Enterprise‑ und Solution‑Architekt:innen, Product Owner sowie Verantwortliche für SAP BTP, die bestehende Build‑Apps‑Anwendungen absichern und eine tragfähige Nachfolgestrategie entwickeln müssen.

Was genau wird eingestellt und warum ist der Bruch so groß?

Um die Tragweite der Abkündigung zu verstehen, hilft ein kurzer Blick in die Vergangenheit: SAP übernahm AppGyver im Februar 2021 und integrierte die No‑Code‑/Low‑Code‑Plattform später als SAP Build Apps in die SAP BTP. Der Ansatz passt zur propagierten Clean‑Core‑Strategie, da so Erweiterungen außerhalb des S/4HANA‑Kerns ermöglicht wurden.

Bereits zuvor gab es erste Einschnitte. Die AppGyver Community Edition verlor ihren Support zum 30. September 2024. Im April 2025 folgte schließlich der Launch des Unified SAP Build Ansatzes. Apps, Prozesse und Work‑Zone‑Themen wurden stärker zusammengeführt und in eine gemeinsame Lobby integriert.

Die Abkündigung der Standalone‑Variante ist eine Weiterführung dieser Konsolidierung. SAP möchte die Werkzeuge für Anwendungen, Prozessautomatisierung und Portale in einem integrierten Angebot bündeln.
Auf dem Papier wirkt das vereinfachend. Für Bestandskunden bedeutet es jedoch einen harten Schnitt. Das frühere Standalone Build Apps basiert technologisch auf anderen Grundlagen als das neue Unified‑Umfeld.

Technische Realität

Frontend: Manuelle Rekonstruktion

Die wichtigste technische Aussage lässt sich klar zusammenfassen: Für Frontend‑Projekte existiert kein automatisierter Migrationspfad.

Konkret bedeutet das, dass Seiten, Datenbindungen, Logikflüsse, Navigationen und individuelle Komponenten in der Zielumgebung manuell neu aufgebaut werden müssen.

Was viele Teams an Build Apps überzeugt hat – die visuelle Modellierung von Logikflüssen – wird in der Transition zur größten Herausforderung. Es gibt kein Werkzeug, das visuelle Logikdiagramme automatisiert in die neue Architektur überführt. Der Grund hierfür liegt in den unterschiedlichen Grundlagen der Systeme. Während das ursprüngliche Build Apps unter anderem auf steroids.js und AngularJS basierte, orientiert sich das neue Unified‑Angebot an SAP‑Standards wie SAPUI5 und dem Cloud Application Programming Model (CAP).

Das bedeutet nicht, dass ein Migrationspfad grundsätzlich unmöglich gewesen wäre. SAP hat sich jedoch bewusst dagegen entschieden, auch für Standardszenarien einen solchen bereitzustellen.

In der Praxis müssen bestehende Anwendungen daher zunächst sauber dokumentiert und anschließend neu implementiert werden. Betroffen sind unter anderem Variablenbindungen, Formeln, Event‑Handler, Navigationslogik sowie Custom‑JavaScript‑Komponenten.

Backend: Datenrettung

Für Backend‑Projekte beschreibt SAP zumindest einen rudimentären Weg, Daten zu übernehmen. Dieser Ansatz ist jedoch eher eine manuelle Datenrettung als eine Migration im klassischen Sinn.

Entitäten werden einzeln aus dem Datenbrowser als CSV‑Dateien exportiert. In der Zielumgebung – idealerweise in einem CAP‑Projekt – müssen passende Tabellen manuell angelegt werden. Anschließend erfolgt der Import der CSVs.

Nicht automatisch übernommen werden dabei Beziehungen zwischen Entitäten, Metadaten, Berechtigungsstrukturen und weitere implizite Regeln. Genau diese Aspekte sind in produktiven Anwendungen häufig kritisch. Zusätzlich entsteht ein Integrationsrisiko: Wenn bestehende Frontends Services konsumieren, sollten neue CAP‑Services möglichst kompatible API‑Signaturen bereitstellen, um den Anpassungsaufwand im Frontend zu begrenzen.

Vier realistische Optionen nach der Abkündigung von SAP BUILD Apps

Wenn Sie SAP Build Apps produktiv einsetzen, sollten Sie die Situation nicht als „ein Projekt“ betrachten, sondern als Portfolio‑Entscheidung.

Nicht jede Anwendung benötigt denselben Zielpfad.
Ein strukturiertes Application‑Portfolio‑Management hilft, Prioritäten zu setzen. Typische Kriterien sind strategische Relevanz, technische Komplexität und Änderungsdynamik.

Option 1: Aussitzen bis Vertragsende

SAP garantiert den weiteren Betrieb bis zum Ende laufender Verträge. Das gilt unabhängig vom Lizenzmodell. SLAs und Wartungszusagen bleiben bestehen.

Diese Option ist jedoch mit Einschränkungen verbunden. Für die Standalone‑Version sind keine neuen Funktionen vorgesehen. Neue Sicherheitsstandards oder Innovationen wie die tiefere Integration von Joule fließen primär in das Unified Offering.
Zudem wird es zunehmend schwieriger, qualifizierte Fachkräfte für eine auslaufende Technologie zu finden.

Abwarten kann daher sinnvoll sein, wenn Anwendungen stabil sind oder ohnehin vor September 2026 abgelöst werden. Für alle anderen stellt es meist nur einen zeitlichen Aufschub dar.

Option 2: Wechsel zum neuen SAP Build

Der offizielle SAP‑Pfad ist der Umstieg auf das vereinheitlichte SAP Build Angebot.
Der Mehrwert liegt nicht in einer automatisierten Migration, sondern in einer konsolidierten Entwicklungsumgebung. Low‑Code, Pro‑Code und KI‑gestützte Funktionen sind zentral gebündelt.

Viele Unternehmen nutzen den Neubau gezielt, um technische Schulden abzubauen. Anwendungen werden auf einer moderneren Architektur neu aufgesetzt – mit klarer Trennung von Frontend, Services und Datenmodell.

Gleichzeitig sollte kritisch geprüft werden, ob und in welchem Umfang Investitionen in ein weiteres SAP‑Innovationsprodukt sinnvoll sind, dessen langfristige Stabilität sich erst bewähren muss.

Option 3: Pro-Code mit SAP CAP und SAPUI5

Für geschäftskritische Anwendungen ist der Einschnitt ein Anlass, wieder stärker auf Pro‑Code zu setzen.
CAP und SAPUI5 gelten als strategische SAP‑Standards. Sie bieten langfristige Wartbarkeit und reduzieren die Abhängigkeit von kurzfristigen Tool‑Entscheidungen.

CAP strukturiert die Service‑Entwicklung und etabliert bewährte Enterprise‑Patterns. UI5 – ergänzt durch Fiori Elements – kann die Entwicklung standardisierter Oberflächen beschleunigen.
Der höhere Schulungsaufwand ist real, rechnet sich aber häufig über den Lebenszyklus zentraler Anwendungen.

Option 4: Drittanbieter-Alternativen

Einige Unternehmen evaluieren bewusst Alternativen außerhalb des SAP‑Portfolios. Das ist insbesondere dann sinnvoll, wenn Fachbereiche stark eingebunden sind, Time‑to‑Market im Fokus steht oder mobile Szenarien besondere Anforderungen stellen.

Plattformen wie Simplifier, Neptune DXP oder Mendix adressieren unterschiedliche Schwerpunkte – von schneller Fiori‑Entwicklung über ABAP‑nahe Architekturen bis hin zu komplexen, systemübergreifenden Anwendungen.

Gleichzeitig erhöht ein Drittanbieter die Abhängigkeiten, beeinflusst Lizenzkosten und steigert die Komplexität der Landschaft. Dieser Weg sollte daher gut abgewogen sein.

Operatives Vorgehen: Das sollten Ihre nächsten Schritte sein

Die größte Gefahr in solchen Umbruchphasen ist Aktionismus: Einzelne Apps werden hektisch neu gebaut, während das Gesamtportfolio unklar bleibt. Besser ist ein klarer Ablauf, der technische und organisatorische Arbeitspakete verbindet.

Der erste Schritt ist eine vollständige Inventarisierung Ihrer SAP Build Apps Lösungen:

Welche Apps existieren?
Wer nutzt sie?
Welche Datenquellen hängen daran?
Welche SLAs gelten?
Wie hoch ist die Änderungsfrequenz?

Daraus entsteht eine Priorisierung nach strategischer Relevanz und technischer Komplexität. So vermeiden Sie, dass knappe Kapazitäten in Apps fließen, die ohnehin abgelöst werden.

Zum Schluss entscheidet die Umsetzungsgeschwindigkeit oft über Erfolg oder Stillstand. Deshalb ist es sinnvoll, frühzeitig Pilot‑Apps auszuwählen: eine einfache, eine mittelkomplexe und eine kritische App. Auf dieser Basis können Sie Standards für Architektur, Security, Naming, Transport/Deployment und Tests definieren und diese Standards danach konsequent für die restliche Build Apps Migration anwenden.

SAP setzt stark auf generative KI, um den Neubau zu beschleunigen. Joule soll in SAP Build Code und Build Apps helfen, Anforderungen schneller in umsetzbare Strukturen zu übersetzen. Der Trend geht damit von reinem Low‑Code stärker in Richtung „KI‑assistierter“ Entwicklung, bei der Menschen Ergebnisse prüfen, integrieren und absichern.

Wichtig ist hier aber die Erwartungshaltung: KI kann Zeit sparen, sie ersetzt aber nicht die Kernarbeit der Transition – also saubere Zielarchitektur, klare Verantwortlichkeiten, Sicherheitskonzept, Tests und Betriebsprozesse.

Was Sie aus der Abkündigung von SAP Build Apps ableiten sollten

Die Abkündigung von SAP Build Apps zeigt, wie schnell sich Cloud‑Produktstrategien ändern können und wie teuer fehlende Portabilität wird, wenn Anwendungen zu stark an ein proprietäres Werkzeug gebunden sind. Für die meisten Unternehmen ist daher der pragmatischste Weg eine Kombination: Unkritische, stabile Apps laufen bis Vertragsende aus; standardnahe Apps werden in das Unified SAP Build überführt; kritische und komplexe Anwendungen werden mit CAP/UI5 neu aufgesetzt und ausgewählte Spezialfälle können durch Drittanbieter sinnvoll adressiert werden.

Entscheidend ist, dass Sie die verbleibende Zeit bis September 2026 nutzen, um Ihre Erweiterungsarchitektur robuster zu machen: Logik stärker in standardisierte Services zu kapseln, Skills für hybride Teams aufzubauen und Governance so zu verankern, dass Geschwindigkeit nicht zu Lasten der Wartbarkeit geht. Genau damit wird eine Build Apps Migration zu einem kontrollierten Umbau statt zu einem ungeplanten Krisenprojekt.

Wenn Sie aktuell SAP Build Apps einsetzen, unterstützen wir Sie bei Rewion gerne dabei, den passenden Nachfolgepfad je Anwendung festzulegen und die Umsetzung planbar zu machen. Konkret können wir gemeinsam

Ihr Build‑Apps‑Portfolio inventarisieren und priorisieren,
eine Zielarchitektur inkl. Security und Betriebsmodell definieren,
Pilot‑Migrationen umsetzen und
daraus wiederverwendbare Standards für die Skalierung ableiten.

Wenn Sie sich zusätzlich für die strategischen Leitplanken interessieren, lohnt sich auch ein Blick in unsere verwandten Beiträge der Blogreihe, zum Beispiel zur Clean‑Core‑Strategie und zu Governance auf SAP BTP (z. B. Verantwortlichkeiten, RACI und Lifecycle‑Regeln).

Was wird sich bei Kerberos ändern?

Phase 1 (Audit Phase)

Phase 2 (Enforcement with manual rollback)

Phase 3 (Enforcement)

Hintergrund: Kerberos AES und RC4

Muss ich bei Kerberos handeln?

Was sollte ich jetzt machen?

Was genau wird eingestellt und warum ist der Bruch so groß?

Technische Realität

Frontend: Manuelle Rekonstruktion

Backend: Datenrettung

Vier realistische Optionen nach der Abkündigung von SAP BUILD Apps

Option 1: Aussitzen bis Vertragsende

Option 2: Wechsel zum neuen SAP Build

Option 3: Pro-Code mit SAP CAP und SAPUI5

Option 4: Drittanbieter-Alternativen

Operatives Vorgehen: Das sollten Ihre nächsten Schritte sein

Was Sie aus der Abkündigung von SAP Build Apps ableiten sollten

Well-Architected Review.

Bestehende Cloud-Workloads systematisch analysieren und optimieren

Unsere Leistung

Mehrwert

Ihre Herausforderung

Ergebnisse & Deliverables

Dauer & Investition

Unser Ansatz

Informationen

Sebastian Tappe

Anfragen

Deutschland

Schweiz

Technischer Support

Support-Hotline

Support E-Mail

Fernwartung via TeamViewer