Sovereign UEM in Practice

The marketing pillar at the Sovereign UEM platform overview defines the category. This article is the implementation reference. The audience is engineers — CTOs evaluating endpoint management at scale, security architects defending procurement decisions to compliance, government technical reviewers reading the architecture before approving a contract, OEM engineering leads deciding whether to integrate at the factory.

The question this article answers: is Sovereign UEM real engineering, or marketing repositioning of a conventional UEM stack? The honest answer requires being specific about which APIs we use, which infrastructure we operate, what we built ourselves, and what we deliberately did not build. Below is that specificity.

Everything in this article describes Lockia's platform as it ships today. Where something is roadmap, I'll say so. Where we got something wrong in earlier iterations, I'll say that too.

Lockia's implementation of Sovereign UEM is four architectural layers. Each is independently sovereign in the sense that no third-party SaaS provider sits between the customer and their fleet for command, telemetry, or policy enforcement. The integration of the four is what makes the platform unified.

1. Android device layer — Lockia Cipher DPC. A Device Policy Controller built on the public Android Enterprise APIs. Runs as Device Owner. Communicates with Lockia's backend over an independent push transport, not Firebase Cloud Messaging. Does not require Google Android Enterprise partner certification.
2. Apple device integration — Lockia Cipher MDM. Lockia operates Cipher MDM in the customer's deployment region — no third-party MDM SaaS in the data path. Integrates with each customer's Apple Business Manager tenant using Apple's published MDM protocol. APNs sits in the command path as mandatory Apple infrastructure; no third-party MDM SaaS is added.
3. Hardware anchor — Cipher Protocol. Patent-pending architecture (USPTO 63/940,826) for hardware-anchored device identity and reset-resistant enforcement. Standard bypass paths — recovery mode, factory reset — are blocked at the hardware-attestation layer.
4. Agentic policy layer — Guardian AI. Behavioral threat detection layer that analyzes device telemetry continuously and arbitrates intervention decisions against current policy state. Operates against customer-specific telemetry in the customer's deployment region — not against a multi-tenant ML pool.

The next four sections cover each layer at the level of detail appropriate for a public engineering article. None of these is proprietary protocol invention — Lockia builds on APIs Apple and Google publish. The differentiation is in implementation quality and deployment posture, not in protocol secrecy.

Lockia Cipher DPC is a Device Policy Controller — a privileged app installed at provisioning time and bound to the device as the Android Enterprise Device Owner. The DPC is the kernel of Android device management. Every command Lockia's backend sends to an Android device executes inside the DPC's process, calling into the public Android Enterprise API surface.

We use the public Android Enterprise API surface — the methods documented at developer.android.com for Device Owner mode. The enforcement workflow surface includes device lock, full-wipe, user-restriction application, intent redirection for lock-state behavior, and application-level controls.

We chose Device Owner mode, not Profile Owner mode. Profile Owner only manages a work profile inside the device; Device Owner is responsible for the entire device. For enforcement-grade device control — the use case underneath every device financing or carrier subsidy program — Profile Owner is insufficient. A customer who defaults on an installment phone needs the device locked, not the work profile suspended. Device Owner is the only Android Enterprise mode that delivers full-device enforcement.

The command channel — how Lockia's backend tells the DPC what to do — runs on Lockia's own independent push transport, not Firebase Cloud Messaging. The reasons we operate our own push transport rather than relying on FCM: sovereignty, reliability, and deployability.

Reset resistance is the core differentiator at this layer. The standard bypass paths for a software-only MDM are factory reset, recovery mode, and SIM swap. Cipher Protocol blocks the first two at the hardware-attestation layer — making bypass via standard recovery flows ineffective on devices where Cipher is correctly provisioned. The patent-pending approach (USPTO 63/940,826, "Bypass-Resistant Device Locking") describes the enforcement model at the level appropriate for the public filing. Section 5 of this article covers it.

A note on what Cipher DPC does not require: Google Play Services as a transport. Google Play Services may be installed on the device — most consumer Android devices ship with it — and user-facing apps continue to work normally when it's present. But the policy enforcement path is independent. If Google Play Services is uninstalled, suspended, or unavailable on a given device, Lockia's command channel and core policy enforcement continue to operate. Some device features that depend on Play Services (notably Play Integrity attestations) require Play Services to be present, but the core enrollment, command, and reset-resistance enforcement do not. This is the architectural difference between AMAPI-built UEMs and Sovereign UEM: in the latter, Google's infrastructure is not a single point of failure for fleet command.

Apple's Mobile Device Management protocol is publicly documented. Any organization willing to invest the engineering can build an MDM server that integrates directly with Apple Business Manager and manages iOS, iPadOS, macOS, and tvOS devices. In practice, most enterprises buy MDM as SaaS from a vendor (Jamf, Intune, Mosyle, Workspace ONE) because building and operating a production MDM server is unglamorous infrastructure work. We chose to do the unglamorous work — because for our customer segments, having a third-party SaaS in the data path between the customer's ABM tenant and their fleet is a procurement-disqualifying dependency.

Lockia operates Cipher MDM in the customer's deployment region — no third-party MDM SaaS in the data path. The MDM server is built directly against Apple's published MDM protocol, so it integrates with each customer's Apple Business Manager tenant using the same federation Apple designed for any MDM vendor. What customers contract for is the deployment region, the isolation terms, and the operator (Lockia) of the MDM in that region.

What Lockia's Apple platform layer provides:

• Multi-tenant architecture. Each customer's ABM tenant is isolated at the database and policy plane layer. Lockia operates the MDM server; customers contract for tenant isolation in their deployment region.
• Billing system webhooks. Customer billing systems update device state via webhook. Lockia's webhook architecture accepts standard billing-platform event formats. Payment delinquency triggers progressive enforcement automatically.
• Progressive enforcement state machine. Configurable enforcement levels from gentle notification through full device wipe, configurable per customer cohort, geography, or product line. Each state transition emits a webhook back to the customer's billing system for audit.
• ABM tenant federation. Customers retain ownership of their ABM tenant; the tenant federates with the Lockia-operated MDM. This is the standard ABM-to-MDM relationship — same as it would be with any other MDM vendor — but with Lockia operating the MDM server, in the customer's deployment region, not a third-party SaaS.

The Apple command flow for an iOS device under Lockia management is: customer ABM tenant federation → Lockia-operated Cipher MDM (in the customer's deployment region) → APNs (Apple's mandatory infrastructure for any iOS MDM) → Apple device. APNs is non-negotiable infrastructure for any MDM, including ours. What Lockia's architecture removes is the additional layer of third-party MDM SaaS that customers using Jamf, Intune, or comparable vendors must accept. There is no Mosyle cloud between the customer's ABM tenant and the device fleet. There is no Workspace ONE multi-tenant SaaS storing the customer's enrollment metadata.

Honest about what Apple's architecture forces, regardless of which MDM vendor a customer chooses: APNs dependency cannot be removed. ABM enrollment records live on Apple's servers — that's the federation model Apple designed. Activation Lock binds devices to an Apple ID at the hardware level. None of these are sovereignty failures specific to Lockia or to any MDM vendor; they are properties of Apple's device ecosystem. The Sovereign UEM claim is about removing third-party SaaS from the data path between the customer's ABM tenant and the device — not about removing Apple itself, which is not architecturally possible and not a problem for the customer segments we serve.

The reason hardware-anchored identity matters in device management is the economics of bypass. A defaulting customer on an installment phone, a carrier subscriber attempting subsidy clawback evasion, or an adversary attempting to extract a stolen managed device from a fleet — all share a common pattern. They will try the easy bypass paths first: factory reset, recovery mode, SIM swap, USB recovery via OEM bootloader unlock. If any of those paths succeeds, the enforcement layer has failed.

Cipher Protocol's approach is to bind device identity to a hardware-anchored attestation surface at provisioning time and verify that attestation at every command execution. The cryptographic identity Cipher establishes at provisioning survives software-level recovery operations because it lives below the operating system layer that recovery flows operate on. The patent-pending architecture (USPTO provisional 63/940,826, "Bypass-Resistant Device Locking") describes the approach at the level appropriate for the public filing.

On Apple, Cipher operates within the boundaries that Apple's published MDM protocol permits. The Apple architecture constrains what a third-party MDM vendor can do at the hardware level — much more than Android — because Apple controls both the OS and the hardware. Cipher's implementation on Apple leverages Apple's device-attestation surface to establish identity, but the enforcement surface is the MDM protocol Apple publishes, not deeper hardware integration. This is by design and consistent with Apple's vendor model.

Above the command and enforcement layers, Lockia operates Guardian AI — a multi-agent threat detection system structured around four signal-detection roles plus an orchestration role:

• Orchestration Agent — arbitrates intervention decisions across the signal agents, weighting their outputs against current policy state and recent customer-cohort patterns.
• Behavioral Detection Agent — analyzes device telemetry sequences and identifies state transitions consistent with compromise, anomalous use, or impending bypass attempts.
• Risk Scoring Agent — probabilistic risk scoring across device signals, payment status, and historical cohort behavior; outputs a continuous risk score per device.
• Threat Intelligence Agent — surfaces threat patterns from the customer's own fleet against current device states; identifies defensive postures appropriate to the observed adversary behavior.

Each agent runs independently against the same device telemetry stream and outputs a vote on whether enforcement should escalate, hold, or de-escalate. The Orchestration Agent weights the votes against current policy state and emits the final decision. This is the agentic part of "agentic policy layer" — the system is not a static rule engine evaluating thresholds; it is a coordinated set of models whose combined output drives policy execution.

Guardian operates against telemetry from the customer's own fleet, in the customer's own deployment region, with no requirement to feed customer data through any external ML provider. There is no OpenAI API call in the device control loop. There is no Anthropic API call. The agents run on Lockia's infrastructure, trained on the customer's own data (with cross-customer learning federated rather than centralized). For customers with data-residency requirements, this is the only architecturally viable approach — and it's why we built it.

Today, Lockia's production infrastructure operates multi-region — Miami, Mexico, Brazil, and Colombia, with additional regions being added. The choice of provider per region is a function of regulatory posture, network topology to our customer regions, and operational maturity of the provider in that geography — not a religious preference for any specific cloud vendor.

For customers with deployment-region requirements that the current footprint doesn't cover, Lockia operates sovereign-cloud deployments on a per-contract basis. The customer specifies the required jurisdiction during procurement; Lockia provisions infrastructure in that jurisdiction with the customer's contractual deployment terms. This is operationally heavier than spinning up a region in our default footprint, but it's the model that matches the customer's sovereignty requirements.

Per-tenant versus shared infrastructure is a deployment tradeoff. The default model for customers without sovereignty-specific requirements is dedicated-tenant logical isolation on shared infrastructure — each customer's data is logically isolated at the database and policy plane layer, but the underlying compute is shared. For customers with stricter contractual isolation requirements, Lockia operates dedicated physical infrastructure — same platform, different cluster. The latter is more expensive and slower to provision; it's deployed where contracts require it.

Honest about what's roadmap. Additional EU and Asia-Pacific regions are under active planning, driven by specific customer procurement conversations. They are not deployed today. If a procurement contract requires deployment in a region we don't yet operate, we plan and provision before contract execution rather than promising regions we don't have.

No architecture lands clean on the first iteration. Three things we tried that didn't work, and what we did about each:

FCM dependency in the early Android stack. Before our independent push transport existed, our Android command channel rode Firebase Cloud Messaging. The reasons were the obvious ones — FCM is well-supported, free, and works out of the box on any Android device with Google Play Services. The problem appeared when we started selling into customer segments where Google Play Services was uninstalled, restricted, or unwanted. Customer-by-customer workarounds were not sustainable. Building our own push transport was the architectural answer, so the command channel does not depend on a Google service at all. That was a multi-month engineering investment; in hindsight, it was the right one earlier than we made it.

Overclaiming factory-reset survival before we understood OEM-level blocking. Early marketing language described Cipher as "surviving factory reset" without the nuance that OEM-level blocking of factory reset depends on the device being correctly provisioned in Device Owner mode at first boot. On devices where Cipher is provisioned correctly, the standard bypass paths are blocked. On devices where Cipher is installed late or in Profile Owner mode rather than Device Owner mode, the same guarantees don't hold. We corrected the language to "reset-resistant" rather than "survives factory reset" — more accurate, and more honest about the conditions under which the resistance holds.

The false start of customer self-hosting. An early version of our pitch deck described Sovereign UEM as offering "customer-self-hosted deployment options." It doesn't. Lockia operates the platform; customers contract for deployment region and isolation terms, but they don't run the platform themselves. The marketing language was an early conflation of "sovereign over data path" with "customer-operated infrastructure" — two different things. We corrected the framing across all customer-facing material: the sovereignty claim is about who is in the data path and where the infrastructure sits, not about offloading operational responsibility to the customer.

Listing this publicly is the kind of thing that procurement reviewers notice. A vendor that talks honestly about what it got wrong earlier is more credible on what it claims to have right now than a vendor that pretends every iteration was correct from the first day.

The architecture described in this article is the architecture Lockia ships in production today. Every layer is implemented, every API surface invoked is in use, every infrastructure region named is operational. The patent-pending Cipher Protocol approach is filed at the USPTO under provisional application 63/940,826. The Guardian AI agents run against live customer telemetry. The Lockia-operated Cipher MDM handles real Apple Business Manager federation today.

Sovereign UEM works because the AOSP and Apple MDM protocols permit it — Lockia didn't invent the APIs, we built the implementation. The closest analogy is the way Stripe built on existing card-network protocols. Visa and Mastercard published the rails; the differentiation was in the implementation quality and developer experience and deployment posture. Sovereign UEM is the same shape of story: Apple and Google published the device-management protocols; the differentiation is in implementation quality, sovereignty posture, and which infrastructure sits in the data path between customer and device.

For engineers evaluating whether to build on this architecture, integrate with it, or buy it: the implementation is real, the technical claims are verifiable against the APIs Apple and Google document publicly, and the procurement framework is shippable. For more on how Sovereign UEM applies to specific verticals, see the Sovereign UEM platform overview or the device financing solutions page.