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 directly on the public AOSP DevicePolicyManager APIs. Runs as Device Owner. Communicates with Lockia's backend over LockiaPush, not Firebase Cloud Messaging. Does not require Google Android Enterprise partner certification.
2. Apple device integration — Lockia Cipher MDM. A self-hosted MDM server derived from the open-source NanoMDM core, deployed on Lockia's Kubernetes infrastructure. 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 TEE-backed device identity and reset-resistant enforcement. Binds device identity to the Trusted Execution Environment on Android and the Secure Enclave on Apple. Enforces lock state across multiple AOSP Device Owner layers — making bypass via standard recovery flows ineffective.
4. Agentic policy layer — Guardian AI. Five-agent multi-agent system using Hidden Markov Model behavioral analysis, Bayesian risk scoring, game-theoretic adversarial modeling, deception (honeypot) signals, and a Master Orchestrator agent arbitrating intervention decisions. 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 in detail. None of these is proprietary protocol invention — Lockia builds on APIs Apple and Google publish, plus an open-source MDM core. The differentiation is in implementation choices 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 AOSP DevicePolicyManager API surface.

The specific API surface we use is the public one — the methods listed in the AOSP documentation under android.app.admin.DevicePolicyManager. The commands that matter most for our enforcement workflow:

• setDeviceOwnerApp — establish Cipher DPC as the Device Owner at provisioning time
• addUserRestriction — block specific user actions (disabling install of unknown apps, factory reset, USB file transfer, etc.)
• lockNow — immediate device lock with optional policy flags
• wipeData — full-wipe enforcement at the Lockia policy plane's decision
• addPersistentPreferredActivity — redirect intents (used to constrain device behavior in Hard Lock and Soft Lock states)
• setApplicationHidden / setSuspendedPackages — granular app-level enforcement

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 AOSP mode that delivers full-device enforcement.

The command channel — how Lockia's backend tells the DPC what to do — runs on LockiaPush, our own push service. LockiaPush is a long-lived TLS connection per device that falls back to short-poll if the connection drops. Conceptually similar to MQTT over WebSocket, but built specifically for the device control workload (small payload size, strict ordering guarantees per device, end-to-end encryption with per-device key rotation).

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 multiple AOSP Device Owner enforcement layers — 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 multi-layer enforcement model in detail. 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 Cipher MDM is derived from the open-source NanoMDM core. NanoMDM is a minimal, modern MDM server implementation maintained by the MicroMDM project. We chose it over MicroMDM (the older Go-based implementation) for three reasons:

1. NanoMDM's architecture is closer to a library than a full application — it gives us a clean foundation to build the multi-tenant, billing-integrated, progressive-enforcement layer on top, without inheriting design decisions tuned for a different deployment model
2. Active maintenance and a small, well-understood codebase — easier to audit and easier to keep current with Apple's ongoing MDM protocol changes
3. BSD-style licensing that permits commercial use without copyleft propagation into our policy layer

What we built on top of the NanoMDM foundation:

• 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 (their own platforms, or partner platforms like Stripe, Recurly, Amdocs for carriers) update device state via webhook. Payment delinquency triggers progressive enforcement automatically.
• Progressive enforcement state machine. Eight 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; Lockia operates the MDM server pointer that the ABM tenant federates with. This is the standard ABM-to-MDM relationship — same as it would be with any other MDM vendor — but the MDM server in question is Lockia's self-hosted instance, not a third-party SaaS.

The Apple command flow for an iOS device under Lockia management is: Apple device → Apple Push Notification service (APNs — Apple's mandatory infrastructure for any iOS MDM) → Lockia self-hosted Cipher MDM server → customer's policy layer in Lockia's backend. 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 the Trusted Execution Environment at provisioning time and enforce lock state across multiple AOSP Device Owner enforcement layers. On Android, that binding happens in the TEE — the hardware security partition that runs isolated from the main Android OS, has its own memory space, and survives most software-level recovery operations. The cryptographic identity Cipher establishes at provisioning is anchored in the TEE and verified at every command execution.

Multi-layer enforcement means each of the AOSP Device Owner enforcement surfaces is independently blocking the bypass attempt. A single-layer enforcement model can be defeated by finding one weakness in one API; multi-layer enforcement requires the bypass to defeat several independent surfaces simultaneously, and the TEE-anchored identity check has to be defeated as the substrate. The patent — USPTO provisional 63/940,826, "Bypass-Resistant Device Locking" — describes the multi-layer architecture in detail.

On Apple, Cipher leverages Apple's hardware-backed Secure Enclave for device attestation while operating 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 is therefore narrower in scope than its Android implementation: it leverages Secure Enclave attestation to establish device 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. The five-agent topology is:

• Master Orchestrator — arbitrates intervention decisions across the four signal agents, weighting their outputs against current policy state and recent customer-cohort patterns
• HMM Agent — Hidden Markov Model behavioral analysis of device telemetry sequences; identifies state transitions consistent with compromise or anomalous use
• Bayesian Agent — probabilistic risk scoring across device signals, payment status, and historical cohort behavior; outputs a continuous risk score per device
• Game Theory Agent — adversarial modeling of likely attacker behaviors against the current device state; identifies defensive postures that increase the cost of bypass attempts
• Deception Agent — deploys honeypot signals into the device telemetry surface; flags devices whose response patterns indicate active reconnaissance against the enforcement layer

Each agent runs independently against the same device telemetry stream and outputs a vote on whether enforcement should escalate, hold, or de-escalate. The Master Orchestrator 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 runs on multi-region Kubernetes deployments. Specifically: Vultr Miami and Vultr Mexico City for the Lockia application stack and Cipher MDM, with Linode hosting LockiaPush for the Android command channel. 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 by Row Level Security and policy plane partitioning, but the underlying compute is shared. For customers with stricter contractual isolation requirements, Lockia operates dedicated physical infrastructure — same Kubernetes stack, different cluster. The latter is more expensive and slower to provision; it's deployed where contracts require it.

Honest about what's roadmap. Brazil region (São Paulo) and EU region (likely Frankfurt or Madrid) 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 LockiaPush 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. LockiaPush was the architectural answer: we built our own push transport so the command channel did not depend on a Google service at all. That was an eight-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 listed is in use, every infrastructure component 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 Cipher MDM server, derived from NanoMDM, 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 and OEM pre-configuration solutions page.