IT-Beratung & IT-Services

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.

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.

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.

1. Prüfen, ob Domain Function Level auf mind. Windows Server 2008 ist. Wenn drunter → unbedingt handeln.
2. Prüfen, ob Legacy Systeme benutzt werden. Unter Legacy Systemen zählen Windows Server 2003 / Windows XP und älter → unbedingt handeln.
3. Prüfen, ob Service Accounts (normale User & gMSA) genutzt werden → normale User durch gMSA ersetzen. RC4 bei gMSA ausschalten.
4. Jeder Domain Controller ist auf dem gleichen Windows Update Stand von Januar 2026.
5. 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.

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.

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

Cloud-Umgebungen wachsen oft schneller als Teams sie manuell verwalten können. Zwar sind sie in kleinen Infrastrukturen noch überschaubar, können allerdings schnell zum Problem werden, sobald die Infrastruktur komplexer wird. Änderungen dauern zu lange, Fehler können sich einschleichen und Entwickler warten auf Ressourcen, um weiterarbeiten zu können. Um sowohl Entwicklern als auch dem Platform-Team die Arbeit zu erleichtern, können verschiedene Prozesse automatisiert werden. In diesem Artikel geben wir einen Überblick, wie Automatisierung im Cloud Platform Engineering aussehen kann und welche Vorteile sie Unternehmen bringt.

Warum manuelle Prozesse im Cloud Platform Engineering an ihre Grenzen stoßen

Ohne Automatisierung ist Cloud Platform Engineering komplex: Jede Entwicklungsumgebung muss manuell aufgesetzt werden. Dadurch können sich Releases verzögern, Umgebungen inkonsistent sein und eine aufwendige Koordination ist nötig. Auch das Fehlerpotenzial ist entsprechend höher: Je mehr manuelle Eingriffe ein Prozess erfordert, desto wahrscheinlicher wird ein Versehen und desto schwerer lässt sich das Problem im Nachhinein nachvollziehen.

In der Praxis bedeutet das: Tickets stapeln sich, Teams verschieben Deployments und das Platform-Team wird zum Flaschenhals, weniger zum Enabler. Gerade beim Aufsetzen der Umgebungen gibt es jedoch zahlreiche wiederkehrende und regelbasierte Aufgaben, die sich an Anforderungen und Compliance-Richtlinien des Unternehmens orientieren. Um das Platform-Team zu entlasten und verlässlich und schnell Umgebungen aufsetzen zu können, kann Automatisierung auf verschiedenen Wegen umgesetzt werden.

3 wichtige Säulen der Automatisierung im Cloud Platform Engineering

Im Cloud Platform Engineering gibt es nicht die eine Automatisierung oder das eine Automatisierungs-Tool. Vielmehr können Unternehmen in mehreren Bereichen Tools und Konzepte einsetzen, die sich gegenseitig ergänzen. Dabei kann es beispielsweise um die Bereitstellung der Infrastruktur gehen, die eigenständige Arbeit der Entwickler oder den permanenten Blick auf den Betrieb.

CI/CD-Pipelines für die Cloud-Infrastruktur

Bei CI/CD-Pipelines handelt es sich um einen automatisierten Prozess, der Änderungen am Code kontinuierlich integriert (Continuous Integration), testet und bereitstellt (Continuous Deployment). Das Prinzip dahinter, Infrastructure as Code, sorgt dafür, dass Umgebungen nicht mehr per Hand konfiguriert werden müssen. Stattdessen entstehen sie durch reproduzierbare, beschreibbare Vorlagen.

In einer automatisierten Pipeline durchläuft jede Änderung an der Infrastruktur mehrere Schritte, bevor sie in den Release geht: automatische Validierung, Sicherheitschecks und Testläufe. Fehler werden so früh erkannt und nicht erst dann, wenn sie bereits Auswirkungen haben. So entstehen konsistentere Umgebungen, weniger manuelle Eingriffe und deutlich kürzere Durchlaufzeiten bei Änderungen.

Die wichtigsten Vorteile auf einen Blick:

• Konsistenz:Jede Umgebung entsteht nach denselben Vorlagen, ohne Abweichungen oder manuelle Sonderwege.
• Früherkennung:Fehler und Sicherheitslücken werden automatisch vor dem Deployment erkannt.
• Geschwindigkeit:Änderungen an der Infrastruktur werden in Minuten ausgerollt statt in Stunden oder Tagen.

Self-Service-Portale für Entwickler

Gerade in wachsenden IT-Teams entsteht oft die gleiche Herausforderung: Entwickler müssen auf Ressourcen warten, weil jede Anfrage über das Platform-Team läuft. Mit Self-Service-Portalen können Unternehmen dieses Problem lösen, indem sie standardisierte Bausteine bereitstellen, die Entwickler eigenständig nutzen können. Dafür brauchen sie kein technisches Spezialwissen und sparen sich Wartezeiten.

Die Plattform dabei stellt sicher, dass alles, was über das Portal geschieht, den internen Standards für Sicherheit und Compliance entspricht. Entwickler arbeiten schneller und unabhängiger. Das Platform-Team wiederum gewinnt Zeit im Arbeitsalltag.

Die wichtigsten Vorteile auf einen Blick:

• Autonomie:Entwickler können Ressourcen eigenständig ohne Ticket und Wartezeit einrichten.
• Standardisierung:Alle bereitgestellten Umgebungen entsprechen automatisch den internen Sicherheits- und Compliance-Vorgaben.
• Entlastung:Das Platform-Team spart Zeit und kann sich auf andere Aufgaben konzentrieren.

Monitoring & Observability

Neben dem Rollout gibt es auch im laufenden Betrieb Möglichkeiten zur Automatisierung. Vom Monitoring bis zur automatischen Reaktion auf Probleme können Unternehmen verschiedene Automatisierungen umsetzen.

Wichtig ist vor allem der Unterschied zwischen klassischem Monitoring und moderner Observability: Monitoring zeigt auf, dass etwas nicht stimmt, Observability hingegen gibt Aufschluss darüber, warum etwas nicht stimmt. Durch automatisierte Alarme, strukturierte Protokolle und nachvollziehbare Metriken können Teams proaktiv handeln. Teilweise gibt es bereits Systeme, die bekannte Probleme selbstständig korrigieren können, ohne dass ein Mensch eingreifen muss.

Die wichtigsten Vorteile auf einen Blick:

• Proaktivität:Probleme werden erkannt und gemeldet, bevor sie den Betrieb beeinflussen.
• Nachvollziehbarkeit: Protokolle und Metriken machen Ursachen schnell sichtbar. Die stundenlange Fehlersuche entfällt.
• Resilienz:Bekannte Störungen können ohne manuellen Eingriff automatisch behoben werden.

Vorteile durch Automatisierung im Cloud Platform Engineering

Die Wirkung von Automatisierung im Cloud Platform Engineering zeigt sich auf verschiedenen Ebenen, von der Geschwindigkeit bis zur Kosteneffizienz.

• Geschwindigkeit:Sie ist der unmittelbarste Effekt. Prozesse, die früher Stunden oder Tage gedauert haben, laufen in Minuten ab. Entwicklungsteams können schneller liefern, weil sie weniger auf externe Freigaben angewiesen sind.
• Zuverlässigkeit:Automatisierte Abläufe führen dieselben Schritte in derselben Reihenfolge aus. Dabei gibt es keine Abweichungen und nichts kann vergessen werden. So sinkt die Fehlerquote deutlich.
• Skalierbarkeit:Eine gut automatisierte Plattform wächst mit den Anforderungen mit, ohne dass der Betriebsaufwand proportional steigt. Mehr Workloads bedeuten nicht automatisch mehr manuellen Aufwand.
• Kosteneffizienz:Einerseits sparen Entwickler und Platform-Teams Zeit und damit Geld, andererseits können Unternehmen durch automatisiertes Ressourcenmanagement ungenutzte Kapazitäten erkennen, Umgebungen bedarfsgerecht anpassen und verhindern, dass Cloud-Ressourcen unnötig laufen. Auch so sinken die laufenden Kosten für den Cloud-Betrieb.

Fazit: Cloud Platform Engineering Hand in Hand mit automatisierten Prozesse

Automatisierung ist ein wichtiger und grundlegender Bestandteil im Cloud Platform Engineering. Durchdachte Automatisierungsstrukturen schaffen die Voraussetzungen für schnellere Entwicklung, höhere Zuverlässigkeit und Cloud Plattformen, die mit den Anforderungen des Unternehmens wachsen können. Zwar lohnt es sich schon von Anfang an, Automatisierung in die Cloud Infrastruktur zu integrieren, aber auch nachträglich können Tools und Konzepte integriert werden. Dabei ist es am sinnvollsten, mit den Bereichen zu beginnen, die den größten Engpass verursachen und von dort aus strukturiert weiterzubauen. So entsteht mit der Zeit eine zuverlässige Automatisierungsstruktur.

Nachdem wir im im ersten Teil unserer Blogreihe das Extensibility-Modell grundlegend betrachtet haben, widmen wir uns nun der praktischen Anwendung bei der Erweiterung von SAP S/4HANA. Die fundamentale Systementscheidung für eine Architektur auf der SAP Business Technology Platform (BTP) gegenüber einem On-Stack-Ansatz definiert maßgeblich die Performance, Wartbarkeit und Skalierbarkeit künftiger Entwicklungen. Eine klare S/4HANA Erweiterungsstrategie hilft dabei, die Vorteile beider Welten effizient zu nutzen. Während direkte Erweiterungen im ERP-Kern einen tiefgreifenden Zugriff auf lokale Geschäftsprozesse bieten, eröffnet die Cloud neue Wege für die Integration von Drittsystemen und externen Nutzergruppen. Dieser Artikel bietet konkrete Entscheidungskriterien für technische Projektleiter, Enterprise-Architekten und leitende SAP-Entwickler.

On-Stack-Erweiterung mit Key User und Developer Extensibility

Die Entwicklung direkt im S/4HANA-System stellt die engste Form der Systemerweiterung dar. Sie unterteilt sich heute in zwei primäre Bereiche, wobei die Key User Extensibility vor allem Anwender mit tiefem Prozessverständnis anspricht. Diese können über integrierte Wizard-Tools benutzerdefinierte Felder, einfache Validierungen oder analytische Ansichten generieren, ohne tiefgehende Programmierkenntnisse zu besitzen. Mit dem Release S/4HANA 2025 FPS01 hat SAP diesen Bereich funktional deutlich aufgewertet. Es ist nun möglich, vollwertige Fiori-Elements-Anwendungen für benutzerdefinierte Geschäftsobjekte mit wenigen Klicks zu erstellen und die Verhaltenssteuerung für SAP-eigene Objekte nahtlos anzupassen.

Sobald die fachlichen Anforderungen komplexer werden, kommt die Developer Extensibility zum Einsatz. Sie stellt professionellen Entwicklern das moderne ABAP Cloud Modell zur Verfügung. Der entscheidende architektonische Vorteil dieses On-Stack-Ansatzes liegt in der physischen und logischen Nähe zu den Geschäftsdaten. Dadurch bleiben die transaktionale Integrität und hohe Ausführungsgeschwindigkeiten gewahrt, da keine externen Schnittstellenaufrufe notwendig sind.

Cloud-Flexibilität durch Side-by-Side Extensibility

Im Gegensatz dazu steht die Side-by-Side Extensibility auf der SAP BTP, bei der Applikationen vollständig außerhalb des ERP-Kerns entwickelt und betrieben werden. Die Kommunikation erfolgt ausschließlich über lose gekoppelte, freigegebene Remote-APIs oder asynchrone Ereignisse über den Event Mesh. Dieses Modell eignet sich besonders für Applikationen, die für externe Endnutzer wie Lieferanten oder Endkunden gedacht sind. Die BTP fungiert hierbei als sichere, isolierte Zone, die den internen ERP-Kern schützt. Zudem ist dieses Muster ideal für Partner, die eigenständige und mandantenfähige Software-as-a-Service Lösungen entwickeln möchten.

Bei der Wahl des Programmiermodells innerhalb der S/4HANA Erweiterungsstrategie stehen das SAP Cloud Application Programming Model (CAP) und das ABAP RESTful Application Programming Model (RAP) im Fokus. Während Entwicklungen über das RAP-Modell On-Stack meist keine zusätzlichen Lizenzkosten verursachen, erfordert die ABAP Environment auf der BTP eine eigene Subskription. Im Vergleich dazu bieten CAP-Anwendungen auf Cloud Foundry ein granulareres Preismodell, was je nach Projektumfang wirtschaftlicher sein kann.

Herausforderungen der S/4HANA Erweiterungsstrategie

Die Entscheidung zwischen On-Stack und Side-by-Side erfordert eine genaue Analyse der Datenströme, da eine Lösung auf der BTP nicht automatisch effizienter ist. Ein kritischer Faktor bleibt die physikalische Bindung von Daten an ihren Ursprungsort. Wenn Millionen von Datensätzen über OData-Schnittstellen übertragen werden, entstehen unweigerlich Performance-Engpässe, sofern der BTP-Subaccount und das S/4HANA-System nicht geografisch und infrastrukturell optimal aufeinander abgestimmt sind.

Neben den Latenzen stellt die sogenannte Principal Propagation eine administrative Hürde dar. Sie erfordert eine komplexe Konfiguration des SAP Cloud Connectors sowie den Import von Zertifikaten und regelbasierte Mappings im System. On-Stack-Erweiterungen punkten hier durch die native Nutzung lokaler Berechtigungskonzepte, was die Stabilität erhöht. Cloud-Szenarien verlangen hingegen eine exakte Synchronisation der Identitätsdaten zwischen dem lokalen System und dem Cloud-Identitätsanbieter.

Um Ihnen die Navigation durch diese komplexen Abwägungen zu erleichtern, bietet die folgende Infografik eine grobe Entscheidungsgrundlage, welche die wichtigsten Kriterien von der Datenlast bis hin zum Nutzerkreis visualisiert.

Hybride Lösungsansätze

Da keine der beiden Varianten isoliert alle modernen Anforderungen abdeckt, liegt die optimale Lösung für komplexe Szenarien häufig in einer hybriden Architektur. Hierbei werden datenintensive Kernprozesse performant On-Stack mittels ABAP Cloud abgewickelt, während kundenorientierte Frontends oder die Integration von Drittsystemen flexibel über die BTP realisiert werden. Die Wahl der Bereitstellungsform beeinflusst langfristig sowohl die Backend-Performance als auch die Flexibilität Ihrer Systemlandschaft. Im dritten Teil dieser Serie analysieren wir, wie sich diese Faktoren künftig auf Benutzeroberflächen und die Integration von künstlicher Intelligenz auswirken.

Gerne unterstützen wir Sie bei diesen komplexen Fragestellungen durch detaillierte Machbarkeitsstudien, um die perfekte Balance zwischen Cloud-Innovation und ERP-Stabilität für Ihr Unternehmen zu finden. Kontaktieren Sie uns für ein unverbindliches Beratungsgespräch oder lesen Sie unsere weiteren Blogartikel zu den Themen Clean Core und SAP BTP Integration.

Die Architektur von Unternehmenssoftware durchläuft einen fundamentalen Wandel. Historisch gewachsene ERP-Landschaften zeichnen sich durch tiefgreifende, monolithische Strukturen aus. Kundenindividueller Code greift häufig in Form von Modifikationen oder User Exits direkt und ungeschützt in den Kern des Systems ein. Diese über Jahrzehnte übliche Praxis führt heute zu erheblicher technischer Schuld, bremst die Agilität von Unternehmen, und macht Systemupgrades komplex und kostenintensiv. Um in einem dynamischen Marktumfeld wettbewerbsfähig zu bleiben, ist die Umsetzung einer Clean Core Strategie unerlässlich. Diese fordert eine strikte technologische Entkopplung von Standardsoftware und individuellen Anpassungen. Unser erster Beitrag dieser dreiteiligen Blogreihe richtet sich gezielt an Enterprise Architekten, leitende SAP-Entwickler und IT-Strategen, die eine performante, wartbare und zukunftssichere Systemlandschaft konzipieren möchten.

Clean Core Strategie im SAP Kontext

Der Begriff des „sauberen Kerns“ wird in der globalen Entwicklergemeinschaft intensiv diskutiert und oft missverstanden. Kundenindividueller Code muss nicht vollständig vermieden werden. „Clean Core“ bedeutet Erweiterung technologisch so zu entkoppeln und zu standardisieren, dass der eigentliche SAP-Standard unangetastet bleibt. Dadurch lassen sich künftige Releases ohne manuellen Anpassungsaufwand einspielen. Das Ziel ist es, Upgrades reibungslos zu gestalten, Altlasten abzubauen und neue Technologien wie Künstliche Intelligenz nahtlos zu integrieren. Für einen dauerhaft effizienten Betrieb stützt sich dieses Architekturkonzept auf fünf Kernprinzipien: durchgängige Prozesse, nahtlose Integration, verlässliche Datenqualität, effiziente Operations und eine standardisierte Erweiterbarkeit.

Im Bereich der Erweiterbarkeit hat die SAP ihre Vorgaben zuletzt stark an die Realität historisch gewachsener Systeme angepasst. Ursprünglich wurde der Entwickler-Community ein striktes Drei-Tier-Modell vorgegeben. Dieses unterschied zwischen Cloud-konformen Erweiterungen (Tier 1), Brückenlösungen (Tier 2) und klassischen, modifizierenden Anpassungen (Tier 3). Dieses binäre System aus „erlaubt“ und „verboten“ erwies sich jedoch in der Migrationspraxis als viel zu restriktiv. Als Lösung führt die SAP ein differenziertes Modell mit vier Leveln ein, das die Kompatibilität von Erweiterungen wesentlich granularer bewertet und einen realistischeren Transformationspfad aufzeigt.

Das Clean Core A-D Extensibility Modell

Das sogenannte A-D Extensibility Modell klassifiziert den individuellen Code anhand seiner technischen Umsetzung und der genutzten Schnittstellen in folgende vier Kategorien beziehungsweise Stufen:

• Level A (ABAP Cloud Readiness): Die sauberste Form der Erweiterung nutzt exklusiv offiziell freigegebene SAP-APIs sowie das ABAP Cloud Entwicklungsmodell. Diese Stufe garantiert höchste Upgrade-Stabilität ohne manuellen Anpassungsaufwand und ist vollständig Cloud-ready.

• Level B (Classic SAP APIs): Auf dieser Ebene nutzt der Code klassische, gut dokumentierte SAP-APIs wie BAPIs oder freigegebene BADIs und folgt den etablierten Best Practices für die klassische ABAP-Entwicklung. Diese Stufe bietet eine sehr hohe Stabilität, erfordert bei Upgrades in der Regel nur marginale funktionale Prüfungen und gilt im Rahmen von Private Cloud Deployments oder On-Premise-Szenarien als valide und zukunftssichere Basis.

• Level C (Unreleased SAP Objects): Diese Stufe umfasst die Nutzung interner SAP-Objekte, die nicht offiziell für Kunden freigegeben wurden. Die Stabilität ist hier nur bedingt gegeben, da vor jedem Upgrade eine zwingende technische Verifizierung der genutzten Objekte über das Changelog erforderlich ist.

• Level D (Modifications & Technical Debt): Diese kritische Stufe umfasst die Nutzung explizit nicht empfohlener Objekte, direkte Kernmodifikationen des SAP-Standards oder veraltete, invasive Techniken wie implizite Enhancements. Code auf diesem Level erzeugt massive technische Schulden, verhindert reibungslose Upgrades und muss im Rahmen der Transformation zwingend in höhere Level refaktoriert werden.

Die rein theoretische Definition dieser vier Level reicht für eine erfolgreiche und nachhaltige Architektur-Transformation jedoch bei Weitem nicht aus. Es bedarf einer strengen Governance, um sicherzustellen, dass Entwicklungsteams diese Leitplanken im Arbeitsalltag konsequent einhalten. Die technische Einhaltung dieser strikten Vorgaben wird durch das ABAP Test Cockpit (ATC) unterstützt, welches den Code automatisiert auf seine ABAP Cloud Readiness prüft und detaillierte Fehler oder Warnungen ausgibt, sobald ein Entwickler den im System definierten Clean Core Standard verlässt. Um Entwicklern den Übergang zu erleichtern, stellt die SAP den SAP Extensibility Explorer sowie das Cloudification Repository zur Verfügung. So können Sie bereits in der Designphase freigegebene Schnittstellen identifizieren und neue Erweiterungen direkt konform zu Level A entwickeln.

Herausforderungen in der Umsetzung

Trotz dieser klaren strategischen Ausrichtung gibt es in der realen Projektpraxis weiterhin erhebliche Herausforderungen. Die Deutschsprachige SAP-Anwendergruppe (DSAG) hat diese kritische Situation bereits auf den Technologietagen 2025 unter dem Motto „Strategy Royale: Call, Raise or Fold?“ intensiv diskutiert. Die mit Abstand größte technische Hürde bei der Umsetzung der Clean Core Paradigmen ist derzeit die mangelnde Verfügbarkeit von Level-A-kompatiblen, freigegebenen Schnittstellen.

Wie sich diese theoretischen Vorgaben in der Praxis umsetzen lassen und welche Kriterien die architektonische Entscheidung zwischen On-Stack-Erweiterungen und Side-by-Side-Bereitstellungen beeinflussen, beleuchten wir im zweiten Teil dieser Blogreihe.

Gehen Sie den nächsten Schritt

Eine fundierte Entscheidung bildet hier das Rückgrat Ihrer digitalen Transformation. Unser Expertenteam begleitet Sie gerne bei der strategischen Neuausrichtung Ihrer Systemlandschaft. Wir führen tiefgreifende Code-Analysen Ihres S/4HANA-Systems mittels ATC durch und erarbeiten einen belastbaren Refactoring-Plan, um Ihre historischen Modifikationen sicher in die Level A und B zu überführen. Nehmen Sie Kontakt mit uns auf, um Ihre individuelle Roadmap für einen Clean Core zu definieren.

Mobile Endgeräte sind fester Bestandteil im Arbeitsalltag zahlreicher Unternehmen geworden. Smartphones, Tablets und Laptops ermöglichen flexibles Arbeiten – ob im Büro, im Homeoffice oder unterwegs. Je mehr Geräte allerdings im Umlauf sind, desto komplexer wird ihre Verwaltung. Mobile Device Management bietet Unternehmen die technische Grundlage, um alle Geräte zentral zu steuern, abzusichern und zu überwachen. Die rein technische Umsetzung reicht jedoch noch nicht aus. Auch alle Mitarbeitenden müssen wissen, wie sie mit ihren Geräten umgehen sollen und welche Richtlinien warum gelten. Deshalb lohnen sich MDM-Schulungen für alle Mitarbeitenden im Zuge der Einführung des Mobile Device Managements. Warum diese Schulungen wichtig sind, welche Inhalte sie vermitteln sollten und welche Formate sich eignen, erklären wir in diesem Artikel.

Warum MDM-Schulungen wichtig für Unternehmen sind

Zahlreiche Sicherheitsvorfälle entstehen durch menschliche Fehler, weniger durch technische Schwachstellen. Mitarbeitende, die nicht wissen, welche Apps sie auf ihrem Dienstgerät installieren dürfen oder wie sie mit Unternehmensdaten auf privaten Geräten umgehen sollen, machen eines der größten Risiken für die IT im Unternehmen aus. Mit MDM-Lösungen können entsprechende Sicherheitsrichtlinien umgesetzt werden, erfordern allerdings Verständnis und Akzeptanz der User, das durch Schulungen entsteht. Andernfalls entstehen verschiedene Risiken:

• Mitarbeitende umgehen bewusst oder unbewusst Sicherheitsrichtlinien, etwa indem sie Gerätesperren deaktivieren.
• Nicht freigegebene Apps werden installiert, die Risiken für Malware bieten.
• Sie wissen nicht, wie sie sich bei Verlust oder Diebstahl eines Geräts verhalten sollten.
• Der Umgang mit BYOD-Geräten und der Trennung privater und beruflicher Daten ist unklar.

An dieser Stelle sind auch Anforderungen der DSGVO und der NIS2-Richtlinie relevant. Beide fordern, dass Unternehmen neben technischen Maßnahmen für die IT-Sicherheit auch organisatorische Maßnahmen etablieren. Dazu zählen auch Mitarbeiterschulungen, die das Team über richtige Verhaltensweisen und Schutzmaßnahmen aufklären.

Diese Inhalte können Teil einer effektiven MDM-Schulung sein

Eine gute MDM-Schulung geht einerseits auf technisches Grundwissen ein und schafft andererseits ein Verständnis für den Sinn hinter verwalteten Geräten und Sicherheitsmaßnahmen. Verstehen alle Teams, warum Regeln gelten, steigt die Akzeptanz und Mitarbeitende halten sich daran. Wichtig ist dabei auch: Passen Sie die Inhalte auf die jeweilige Zielgruppe an. Für IT-Administratoren sind andere Grundlagen und Themen wichtig als für Mitarbeitende im Vertrieb oder Kundenservice.

Für alle Mitarbeitenden eignen sich diese Inhalte:

• Was ist MDM und welche Geräte sind im Unternehmen davon betroffen?
• Welche Unternehmensrichtlinien gelten für mobile Endgeräte?
• Wie funktioniert die Einbindung eines Geräts in das MDM-System?
• Was ist im Fall eines Geräteverlusts zu tun und was bedeutet ein Remote Wipe?
• Wie werden private und berufliche Daten auf BYOD-Geräten sauber getrennt?

Für IT-Verantwortliche und Administratoren kommen weitere Themen hinzu, etwa die Konfiguration von Geräteprofilen, das Management von App-Berechtigungen oder die Auswertung von Compliance-Reports. Durch eine klare Unterscheidung dieser Zielgruppen stellen Sie sicher, dass die Schulungen effizient sind und die Informationen wirklich relevant sind.

Wie können Unternehmen MDM-Schulungen erfolgreich umsetzen?

Natürlich ist es wichtig, was Teams im Zuge der MDM-Schulungen lernen. Zentrale Frage ist aber auch, wie sie die nötigen Infos vermittelt bekommen. Dafür können Unternehmen verschiedene Wege wählen:

• Ein Präsenztraining eignet sich optimal für komplexere Themen und den direkten Austausch, vor allem bei der Implementierung von MDM im Unternehmen.
• E-Learning-Module sind flexibel und lassen sich gut dokumentieren, eignen sich also besonders gut für verteilte Teams, die hauptsächlich remote arbeiten.
• Micro-Learning umfasst kurze Einheiten von wenigen Minuten zu einem konkreten Thema und kann gut für regelmäßige Auffrischungen eingesetzt werden.
• Im Onboarding neuer Mitarbeitender können direkt die nötigen MDM-Grundlagen eingebunden werden, damit sie Geräte von Anfang an richtig nutzen können.

Den Erfolg der MDM-Schulungen können Sie beispielsweise durch kleine Wissenstests nach einzelnen Einheiten überprüfen. Holen Sie sich außerdem Feedback ein, ob an den Schulungen etwas verbessert werden kann, um für zukünftige Einheiten zu lernen.

Wichtig ist auch: MDM-Lösungen entwickeln sich ständig weiter. Deshalb reicht eine einmalige Schulung meist nicht aus. Neue Gerätetypen, aktualisierte Unternehmensrichtlinien oder neue gesetzliche Vorgaben erfordern regelmäßige Updates. Sinnvoll ist es daher, MDM-Schulungsinhalte jährlich aufzufrischen und zusätzliche Schulungen einzuplanen, wenn es größere Änderungen gibt.

Fazit: Schulungen machen MDM zum Erfolg

Oft werden MDM-Schulungen als notwendige Compliance-Maßnahme angesehen. Dabei sorgen sie dafür, dass alle Teams die Regeln und Vorgaben rund um die Geräteverwaltung verstehen und akzeptieren und reduzieren somit die Sicherheitsrisiken für die IT des gesamten Unternehmens. Je besser Mitarbeitende nämlich verstehen, warum Regeln gelten, desto weniger fühlen sie sich kontrolliert und desto eher halten sie sich an sie. Unternehmen schaffen so die Grundlage für sichere Remote-Arbeit.

Ein Termin wird kurzfristig abgesagt.
Familiärer Krankheitsfall.
Keine Vertretung.

Alles hängt an einer Person.

Was im Alltag nachvollziehbar ist, wird in der IT zum Risiko:
– Ein Single Point of Failure

Die entscheidende Frage lautet:

Wie viele solcher Abhängigkeiten gibt es in Ihrem Unternehmen, ohne dass Sie es wissen?

Die Realität in vielen Unternehmen

• Kritisches Wissen liegt bei einzelnen Personen

• Systeme sind nicht einheitlich abgesichert

• Prozesse sind nicht ausreichend dokumentiert

• Vertretungsregelungen existieren nur auf dem Papier

Solange alles läuft, bleibt das unsichtbar.
Doch im Ernstfall führt genau das zu:

• Ausfällen
• Sicherheitsvorfällen
• Compliance-Risiken

Warum jetzt Handlungsdruck besteht

Mit NIS2, ISO 27001 und neuen regulatorischen Anforderungen verändert sich IT-Sicherheit grundlegend:

Weg von Einzelmaßnahmen
Hin zu nachweisbarer Resilienz

Unternehmen müssen heute zeigen können:

• Welche Risiken bestehen

• Welche Maßnahmen umgesetzt wurden

• Wie Systeme abgesichert sind

• Wie Ausfälle abgefangen werden

„Wir haben das im Griff“ reicht nicht mehr.

Die Lösung: Struktur statt Zufall

Moderne IT-Sicherheit basiert auf zwei Säulen:

 Technische Absicherung

• System Hardening (IT-Härtung)

• Sichere Konfigurationen

• Zugriffskontrollen

• Monitoring & Logging

 Organisatorische Sicherheit

• Klare Verantwortlichkeiten

• Dokumentierte Prozesse

• Vertretungsregelungen

• Notfall- und Wiederanlaufpläne

Erst die Kombination macht Ihr Unternehmen wirklich widerstandsfähig.

Vorgehen nach ISO 27001 & NIS2 – einfach erklärt

Wir setzen genau dort an, wo die größten Risiken entstehen:

1. Transparenz schaffen

• Analyse Ihrer Systeme, Prozesse und Abhängigkeiten

• Identifikation von Schwachstellen (z. B. Single Points of Failure)

2. Risiken bewerten

• Welche Ausfälle hätten welche Auswirkungen?

• Wo besteht akuter Handlungsbedarf?

3. Maßnahmen definieren

• Technisch (Hardening, Zugriffskonzepte)

• Organisatorisch (Vertretung, Prozesse, Richtlinien)

4. Umsetzung begleiten

• Einführung sicherer Standards (z. B. CIS Benchmarks)

• Strukturierte Umsetzung statt Insellösungen

5. Nachweis & Weiterentwicklung

• Dokumentation für Audits (ISO 27001, NIS2)

• Kontinuierliche Verbesserung

Ergebnis: Sicherheit, die funktioniert und geprüft standhält

Ihr Vorteil

• Weniger Abhängigkeit von Einzelpersonen
• Reduzierte Angriffsflächen
• Höhere Ausfallsicherheit
• Audit- und Compliance-Fähigkeit
• Klare Strukturen statt Unsicherheit

Die entscheidende Frage

Was passiert bei Ihnen, wenn morgen eine Schlüsselperson ausfällt?

• Läuft alles weiter?

• Oder steht ein Teil Ihres Unternehmens still?

Jetzt Klarheit schaffen

Lassen Sie uns gemeinsam herausfinden, wo Ihre größten Risiken liegen und wie Sie diese strukturiert beseitigen.

Jetzt unverbindlich anfragen:

Kontaktieren Sie uns für eine erste Einschätzung

Rewion – Ihr Partner für IT-Härtung, ISO 27001 & NIS2-Compliance

Lesen sie auch: Warum ISO 27001 und NIS2 keine Bedrohung, sondern eine strategische Chance sind.

Auch interessant alle Themen und Informationen beim: BSI