IT-Beratung & IT-Services

Die meisten Unternehmen nutzen heute eine Form von Cloud-Diensten oder betreiben ihre gesamte IT-Infrastruktur in der Cloud. Immer wichtiger wird dabei das Thema Souveränität: Wie behalten Unternehmen die volle Kontrolle über ihre Daten und bleiben unabhängig in der Wahl ihrer Cloud-Anbieter? Die Schwarz-Gruppe bietet mit der STACKIT Cloud eine europäische Lösung für Unternehmen, die großen Wert auf Datenschutz und souveräne Infrastruktur legen. Wir geben einen Überblick über die STACKIT Cloud, was sie bietet und für wen sie sich eignet.

Der Weg zur europäischen Cloud: Wie die STACKIT Cloud entstanden ist

Hinter STACKIT steckt ein bekannter Name: die Schwarz-Gruppe. Zu dem Handelskonzern gehören beispielsweise Lidl und Kaufland. Schon seit Jahren betreibt er eine umfangreiche eigene IT-Infrastruktur. Was als interne Lösung entstand, hat sich schrittweise zu einer eigenständigen Cloud-Plattform entwickelt und wurde 2021 offiziell für externe Unternehmen geöffnet.

Der Antrieb dahinter war der Bedarf an einer leistungsstarken Cloud-Plattform, die vollständig unter europäischer Kontrolle betrieben wird. Große Anbieter wie AWS, Azure und Google Cloud kommen alle aus den USA und bringen entsprechende Risiken und Einschränkungen für Unternehmen mit, die mit sensiblen Daten arbeiten.

STACKIT betreibt seine Infrastruktur ausschließlich in zertifizierten Rechenzentren in Deutschland und Österreich. Alle Daten bleiben damit innerhalb der Europäischen Union und unterliegen dem europäischen Datenschutzrecht. Zugriffe durch ausländische Behörden sind bei STACKIT strukturell ausgeschlossen. Damit entfallen die Risiken, die Unternehmen mit den großen US-Hyperscalern eingehen (Cloud Act).

Was bietet STACKIT mit seiner Cloud-Lösung?

STACKIT ist eine vollständige Cloud-Plattform mit einem breiten Produktportfolio. Unternehmen können damit ihre gesamte IT-Infrastruktur abbilden: vom einfachen Server über Datenspeicher bis hin zu serverless und nativen Services. Die Leistungen umfassen unter anderem:

• Compute Engine: Virtuelle Server, die sich flexibel an den tatsächlichen Bedarf anpassen lassen. Unternehmen zahlen nur das, was sie tatsächlich nutzen.
• Storage: Verschiedene Speicherlösungen für unterschiedliche Anforderungen: Blockspeicher für Datenbanken, Objektspeicher für große Datenmengen und Backup-Lösungen für die automatische Datensicherung.
• Kubernetes Engine: Eine verwaltete Umgebung für den Betrieb containerbasierter Anwendungen. STACKIT übernimmt dabei die technische Verwaltung des Systems, sodass sich IT-Teams auf die Anwendungen selbst konzentrieren können.
• Netzwerk & Security: Integrierte Funktionen für sichere Netzwerkkonfigurationen, Zugriffssteuerung und Firewalls direkt in der Plattform.
• Secrets Manager: Zentrale Verwaltung sensibler Zugangsdaten wie Passwörter, API-Schlüssel und Zertifikate.
• Confidential: STACKIT bietet spezielle Confidential Server, in denen Unternehmen besonders kritische Workloads ausführen können.
• Open Source Produkte: STACKIT bietet Produkte an, die sehr nah an den jeweiligen Upstream-Versionen einiger Open-Source-Lösungen liegen, z. B. MLflow, Jupyter Notebooks, Apache Airflow usw.

Alle Produkte laufen dabei auf derselben souveränen Infrastruktur. Unternehmen müssen also nicht zwischen Leistung und Datenschutz abwägen. Beides ist gleichzeitig gewährleistet.

Für welche Unternehmen eignet sich die Cloud von STACKIT?

STACKIT eignet sich grundsätzlich für Unternehmen jeder Größe und Branche, vom mittelständischen Betrieb bis zum Konzern. Besonders relevant ist die Plattform allerdings für Unternehmen, in denen Datenschutz und Compliance grundlegende Anforderungen sind. Besonders häufig kommt die Cloud in diesen Bereichen zum Einsatz:

• Gesundheitswesen: Patientendaten unterliegen strengen Datenschutzvorgaben. Eine europäische Infrastruktur mit klarer Rechtsgrundlage ist hier verpflichtend.
• Finanzbranche: Regulatorische Anforderungen durch BaFin und europäische Vorgaben schränken die Wahl des Cloud-Anbieters ein. STACKIT erfüllt alle nötigen Anforderungen der Branche.
• Öffentlicher Sektor: Behörden und öffentliche Einrichtungen sind auf datenschutzkonforme IT-Lösungen angewiesen, die Datenverarbeitung ausschließlich in Europa versichern.
• Industrie und Mittelstand: Immer mehr Unternehmen möchten ihre Abhängigkeit von einzelnen US-Anbietern reduzieren und ihre digitale Souveränität stärken.

In der Praxis setzen Unternehmen STACKIT für unterschiedliche Zwecke ein. Manche Firmen verlagern ihre gesamte IT-Infrastruktur aus dem eigenen Rechenzentrum oder einer bestehenden Cloud in die STACKIT Cloud. Andere nutzen die Plattform für einzelne Anwendungen, zum Beispiel für die Auslagerung der Datensicherung oder für besonders sensible Workloads. Wieder andere starten mit einem kleineren Pilotprojekt, um zuerst Erfahrungen zu sammeln, bevor sie größere Workloads migrieren.

Fazit: Die STACKIT Cloud für souveräne Infrastruktur mit europäischen Wurzeln

STACKIT ist mit seinen Rechenzentren in Deutschland und Österreich eine bewusste Entscheidung für Datensouveränität, europäisches Recht und unabhängige Infrastruktur. Für Unternehmen und Organisationen, die regelmäßig sensible Daten verarbeiten wie Krankenhäuser oder den öffentlichen Sektor ist sie ein sicherer Weg, ihre IT-Infrastruktur in der Cloud abzubilden.

Als zertifizierter STACKIT Professional & Managed Service Partner begleitet Rewion Unternehmen auf ihrem Weg in die STACKIT Cloud. Von der ersten Bestandsaufnahme über die Planung bis hin zum laufenden Betrieb der STACKIT Infrastruktur stehen wir an Ihrer Seite.

Krankenhäuser stehen aktuell vor einer ähnlichen Situation: Es gibt erste Ideen für KI‑Anwendungen teilweise auch schon den ersten PoC. Was dabei oft schwer einzuschätzen ist: Wie gut passt das eigentlich zur eigenen Ausgangssituation?

Denn genau hier entscheidet sich, ob ein Thema gut umgesetzt werden kann oder ob zunächst grundlegende Voraussetzungen zur KI Readiness fehlen.

Worum es hier wirklich geht

Bevor konkrete Anwendungsfälle ausgewählt oder priorisiert werden, geht es darum, die eigene KI Readiness bzw. eigene Voraussetzungen systematisch zu betrachten. Nicht abstrakt, sondern ganz konkret entlang mehrerer Dimensionen:

• Daten
• technische Integration
• organisatorische Strukturen
• Anforderungen aus Datenschutz und Informationssicherheit

Ziel ist es, ein realistisches Bild zu bekommen: Was ist heute bereits möglich und wo besteht noch Handlungsbedarf?

Voraussetzungen bedeutet mehr als nur Datenverfügbarkeit.

Die eigene Readiness entscheidet nicht nur darüber, ob ein Krankenhaus grundsätzlich mit KI arbeiten kann, sondern auch darüber, wie schnell sich bestimmte Themen realisieren lassen.

Woran sich die eigene Readiness einschätzen lässt

Einige Fragen können Orientierung geben, beispielsweise:

Ist absehbar, wie sich eine Lösung in die bestehende Systemlandschaft integrieren lässt?
Gibt es eine klare Vorstellung davon, wer fachlich und technisch Verantwortung übernimmt?
Ist geklärt, wie mit Datenschutz- und Sicherheitsanforderungen umgegangen wird

Typische Hinweise auf fehlende Voraussetzungen

Das WM-Dilemma: Wenn EWM zu groß und Stock Room zu wenig ist – Wie das neue SAP Logistics Management die Lücke schließt
Was das Ende des klassischen SAP WM für Ihr Unternehmen bedeutet und warum der SAP Logistics Management Vergleich zeigt, dass die neue SAP-Lösung weit mehr ist als nur ein Ersatz der klassischen Lagerverwaltung.

SAP WM: Ein Modul geht und reißt eine Lücke

Das SAP Warehouse Management (WM) hat für viele Unternehmen jahrelang zuverlässig funktioniert. Lagerplatzverwaltung, Transportaufträge, RF-Anbindung: SAP WM hat die Lagerverwaltung und seine Prozesse ideal abgebildet. Mit der Umstellung auf S/4HANA müssen sich Kunden auf neue Rahmenbedingungen einstellen.
SAP hat SAP WM nicht in den S/4HANA-Kern übernommen. Der Grund liegt in der Architektur: Statt einer Weiterentwicklung hat SAP einen Schnitt gemacht und das SAP Extended Warehouse Management (EWM) als strategische Nachfolgelösung positioniert.

Doch SAP EWM ist für viele Unternehmen zu mächtig, zu aufwändig und zu kostspielig in der Einführung. Kleine und mittelgroße Lager, regionale Standorte, Betriebe mit überschaubarer Lagerkomplexität, sie alle standen vor einem echten Problem: Was kommt nach SAP WM, wenn SAP EWM zu viel ist?

Die wichtigsten Fristen auf einen Blick

SAP Logistics Management: Die neue Lösung im Detail

SAP Logistics Management (LGM) wurde im Oktober 2025 auf der SAP Connect angekündigt und ist seit Q1 2026 allgemein verfügbar. Es ist keine Weiterentwicklung des alten SAP WM und kein abgespecktes SAP EWM, sondern eine vollständig neu konzipierte Cloud-native Lösung auf der SAP Business Technology Platform (BTP). Die Integration in den bestehenden ERP-Kern, SAP Cloud ERP Private (RISE/Private Cloud), erfolgt dabei nahtlos über offene APIs.

Während SAP EWM seine Stärken vor allem in großen, hochkomplexen Verteilzentren ausspielt, bietet SAP LGM eine passgenaue und effiziente Lösung für kleinere Lager mit klar strukturierten, weniger komplexen Prozessen. SAP LGM ist dabei kein reines Lagersystem, sondern vereint Lagerlogistik, Transportdisposition (LTL/FTL und Paketversand) und die Frachtkollaboration mit Carriern über das SAP Business Network in einer Lösung.

Hinzu kommen mobile Kommissionierung per App, Echtzeit-Transparenz über alle angebundenen Standorte sowie automatische Updates über die SAP Cloud-Infrastruktur, ohne aufwändige Release-Wechsel im eigenen System.

Was SAP Logistics Management von bisherigen Lösungen unterscheidet

Der entscheidende Unterschied zu SAP Stock Room Management ist nicht der Funktionsumfang, sondern die Richtung. Stock Room Management wurde eingeführt, um den Übergang zu vereinfachen, erhält aber keine Weiterentwicklung durch SAP. SAP LGM ist die von SAP vorgesehene Lösung zur Abbildung kleinerer Lager mit überschaubarer Prozesskomplexität. Darüber hinaus ist SAP LGM die einzige für kleinere Lager vorgesehene Lösung, die SAP künftig aktiv weiterentwickelt, inklusive eines nativ eingebetteten KI-Copiloten (Joule).

Gegenüber SAP EWM punktet SAP LGM mit deutlich geringerem Einführungsaufwand, einem SaaS-Modell ohne eigene Systemlandschaft und einer bewusst schlanken Funktionstiefe, ideal für Standorte, die keine vollautomatisierten Hochregallager betreiben.

Mischarchitekturen: SAP LGM und SAP EWM Hand in Hand

SAP hat SAP LGM bewusst so konzipiert, dass es sich mit SAP EWM kombinieren lässt. Ein typisches Szenario: Das Hauptwerk nutzt SAP EWM für komplexe Lagerprozesse, während regionale Auslieferungslager oder Produktionsbegleitlager mit SAP LGM angebunden werden. Die Anbindung läuft über offene APIs und das SAP Business Network. So laufen die Lagerprozesse glatt und transparent ohne die Komplexität von SAP EWM.

Was jetzt zu tun ist

Das Ende von SAP WM war absehbar. Trotzdem zögern viele Unternehmen und verlieren dabei wertvolle Zeit. Für SAP WM in S/4HANA on-premise sind die Nutzungsrechte des Kompatibilitätsmodus Ende 2025 ausgelaufen (letzte Übergangsfrist bis Mai 2026), im RISE-/Private-Cloud-Umfeld ist der Weiterbetrieb noch bis Ende 2030 möglich. Wer noch auf ECC arbeitet, sollte die Migration nicht weiter hinausschieben.

Die gute Nachricht: Mit SAP Logistics Management gibt es endlich eine realistische Option für Unternehmen, denen SAP EWM zu komplex und SAP Stock Room Management zu wenig ist. Die Lösung ist verfügbar, wird aktiv weiterentwickelt und schließt eine Lücke, die im SAP-Portfolio zu lange offen war.

Der Wunsch nach Künstlicher Intelligenz ist mittlerweile auch in vielen Krankenhäusern angekommen. Themen entstehen dabei häufig direkt aus dem Alltag heraus, zum Beispiel in der Dokumentation, bei Auswertungen oder in administrativen Prozessen. Typischerweise bringt ein Fachbereich eine konkrete Idee mit, die IT prüft mögliche Lösungen, Datenschutzbeauftragte und Informationssicherheitsbeauftragte werden eingebunden und daraus entsteht dann ein erstes Projekt.
Das ist grundsätzlich ein sinnvoller Einstieg und ein sinnvolles Vorgehen, um KI auszuprobieren. Aber wer langfristig auf KI bauen will und mit KI im Krankenhaus richtig starten will, wird feststellen, dass an genau diesem Punkt etwas fehlt.

Was zu Beginn oft noch nicht klar ist

Wenn ein KI‑Projekt startet, stehen meist sofort konkrete Fragen im Raum:

• Lässt sich die Lösung in die bestehende IT integrieren?
• Ist der Einsatz datenschutzkonform gestaltet?
• Unterstützt die Anwendung den Arbeitsalltag im Fachbereich?

Diese Perspektiven sind alle relevant und notwendig. Was häufig erst später aufkommt, ist die übergeordnete Einordnung:

• Wofür soll KI im eigenen Haus überhaupt eingesetzt werden?
• In welchen Bereichen ist der Einsatz sinnvoll und wo eher nicht?
• Welche Ziele werden damit konkret verfolgt?
• Nach welchen Kriterien werden weitere Initiativen entschieden?

Solange diese Fragen offen bleiben, entstehen einzelne Projekte, aber kein gemeinsamer Rahmen.

Warum sich das später bemerkbar macht

Gerade in Krankenhäusern sind an solchen Themen mehrere Bereiche und Rollen beteiligt, unter anderem:

• Fachbereiche, die konkrete Probleme lösen wollen
• IT, die Integration und Betrieb sicherstellen muss
• Datenschutz und Informationssicherheit, die regulatorische Anforderungen einbringen

Ohne gemeinsame Grundlage treffen hier unterschiedliche Perspektiven aufeinander. Das führt weniger zu „Fehlern“ , sondern eher dazu, dass jedes Projekt neu eingeordnet werden muss.

Typische Effekte sind dann:

• Diskussionen über Nutzen und Priorität erst im laufenden Projekt
• unterschiedliche Erwartungen an dieselbe Anwendung
• uneinheitliche Entscheidungen von Fall zu Fall

Der Aufwand entsteht dadurch nicht in der Umsetzung selbst, sondern in der fehlenden Orientierung davor.

Der eigentliche Knackpunkt: Die Einordnung fehlt zu Beginn

Viele Initiativen steigen direkt in konkrete Anwendungen ein. Das ist so gesehen auch nachvollziehbar, weil der Bedarf oft klar sichtbar ist. Gleichzeitig fehlt damit ein kurzer, vorgelagerter Schritt: eine gemeinsame Einordnung, bevor einzelne Use Cases definiert oder Tools ausgewählt werden. Genau an dieser Stelle setzt auch ein strukturierter Ansatz an.

Ein kurzer Blick auf den Gesamtprozess

KI‑Einführung ist kein einzelnes Projekt, sondern ein Prozess mit mehreren aufeinander aufbauenden Schritten.
Ein sinnvoller Aufbau lässt sich in fünf Phasen gliedern:

1. Strategische Einordnung
2. Voraussetzungen und Readiness des Krankenhauses
3. Auswahl geeigneter Anwendungsfälle
4. Implementierung und Integration
5. Betrieb und Weiterentwicklung

Dieser Beitrag bezieht sich bewusst auf den ersten Schritt, weil genau hier die Grundlage für alles Weitere gelegt wird.

Worum es am Anfang konkret geht

Die erste Phase besteht nicht aus umfangreicher Strategiearbeit, sondern aus einer gezielten Klärung von wenigen zentralen Punkten. Im Kern geht es darum, alle Stakeholder an einen Tisch zu holen, um eine gemeinsame Orientierung festzulegen:

• Wofür soll KI eingesetzt werden?
  Geht es primär um Entlastung, Qualität, Steuerung oder etwas anderes?
• Wo entsteht wirklich zusätzlicher Nutzen?
  Welche Themen lassen sich mit klassischen Mitteln lösen und wo lohnt sich KI tatsächlich?
• Welche Bereiche stehen im Fokus?
  Wo wird bewusst gestartet und wo zunächst nicht?
• Wie werden Entscheidungen getroffen?
  Wer bewertet Ideen nach welchen Kriterien wird bewertet?
  Wer und wie wird priorisiert?
  Wer trägt für was Verantwortung im weiteren Verlauf?

Diese Fragen wirken unscheinbar, aber in der Praxis machen sie dann den Unterschied zwischen isolierten Initiativen und einem konsistenten Vorgehen.

Warum dieser Schritt am Anfang entscheidend ist

Diese Abstimmung entfaltet ihre größte Wirkung, wenn sie vor den ersten konkreten Projekten stattfindet. Sobald ein Use Case definiert ist oder ein Tool ausgewählt wurde, entstehen bereits Erwartungen und Annahmen. Diese im Nachhinein zu synchronisieren, ist deutlich aufwändiger.
Wird die Einordnung dagegen früh gemeinsam vorgenommen, ergibt sich eine stabile Grundlage für die nächsten Schritte:

• klarere Auswahl von Anwendungsfällen
• konsistentere Entscheidungen
• weniger Abstimmungsaufwand zwischen IT, Fachbereich und Geschäftsführung
• realistischere Erwartungen im Projektverlauf

Kurz & Konkret:

Viele KI‑Initiativen im Krankenhaus starten aus einem konkreten Bedarf heraus. Das ist sinnvoll und oft der richtige Impuls. Damit daraus tragfähige Lösungen entstehen, braucht es jedoch einen kurzen Schritt davor: eine gemeinsame Einordnung von Ziel, Nutzen und Rahmen. Dieser Schritt ist die Grundlage für alles, was danach folgt. Wer ihn bewusst einplant, erleichtert sich die nächsten Phasen erheblich.

Im Jahr 2026 werden zentrale Secure Boot Zertifikate erneuert. Unternehmen sollten diese Umstellung aktiv einplanen, denn Secure Boot schützt nur dann zuverlässig, wenn die zugrunde liegenden Vertrauensketten aktuell sind. Für IT-Verantwortliche bedeutet das: Geräte und Firmwarestände, Betriebssysteme und Sonderfälle wie Linux oder Virtualisierung sollten rechtzeitig geprüft werden. In diesem Artikel zeigen wir Ihnen, warum die Umstellung wichtig ist und wie Sie den Austausch der Zertifikate strukturiert vorbereiten können.

Secure Boot im Überblick

Secure Boot schützt den Startvorgang eines Systems. Vereinfacht gesagt wird bereits vor dem Laden des Betriebssystems geprüft, ob die gestarteten Betriebssysteme und Treiber vertrauenswürdig sind. Vor der Einführung von Secure Boot konnten Angreifer Schadsoftware deutlich leichter in sehr frühe Startphasen einschleusen. Klassische Schutzmechanismen im Betriebssystem griffen zu diesem Zeitpunkt häufig noch nicht. Secure Boot wurde deshalb als Schutzmechanismus etabliert und kam mit Windows 8 breiter in den Markt. Betroffen von der aktuellen Umstellung sind unter anderem Windows, Linux- und Virtualisierungsumgebungen.

Technisch arbeitet Secure Boot mit Erlaubnis- und Sperrlisten. Diese Listen entscheiden, welche Bootloader, Treiber und Firmware gestartet werden dürfen und welche ausdrücklich blockiert sind. Man kann sie sich wie einen digitalen Türsteher vorstellen: Ist eine Komponente bekannt und erlaubt, darf sie starten. Steht sie auf der Sperrliste, wird die Ausführung verweigert.

Die Vertrauensstruktur hinter Secure Boot basiert auf digitalen Zertifikaten und Schlüsseln. An oberster Stelle steht der Platform Key (PK), der in der Regel vom Geräte- oder Mainboard-Hersteller gesetzt wird. Darunter befindet sich der Key Exchange Key (KEK), über den Änderungen an den nachgelagerten Listen autorisiert werden. Die erlaubten Komponenten befinden sich in der Allow-Datenbank (db), während bekannte unsichere oder zurückgezogene Komponenten in der Disallow-Datenbank (dbx) landen. Vereinfacht gesagt: Der PK vertraut dem KEK, der KEK autorisiert Änderungen an db und dbx, und diese Listen entscheiden darüber, was beim Systemstart ausgeführt werden darf.

Übersicht über die alten und neuen Secure Boot Zertifikate

Übersicht über die Baumstruktur der Secure Boot Zertifikate

Planung einer Umsetzung

Für Unternehmen empfiehlt sich ein schrittweises Vorgehen. Zuerst sollte geprüft werden, auf welchen Geräten Secure Boot bereits aktiv ist und wo es noch deaktiviert ist. Geräte ohne aktiviertes Secure Boot sollten gesondert bewertet werden, da hier möglicherweise zusätzliche Konfigurationsanpassungen notwendig sind. Anschließend sollten aktuelle Firmware-Versionsstände geprüft werden, damit die neuen Zertifikate sauber übernommen werden können.

Microsoft sieht für den Austausch der UEFI-Zertifikate im Wesentlichen zwei Aktualisierungswege vor. Welcher Weg besser passt, hängt davon ab, wie viel Kontrolle Sie über den Rollout behalten möchten und wie stark Ihre Umgebung standardisiert ist.

1. Controlled Feature Rollout (CFR): verwaltet durch Microsoft über Diagnosedaten
2. Latest Cumulative Update (LCU): verwaltet durch einen selbst mit Windows Updates

Beim Controlled Feature Rollout werden Geräte in Gruppen eingeteilt. Microsoft nutzt dafür zusätzliche Diagnosedaten, um zu bewerten, welche Gerätegruppen mit hoher Wahrscheinlichkeit für die Aktualisierung geeignet sind. Sobald eine Gruppe freigegeben ist, werden die Zertifikate automatisch ersetzt. Aus den übermittelten Diagnosedaten entsteht eine High Confidence Database (HCD), die dabei hilft, weitere Gerätegruppen sicherer für den Rollout zu bewerten.

Bei der Variante über das Latest Cumulative Update behalten Sie mehr Kontrolle über den Ablauf. Die neuen Zertifikate sowie die aktuelle HCD werden seit Mai 2025 mit den monatlichen Sicherheitsupdates bereitgestellt. Windows gleicht die vorhandene Hardware mit der HCD ab und entscheidet darauf basierend, ob ein Gerät für die Aktualisierung geeignet ist. Für kontrollierte Unternehmensumgebungen ist dieser Weg besonders interessant, weil sich Tests, Pilotgruppen und Rollout-Stufen gezielt planen lassen.

An dieser Stelle passt auch der Hinweis auf unseren letzten Blogartikel zu den Windows Updates im Juni 2026. Dort geben wir monatlich eine Übersicht über relevante Windows Updates. Mit den Juni-Updates wurden weitere Gerätegruppen für die Umstellung freigegeben.

Die Umsetzung lässt sich über Gruppenrichtlinien, Intune-Richtlinien oder über die Kommandozeile steuern. Wichtig ist, dass Sie den gewählten Weg dokumentieren und zunächst mit Pilotgeräten testen, bevor Sie die Aktualisierung breit ausrollen. Über die verfügbaren Werkzeuge steuern Sie, ob die Aktualisierung über CFR oder über LCU erfolgen soll. Wenn Sie den Austausch schrittweise durchführen, sollten Sie die erzeugten Ereignisse und Registry-Einträge regelmäßig prüfen. Darüber lässt sich nachvollziehen, in welchem Zustand sich ein Gerät befindet und welche Schritte bereits erfolgt sind. Besonders wichtig ist die AvailableUpdates-Bitmaske, da sie maßgeblich beeinflusst, welche Aktualisierungsschritte angestoßen werden.

Besonderheit bei Linux und anderen

Auch Linux- und Virtualisierungsumgebungen sollten in die Planung einbezogen werden. Damit nicht jede Linux-Distribution separat in der Secure Boot-Datenbank hinterlegt werden muss, kommt häufig der sogenannte Linux Shim zum Einsatz. Dieser ist in der Allow-Datenbank eingetragen und kann wiederum Schlüssel von Linux-Distributionen verwenden, um anschließend den Bootloader GRUB zu prüfen und zu starten.

Den Secure Boot-Status eines Linux-Systems können Sie mit einfachen Bordmitteln prüfen. Zusätzlich stellen Virtualisierungsanbieter bereits eigene Hinweise und Empfehlungen bereit, beispielsweise VMware und Proxmox. Gerade in gemischten Umgebungen ist es sinnvoll, diese Systeme frühzeitig in Pilot- und Kompatibilitätstests einzubeziehen. Intune bietet hierzu qualifizierte vorgefertige Reports an. Ein Auswertung lässt sich auch ohne Intune durchführen.

Solange eine sorgfälltige Vorausplanung durchgeführt wird, stellt sich der Umstellung nichts mehr im Wege.

Bei Fragen zum Thema Secure Boot und der Zertifikatsverwaltung stehen wir Ihnen gerne beratend zur Seite. Wir freuen uns auf Ihre Kontaktaufnahme.

Wie an jedem zweiten Dienstag im Monat werden die Sicherheitsupdates für Clients und Server von Microsoft veröffentlicht. Im Juni 2026 schließt Microsoft 198 Schwachstellen, davon 32 kritische.

Welche Patches müssen heute Nacht raus und was kann warten? Hier ist unsere Einschätzung.

Sicherheitsupdates für Juni 2026 im Überblick

Zuletzt geprüft am 15.06.2026, 15:16 Uhr

Ganzheitlicher Blick auf die Support Zeiträume

Die folgende Matrix gibt Aufschluss über die aktuellen Support-Zeiträume. Die Update-Verlängerung bezieht sich auf das Extended Security Update (ESU) Programm von Microsoft.

Zuletzt geprüft am 15.06.2026, 15:22 Uhr

Schlussworte

Fragen zu einzelnen Updates oder zur Patch-Strategie in Ihrer Umgebung? Sprechen Sie uns an.

Ein neues Gerät bestellen, einrichten, ausgeben und irgendwann wieder einsammeln: Lifecycle Management klingt auf den ersten Blick überschaubar, ist es in der Praxis aber selten. Zwischen Erstkonfiguration, laufendem Betrieb und sicherem Offboarding entstehen ohne klare Prozesse schnell Lücken wie fehlende Updates, vergessene Zugänge oder nicht gelöschte Daten. Mobile Device Management schafft hier eine wichtige Struktur und macht Lifecycle Management von einer organisatorischen Herausforderung zu einem steuerbaren, größtenteils automatisierten Ablauf. Was das konkret bedeutet und welche Phasen Geräte im Lifecycle Management mit MDM durchlaufen, erklären wir in diesem Artikel.

Phase 1 – Onboarding: Lifecycle Management beginnt vor dem ersten Login

Der erste Eindruck zählt. Das gilt auch für Firmengeräte wie Laptops, Smartphones und Tablets. Geben Unternehmen Geräte unvorbereitet aus, entsteht Arbeit auf beiden Seiten. Die IT richtet alles manuell ein, die Mitarbeitenden wiederum warten darauf. Mit MDM läuft das anders. Über Funktionen zum automatischen Enrollment können Geräte so vorkonfiguriert werden, dass sie beim ersten Einschalten direkt ins Unternehmenssystem eingebunden werden. Apps, WLAN-Profile, Sicherheitsrichtlinien und Zugangsdaten werden zentral ausgerollt, ohne dass jemand das Gerät vorher in der Hand gehabt haben muss.

In der Praxis bedeutet das:

• Neue Mitarbeitende erhalten ein einsatzbereites Gerät, ohne auf die IT warten zu müssen.
• Die IT-Abteilung spart sich repetitive Einrichtungsschritte bei jedem Rollout.
• Einheitliche Konfigurationen verhindern von Anfang an Abweichungen vom Sicherheitsstandard.

Gerade bei größeren Unternehmen oder häufigem Personalwechsel macht dieser Einstiegspunkt einen wichtigen Unterschied in der Geräteverwaltung. Mit MDM ist sie skalierbar, ohne entstehen unübersichtliche manuelle Aufgaben, die fehleranfällig sind.

Phase 2 – Betrieb: Lifecycle Management im Tagesgeschäft

Sobald das fertig eingerichtete Gerät ausgegeben ist, beginnt die längste Phase. Der Betrieb ist gleichzeitig oft die unübersichtlichste Phase, weil sich Geräte, Nutzer und Anforderungen laufend verändern. MDM hält den Betrieb strukturiert, ohne dass die IT ständig eingreifen muss. Zentral ist dabei das Thema Updates: Veraltete Betriebssysteme und fehlende Sicherheitspatches gehören zu den häufigsten Gründen für Cyberangriffe. Über die MDM-Lösung kann die IT Updates zeitgesteuert und richtlinienbasiert ausrollen. Das funktioniert für alle Geräte gleichzeitig, ohne dass manuelle Einzelaktionen nötig sind.

Daneben können IT-Teams Mobile Device Management im laufenden Betrieb für verschiedene weitere Aufgaben einsetzen:

• Monitoring: Welche Geräte sind aktiv, welche sind vielleicht nicht regelkonform? Ein zentrales Dashboard gibt jederzeit einen Überblick, ohne Einblick in private Inhalte der Nutzenden zu ermöglichen.
• Fernwartung: Probleme können remote behoben werden, die IT kann Einstellungen anpassen, Apps installieren oder entfernen. Besonders relevant ist das für ortsunabhängige Teams und den Außendienst.
• Compliance-Umsetzung: Verstößt ein Gerät gegen definierte Richtlinien, kann das System automatisch reagieren und den Zugang einschränken.

Der wichtigste Vorteil liegt darin, dass die IT den Überblick behält, ohne ständig präsent sein zu müssen. Regelwerke laufen im Hintergrund und Abweichungen davon werden sichtbar, bevor sie sich zum Problem entwickeln können.

Phase 3 – Offboarding: Lifecycle Management endet nicht mit der Kündigung

Das Offboarding ist die Phase, die Unternehmen am häufigsten unterschätzen. Hier können die größten Risiken entstehen, wenn Prozesse fehlen. Verlässt eine Person das Unternehmen, muss die IT die Zugänge sperren und Daten löschen. Die selbstverständlich klingende Aufgabe kann ohne Mobile Device Management fehleranfällig sein. Es fehlt ein Überblick, welche Apps installiert waren, welche Unternehmensdaten auf dem Gerät lagen und ob überhaupt alle Geräte zurückgegeben wurden.

Mit MDM gibt es eine strukturierte Lösung: Per Remote Wipe lässt sich ein Gerät auf Knopfdruck auf Werkseinstellungen zurücksetzen – unabhängig davon, wo es sich befindet. Für BYOD-Geräte, die auch privat genutzt werden, gibt es alternativ den Selective Wipe. Dabei werden nur die Unternehmensanwendungen und -daten entfernt, private Inhalte bleiben bestehen.

Nach der Löschung steht die nächste Frage: Können wir das Gerät weiterverwenden oder sollten wir es ausmustern? MDM unterstützt beide Wege. Ein zurückgesetztes Gerät kann direkt wieder ins Enrollment und für die nächste Person konfiguriert werden. Der Lifecycle beginnt dann einfach von vorne. Ältere Geräte, die ausgemustert werden, sollten entsprechend gelöscht sein.

Fazit: Lifecycle Management wird mit Mobile Device Management planbar

Das Lifecycle Management von Geräten ist ein kontinuierlicher Prozess in Unternehmen – ob es dabei um Geräte von Mitarbeitenden oder um unternehmenseigene Geräte geht, um Smartphones, Laptops oder Tablets. Von der ersten Konfiguration bis zur sicheren Rückgabe müssen IT-Teams viele Faktoren berücksichtigen. Mobile Device Management macht den Prozess sichtbar und skalierbar: Das Onboarding läuft automatisiert, der Betrieb bleibt kontrollierbar, das Offboarding wird sauber abgeschlossen. Mit durchdachtem Lifecycle Management reduzieren Unternehmen langfristig ihren manuellen IT-Aufwand, schließen Sicherheitslücken und schaffen eine strukturierte Grundlage für alle Geräte, die im Umlauf sind.

Cloud-Infrastrukturen entwickeln sich nahezu tagtäglich weiter und mit ihnen die Anforderungen an Teams, die diese Umgebungen betreiben und weiterentwickeln. Auch das Cloud Platform Engineering ist entsprechend in Bewegung: Neue Technologien, Nutzungsmuster und Anforderungen nehmen Einfluss darauf, wie Plattformen gebaut werden und aussehen sollen. Dieser Artikel gibt einen Überblick über vier Entwicklungen, die das Cloud Platform Engineering in den kommenden Jahren beeinflussen und welche Veränderungen sich dadurch ergeben können.

Infrastruktur ohne selbst gehostete Server: Serverless Architekturen

In klassischen Cloud-Umgebungen bauen Entwicklungsteams ihre Anwendungen und sind zusätzlich für die Verwaltung der Infrastruktur dahinter verantwortlich: Server bereitstellen, skalieren, aktualisieren und überwachen. Serverless Architekturen verschieben diese Verantwortung vollständig. Statt die Infrastruktur selbst zu verwalten, übernimmt das der Cloud Provider. Server gibt es natürlich weiterhin, das Unternehmen muss sich aber nicht mehr selbst darum kümmern. Entwicklungsteams stellen nur noch ihren Code oder Container bereit, der automatisch skaliert und nutzungsbasiert abgerechnet wird.

Daraus ergeben sich verschiedene Veränderungen und Vorteile:

• Weniger Betriebsaufwand: Plattformteams müssen keine Serverkapazitäten mehr einplanen oder verwalten. Die Infrastruktur passt sich selbst an.
• Schnellere Bereitstellung: Neue Funktionen lassen sich in kürzerer Zeit produktiv schalten, weil kein Aufbau der Infrastruktur mehr nötig ist.
• Neue Kostenstruktur: Statt für dauerhaft gebuchte Server zahlen Unternehmen nur für tatsächliche Nutzung. Das kann bei schwankendem Bedarf erhebliche Einsparungen bedeuten.

Serverless ist für viele Anwendungsfälle ein Effizienzgewinn und ist teilweise schon heute fester Bestandteil moderner Plattformstrategien.

Daten dort verarbeiten, wo sie entstehen mit Edge Computing

Klassische Cloud-Architekturen folgen einem klaren Prinzip: Daten werden gesammelt, in ein Rechenzentrum übertragen und dort verarbeitet. Das funktioniert gut, solange Geschwindigkeit keine kritische Rolle spielt und die Datenmenge beherrschbar bleibt. Dieser Weg wird aber immer häufiger zu langsam. Geräte am sogenannten Edge, also am Rand eines Netzwerks wie beispielsweise Maschinen in einer Produktionshalle, Fahrzeuge oder medizinische Geräte erzeugen besonders große Datenmengen. Diese alle erst in ein zentrales Rechenzentrum zu schicken, kostet Zeit und Bandbreite.

Beim Edge Computing wird ein Teil der Verarbeitung dorthin verlagert, wo die Daten entstehen. Sie findet direkt auf dem Gerät oder in unmittelbarer Nähe davon statt. Das bringt mehrere Vorteile mit sich:

• Reaktionszeiten sinken erheblich, weil keine langen Übertragungswege mehr nötig sind.
• Netzwerklast und Übertragungskosten werden reduziert.
• Sensible Daten müssen das lokale Umfeld gar nicht erst verlassen.

Für Cloud Platform Engineering bedeutet dieser Trend, dass Plattformen künftig nicht mehr nur zentrale Rechenzentren, sondern auch dezentrale Infrastruktur an verschiedenen Standorten verwalten können müssen. Das Modell ist zwar deutlich komplexer, aber auch zukunftsfähig.

KI-gestützte Verwaltung als Plattform, die mitdenkt

Cloud-Umgebungen wachsen. Mit der Zahl der Services, Teams und Anwendungen steigt auch die Komplexität irgendwann in Dimensionen, die manuell kaum noch beherrschbar sind. In solchen Fällen kann der Einsatz KI-gestützter Plattformverwaltung sinnvoll sein. Konkret geht es darum, wiederkehrende Aufgaben zu automatisieren und Muster zu erkennen, die für Menschen schwer zu erfassen sind. Plattformen, die KI einsetzen, können zum Beispiel:

• Anomalien frühzeitig erkennen: Ungewöhnliches Verhalten in der Infrastruktur wird automatisch gemeldet, bevor es zu einem ernsthaften Problem wird.
• Ressourcen intelligenter verteilen: Anhand von Nutzungsmustern wird die Infrastruktur vorausschauend skaliert.
• Routineaufgaben übernehmen: Updates, Konfigurationsanpassungen oder Sicherheitsprüfungen laufen automatisiert ab, ohne dass ein Mensch jeden Schritt anstoßen muss.

Wichtig ist dabei: KI-gestützte Verwaltung ersetzt Plattformteams nicht, sondern ist zur Entlastung da. Der Routineaufwand sinkt, sodass sich Mitarbeitende auf Entwicklungsaufgaben fokussieren können.

Nachhaltiger betreiben: Green IT als zentraler Trend im Cloud Platform Engineering

Cloud-Infrastrukturen verbrauchen große Mengen an Energie. Rechenzentren gehören zu den energieintensivsten Einrichtungen überhaupt. Mit steigender Cloud-Nutzung wächst dieser Fußabdruck entsprechend weiter. Nachhaltigkeit ist damit längst zum wichtigen Trend im Cloud Platform Engineering geworden. Unternehmen reagieren darauf auf verschiedenen Ebenen:

• Wahl des Anbieters: Cloud-Anbieter mit nachweislich erneuerbaren Energiequellen und transparenter Klimabilanz nehmen eine immer wichtigere Rolle ein.
• Effizientere Ressourcennutzung: Ungenutzte Ressourcen werden konsequenter abgeschaltet, Workloads sinnvoll skaliert, um nur so viel Energie zu verbrauchen wie wirklich nötig.
• Messbarkeit als Voraussetzung: Möchten Unternehmen Emissionen reduzieren, müssen sie sie erst erfassen können. In Plattformen finden sich immer häufiger Tools, die den tatsächlichen CO₂-Fußabdruck von Cloud-Workloads sichtbar machen.

Nachhaltigkeit und Effizienz gehen hier Hand in Hand: Optimieren Unternehmen ihren Energieverbrauch, sparen sie in der Regel auch Kosten.

Cloud Platform Engineering Trends: heute planen, morgen vorn mitspielen

Aktuelle Entwicklungen im Cloud Platform Engineering, von Serverless Architekturen über Edge Computing und KI-gestützter Verwaltung bis hin zu Green IT, sind schon heute im Einsatz. Unternehmen nutzen die Möglichkeiten schon in unterschiedlichen Reifegraden. In vielen Firmen stehen die Entwicklungen allerdings noch am Anfang, sodass wir davon ausgehen können, dass diese Trends uns noch einige Jahre begleiten werden. Beziehen Unternehmen für sie sinnvolle Trends frühzeitig in ihre Plattformstrategie ein, schaffen sie Strukturen, die sich zukünftigen Anforderungen anpassen können. Dabei ist nicht jedes Thema für jedes Unternehmen gleich relevant. Es lohnt sich aber, einen Blick auf die Möglichkeiten zu werfen.