Apple. Klar geführt. Als Plattform.
Platform6 führt Apple als eigenständige Plattform: Identity als Steuerungsebene, Zero-Touch als Standard, Sicherheits-Baselines als überprüfbarer Zustand. Am Ende steht ein Betriebsmodell, das Ihr Team selbst betreibt und Ihre Revision nachvollziehen kann.
Von Riga aus — vor Ort in Deutschland, Lettland, Litauen und Estland.
- Zero-Touch Enrollment, Platform SSO, deklarative Konfiguration
- Baselines für macOS, iOS und iPadOS mit dokumentierter Begründung je Einstellung
- Sechs Wochen bis zum übergebenen Zielzustand, mit Runbooks und benannter Ownership
Der Zustand muss erklärbar bleiben
In vielen Organisationen existiert Apple „nebenbei“: Geräte funktionieren, aber die Plattform ist nicht geführt. Das rächt sich, sobald Verantwortung, Updates, Security-Statements oder Audits ins Spiel kommen. Platform6 richtet deshalb zuerst die Architektur so aus, dass der Zustand dauerhaft erklärbar bleibt, für Betrieb, Security und Leitung.
Apple ohne Plattformführung
Apple ist im Einsatz, aber Identität, Gerätezustand und Betrieb greifen nicht sauber ineinander. Das führt zu „funktioniert irgendwie“-Pfaden: lokale Sonderfälle, unklare Update-Fenster, Support-Wissen in Köpfen, und Security, die Listen pflegt statt Wirksamkeit zu zeigen.
Plattformzustände führen
Platform6 verbindet Identity (z. B. Platform SSO), den Device Lifecycle (Enrollment bis Stilllegung) und Sicherheits-Baselines zu einem Zustand, der in Betrieb übersetzt werden kann: Regeln, Verantwortung, Abweichungen, und ein klarer Weg vom „Ist“ zum „Soll“.
Zugriff folgt Identität und Gerätezustand
Planbare Updates, klare Übergaben
Wirksamkeit und dokumentierte Abweichung
Ein tragfähiger Plattformzustand
Betrieb, Security und Verantwortung greifen ineinander. Der Zustand ist dokumentiert, intern erklärbar, und bleibt stabil, auch wenn Teams wechseln, neue Anforderungen auftauchen oder Workloads dazukommen.
Apple als Plattform. Nicht als Ausnahme.
Viele Organisationen haben Apple-Geräte, wenige haben eine Apple-Plattform. Was den Unterschied macht, sind Architekturentscheidungen: Ownership, Leitplanken und ein definierter Zielzustand, der Sicherheit, Betrieb und Compliance zusammenführt. Genau das liefern zwei klar abgegrenzte Angebote.
Apple Sovereign Workplace Landing Zone
Für Organisationen, die Apple von Anfang an richtig aufsetzen wollen.
Die Landing Zone definiert einen nicht verhandelbaren Day-1-Zustand für Apple in regulierten Umgebungen. Kein Projekt, kein Proof-of-Concept – sondern ein vollständiges, dokumentiertes Betriebsmodell.
Was entsteht- Klarer Identitäts- und Zugriffsrahmen (Platform SSO, MFA, Passkeys)
- Zero-Touch Enrollment und rollenbasierte Geräte-Blueprints
- Sicherheits- und Compliance-Baselines als definierter Zustand
- Klare Betriebs-Ownerships, Runbooks und Kontrollmechanismen
Apple ist auditfähig, betreibbar und organisatorisch verankert – vom ersten Gerät an.
Bewusste Grenzen- Keine Identity-Neubauten
- Keine App-Modernisierung
- Keine Sonderarchitekturen pro Fachbereich
Apple Zero-Touch Transformation Kit
Für Organisationen mit bestehender Apple-Flotte und struktureller Altlast.
Dieses Kit transformiert Apple aus einem AD-abhängigen Sonderfall in eine eigenständige Plattform. Nicht schrittweise über Jahre, sondern in einem klar geführten Architektur-Zyklus.
Was sich ändert- Entkopplung von AD-Bindungen und historischer Windows-Logik
- Einführung von Platform SSO und identitätsgetriebenen Workflows
- Umstellung auf Zero-Touch Provisioning und deklarative Policies
- Neudefinition von Admin-Rollen, Verantwortlichkeiten und Routinen
Apple wird führbar, skalierbar und sicher – ohne den Betrieb dauerhaft zu belasten.
Bewusste Grenzen- Kein AD-Migrationsprojekt
- Keine endlosen Übergangszustände
- Keine Ausnahme-Architektur als Dauerlösung
Beide Angebote liefern keinen Beratungsvorschlag, sondern einen Zustand – einen, den Admins betreiben können, ohne täglich fehlende Entscheidungen zu kompensieren.
Vom Ist-Zustand zum definierten Zielzustand.
Kurzer Zyklus, der in einem laufenden Zustand mit Ownership endet.
Eine definierte Plattform ist eine bewusste Entscheidung.
Passt, wenn …
- Regulierte Organisationen mit realer Audit-Last
- Umgebungen, in denen Apple als eigenständige Plattform laufen soll – nicht als Windows-Sonderfall
- Teams, die Standards wollen, nicht Endlos-Customizing
Passt nicht, wenn …
- „Wir wollen Apple, aber ABM/MDM lehnen wir ab“
- „Wir brauchen Ausnahmen für jede Abteilung“
- „Wir müssen erst IAM komplett neu bauen“
Häufige Fragen
Braucht unsere Behörde für VS-NfD ein bestimmtes MDM?
Ja. Für indigo verlangt das BSI eine zertifizierte MDM-Serverkomponente nach dem Protection Profile MDM-TS (BSI-CC-PP-0115), betrieben on-premises auf souveräner Infrastruktur. Vollständig zertifiziert ist derzeit BlackBerry UEM. Welche Produkte darüber hinaus noch unter Übergangsfrist laufen und welche ohne Zertifikat aus der Frist gefallen sind, steht auf der indigo-Seite.
Die Auswahl des MDM ist dabei die kleinere Hälfte der Aufgabe: Die Betriebsumgebung um den zertifizierten Server herum ist nicht zertifiziert und muss architektonisch gebaut werden.
Können wir das mit unserem Cloud-MDM abbilden?
Für VS-NfD heute nicht. Das Protection Profile MDM-TS ist auf On-Premises-Betrieb ausgelegt, und die Brightsite-Anforderung verlangt einen MDM-Server unter deutscher Betriebskontrolle.
Für Cloud-Dienste existiert bisher kein passendes Protection Profile, die SOGIS-Harmonisierung dafür steht aus, und die Frage, unter welchen Bedingungen US-Anbieter EUCS Level High erfüllen können, ist politisch offen. Die drei Abhängigkeiten haben wir in einem eigenen Beitrag auseinandergenommen: Cloud-MDM und BSI-Zertifizierung.
Sie sind ein sehr kleiner Anbieter. Gibt es Sie in zwei Jahren noch?
Berechtigte Frage, deshalb ist die Antwort in die Arbeitsweise eingebaut. Jedes Engagement endet mit einer Übergabe statt mit einem Wartungsvertrag: Konfiguration, Dokumentation, Architecture Decision Records und Runbooks gehören danach Ihnen, und Ihr Team betreibt die Plattform eigenständig.
Wenn Platform6 morgen verschwindet, läuft Ihr Zielzustand weiter. Über ein Dauermandat bei einem Großanbieter lässt sich das so nicht sagen.
Arbeitet ihr nur mit Jamf?
Nein. Wir arbeiten mit marktüblichen Enterprise-MDM-Systemen wie Jamf, BlackBerry UEM, Ivanti, Omnissa, Microsoft Intune oder vergleichbaren Lösungen. Entscheidend ist nicht das Tool, sondern ein sauberer Betrieb mit Apple Business Manager und MDM. Ohne diese Grundlagen ist keine belastbare Plattformführung möglich.
Migriert ihr unsere Identity-Plattform oder das Active Directory?
Nein. Wir integrieren bestehende Enterprise-Identitäten in eine klare Apple-Architektur. Identity-Systeme ersetzen und IAM-Großprojekte führen andere. Wir integrieren bestehende Enterprise-Identitäten wie Entra ID oder Okta in eine klare Apple-Architektur und entkoppeln Apple dort, wo es betrieblich sinnvoll ist, von historischer Windows-Logik.
Was ist am Ende konkret geliefert?
Geliefert wird ein laufender, definierter Zielzustand: Konfiguration, Dokumentation, Kontrollmechanismen, Rollenmodellen und Betriebsroutinen. Der Zustand ist auditierbar, betreibbar und alltagstauglich.
Ist das ein Projekt oder eine dauerhafte Beratung?
Wir arbeiten zielzustandsorientiert: klarer Scope, klarer Endpunkt, klarer Übergang in den Betrieb. Der Zielzustand funktioniert auch ohne dauerhafte externe Abhängigkeit.
Was kostet das?
Die Investition liegt typischerweise im niedrigen bis mittleren 5-stelligen Bereich, abhängig von Scope, Fleet-Size und bestehender Infrastruktur.
Entscheidend: Sie zahlen für einen definierten Zielzustand, nicht für Beratungstage. Nach Woche 6 läuft die Plattform – ohne dauerhafte externe Abhängigkeit. Ein typisches "Apple-Modernisierungs-Projekt" über 18–24 Monate kostet ein Vielfaches und endet oft ohne klaren Endzustand.
Wie groß muss unsere Organisation / Fleet sein?
Landing Zone: Macht ab ~50 Geräten Sinn, wenn Apple von Anfang an sauber aufgesetzt werden soll. Typisch: 100–2.000+ Geräte in regulierten Umgebungen.
Transformation Kit: Sinnvoll ab ~200 bestehenden Geräten mit struktureller Altlast (AD-Binding, keine Zero-Touch, manuelle Prozesse). Typisch: 300–5.000+ Geräte.
Bei unter 50 Geräten lohnt sich der Overhead meist nicht – außer die Audit-/Compliance-Last ist extrem hoch (z.B. Healthcare, Finance, Behörden mit strikten Auflagen).
Was, wenn wir kein Entra ID oder Okta haben?
Platform SSO funktioniert mit allen SAML 2.0 / OIDC-fähigen Enterprise-IdPs – das schließt Google Workspace, Ping Identity, OneLogin, Keycloak und andere ein.
Wichtig: Wir bauen keine Identity-Systeme neu und migrieren kein AD. Wenn Ihre Organisation noch kein funktionierendes Enterprise-IdP-Setup hat, ist das eine Voraussetzung, die vor oder parallel geklärt werden muss.
Falls nur klassisches AD existiert: Wir können Entra ID-Anbindung als parallelen Schritt einplanen, aber das verlängert die Timeline und erhöht den Scope. Das klären wir im initialen Call.
Was bedeutet das konkret für CISO, Audit und Haftung?
Der Zielzustand ist nachvollziehbar, dokumentiert und kontrollierbar. Sicherheitsrelevante Entscheidungen sind explizit getroffen, technisch umgesetzt und organisatorisch zugeordnet. Das reduziert implizite Risiken, vereinfacht Audits und schafft eine klare Trennung zwischen Plattformverantwortung, Betrieb und Nutzung.
Geht das remote oder braucht ihr On-site-Termine?
Remote-first. Architektur, Implementierung und Übergabe funktionieren vollständig remote. On-site-Termine finden nur statt, wenn sie organisatorisch oder politisch einen echten Mehrwert liefern.
Für wen ist dieser Ansatz nicht geeignet?
Für Organisationen, die Apple ohne ABM oder MDM betreiben wollen, dauerhafte Ausnahmen pro Fachbereich erwarten oder Apple als Sonderfall neben einer Windows-Plattform führen möchten. In diesen Fällen entsteht kein stabiler Zielzustand.
Kontakt
Kurzer Kontext reicht: Setup (ABM/MDM/IdP), Fleet-Size, Ziel. Ich antworte konkret.
Einfach schreiben
Wenn Sie lieber ohne Formular arbeiten: Mail mit Setup und Ziel, fertig.
hello@platform6.eu
Platform6 – Constantin Hanov-Blum
Riga, Latvia (Europe)
Phone +371 2200 1229
E-Mail hello@platform6.eu