Apple. Clearly governed. As a platform.
Platform6 runs Apple as a platform in its own right: identity as the control plane, zero-touch as the standard, security baselines as a verifiable state. What you end up with is an operating model your team runs and your auditors can follow.
Based in Riga — on site across Germany and the Baltic states.
- Zero-touch enrollment, Platform SSO, declarative configuration
- Baselines for macOS, iOS and iPadOS with documented rationale per setting
- Six weeks to a handed-over target state, with runbooks and named ownership
The state has to stay explainable
In many organisations Apple exists on the side: the devices work, but the platform is not governed. That catches up with you as soon as accountability, updates, security statements or audits come into play. Platform6 therefore starts by setting up the architecture so that the state stays explainable over time, for operations, security and leadership.
Apple without platform governance
Apple is deployed, but identity, device state and operations do not mesh cleanly. What follows are works-somehow paths: local special cases, unclear update windows, support knowledge held in people's heads, and a security function that maintains lists instead of demonstrating effectiveness.
Governing platform states
Platform6 connects identity (Platform SSO, for example), the device lifecycle (enrollment through decommissioning) and security baselines into a state that translates into operations: rules, accountability, deviations, and a clear route from the current state to the target state.
Access follows identity and device state
Predictable updates, clean handovers
Effectiveness and documented deviation
A platform state that holds
Operations, security and accountability mesh. The state is documented, explainable internally, and stays stable even when teams change, new requirements appear or workloads are added.
Apple as a platform. Not as an exception.
Many organisations have Apple devices, few have an Apple platform. What makes the difference are architectural decisions: ownership, guardrails and a defined target state that aligns security, operations and compliance. That is what two clearly scoped offerings deliver.
Apple Sovereign Workplace Landing Zone
For organizations that want to get Apple right from day one.
The Landing Zone defines a non-negotiable day-one state for Apple in regulated environments. Not a project, not a proof of concept — but a complete, documented operating model.
What is established- A clear identity and access framework (Platform SSO, MFA, passkeys)
- Zero-touch enrollment and role-based device blueprints
- Security and compliance baselines as a defined state
- Clear operational ownership, runbooks, and control mechanisms
Apple becomes audit-ready, operable, and organizationally anchored — from the first device.
Explicit boundaries- No identity rebuild
- No application modernization
- No per-department custom architectures
Apple Zero-Touch Transformation Kit
For organizations with an existing Apple fleet and structural legacy.
This kit transforms Apple from an AD-dependent exception into a first-class platform. Not gradually over years, but through a clearly guided architectural cycle.
What changes- Decoupling from AD bindings and historic Windows logic
- Introduction of Platform SSO and identity-driven workflows
- Shift to zero-touch provisioning and declarative policies
- Redefinition of admin roles, responsibilities, and operating routines
Apple becomes governable, scalable, and secure — without permanently burdening operations.
Explicit boundaries- No AD migration project
- No endless transition states
- No exception-based architecture as a long-term model
Both offerings deliver not a recommendation, but a state — one that admins can operate without compensating for missing decisions every day.
From current state to a defined target state.
A short cycle that ends in a running state with operational ownership.
A defined platform is a choice.
Works best when …
- Regulated orgs with real audit pressure
- Environments where Apple should run as a first-class platform — not as a Windows exception
- Teams that want a defined standard, not endless customization
Not the right approach when …
- “We want Apple, but refuse ABM/MDM”
- “We want exceptions for every department”
- “We need a full IAM re-platform first”
Common questions
Does our agency need a specific MDM for classified use?
Yes. For indigo, BSI requires an MDM server component certified against the MDM-TS Protection Profile (BSI-CC-PP-0115), operated on premises on sovereign infrastructure. BlackBerry UEM currently holds full certification. Which other products still run under a transition period, and which dropped out of theirs without a certificate, is documented on the indigo page.
Choosing the MDM is the smaller half of the task: the operational environment around the certified server is not certified and has to be architected.
Can we cover this with our cloud MDM?
Not for classified use today. The MDM-TS Protection Profile is designed for on-premises operation, and the Brightsite requirement calls for an MDM server under German operational control.
No Protection Profile for cloud services exists yet, SOGIS harmonisation for one is pending, and whether US providers can meet EUCS Level High remains politically unresolved. We took the three dependencies apart in a separate article: Cloud MDM and BSI certification.
You are a very small provider. Will you still exist in two years?
Fair question, and the answer is built into how we work. Every engagement ends with a handover rather than a maintenance contract: configuration, documentation, architecture decision records and runbooks belong to you, and your team operates the platform on its own.
If Platform6 disappeared tomorrow, your target state would keep running. That is more than can be said for an open-ended retainer with a large provider.
Do you only work with Jamf?
No. We work with established enterprise MDM solutions such as Jamf, BlackBerry UEM, Ivanti, Omnissa, Microsoft Intune, or comparable platforms. What matters is not the tool, but a clean setup using Apple Business Manager and MDM. Without these foundations, a sustainable platform state is not possible.
Will you migrate our identity platform or Active Directory?
No. We do not replace identity systems and we do not run IAM re-platforming projects. We integrate existing enterprise identities such as Entra ID or Okta into a clear Apple architecture and decouple Apple from historic Windows logic where this makes operational sense.
What exactly is delivered?
The result is a running, defined target state: configuration, documentation, control mechanisms, role models, and operational routines. The state is audit-ready, operable, and usable in daily operations.
Is this a project or ongoing consulting?
We work state-driven: clear scope, clear endpoint, and a defined handover into operations. The target state works without permanent external dependency.
What does this cost?
The investment typically ranges in the low to mid 5-figure range, depending on scope, fleet size, and existing infrastructure.
What matters: You're paying for a defined target state, not consulting days. After week 6, the platform runs — without permanent external dependency. A typical "Apple modernization project" over 18–24 months costs multiples of this and often ends without a clear target state.
How large does our organization / fleet need to be?
Landing Zone: Makes sense from ~50 devices when Apple should be set up correctly from day one. Typical: 100–2,000+ devices in regulated environments.
Transformation Kit: Worthwhile from ~200 existing devices with structural legacy (AD binding, no zero-touch, manual processes). Typical: 300–5,000+ devices.
Below 50 devices, the overhead is usually not justified — unless audit/compliance pressure is extreme (e.g., healthcare, finance, government with strict requirements).
What if we don't have Entra ID or Okta?
Platform SSO works with any SAML 2.0 / OIDC-capable enterprise IdP — this includes Google Workspace, Ping Identity, OneLogin, Keycloak, and others.
Important: We don't rebuild identity systems and we don't migrate AD. If your organization doesn't have a working enterprise IdP setup, that's a prerequisite that must be addressed before or in parallel.
If only classic AD exists: We can plan Entra ID integration as a parallel step, but this extends the timeline and increases scope. We'll clarify this in the initial call.
What does this mean for CISOs, audits, and liability?
The target state is transparent, documented, and controllable. Security-relevant decisions are explicitly made, technically enforced, and organizationally assigned. This reduces implicit risk, simplifies audits, and creates a clear separation between platform ownership, operations, and usage.
Can this be done remotely or do you require on-site work?
Remote-first. Architecture, implementation, and handover work fully remote. On-site sessions are only used where they provide real organizational or political value.
Who is this approach not suitable for?
Organizations that want to run Apple without ABM or MDM, expect permanent per-department exceptions, or treat Apple as a long-term exception next to a Windows platform. In these cases, a stable target state cannot be achieved.
Contact
Brief context is enough: setup (ABM/MDM/IdP), fleet size, outcome. I’ll answer with a clear next step.
Just reach out
If you prefer no form: email with setup + outcome, done.
hello@platform6.eu
Platform6 – Constantin Hanov-Blum
Riga, Latvia (Europe)
Phone +371 2200 1229
E-Mail hello@platform6.eu