Public Sector Device Sovereignty

Regulated public-sector buyers in Latin America, the EU, and emerging markets increasingly write specific architectural requirements into their RFPs: in-country data residency, no third-party SaaS provider in the command-and-control path between the buyer and their device fleet, no foreign-government service dependencies, and contractual data-handling terms the buyer's procurement office can govern. These are not optional preferences; they are disqualifiers. A platform that cannot satisfy them architecturally is not eligible to bid.

The dominant enterprise UEM vendors — Microsoft Intune, Jamf, VMware Workspace ONE, IBM MaaS360, ManageEngine — operate as third-party SaaS layers. For Android, their architectures route commands through Google's Android Management API and Firebase Cloud Messaging. For Apple, their MDM servers operate in the vendor's cloud between the customer's Apple Business Manager tenant and the device fleet. Both halves of the device estate sit on US-hyperscaler infrastructure.

For most enterprises, that's an acceptable trade. For a Mexican federal agency procuring endpoint management under data-residency requirements, a Brazilian healthcare network governed by LGPD, a Chilean public-sector buyer with sovereignty mandates, or an EU government office under digital-sovereignty procurement frameworks, US-SaaS-in-the-data-path is not an architectural inconvenience — it is a procurement disqualification. The contract cannot include those vendors regardless of how good the product is in non-sovereignty-constrained deployments.

The architectural gap is real and growing. Public-sector buyers are increasingly forced into either (a) deploying a vendor that doesn't meet sovereignty requirements and accepting compliance risk, (b) building custom in-house platforms (expensive, slow, rarely operationally sustainable), or (c) declining to procure modern endpoint management entirely. None of those are good outcomes.

Public AOSP DevicePolicyManager APIs, not Google AMAPI. Lockia's Cipher DPC is built directly on the public AOSP APIs that ship in every Android Enterprise–capable device. The DPC enrolls as Device Owner at first boot. Command and policy decisions route through Lockia's own backend infrastructure on a push transport (LockiaPush) that does not depend on Firebase Cloud Messaging or any Google service as transport. Google services remain absent from the data path between the buyer and their fleet.

Self-hosted MDM server for Apple, integrated with the buyer's ABM tenant. Lockia operates Cipher MDM — derived from the open-source NanoMDM core — on Lockia's Kubernetes infrastructure. The buyer's Apple Business Manager tenant federates with Lockia's self-hosted MDM server. There is no third-party MDM SaaS between ABM and the device fleet. Apple's APNs is mandatory infrastructure for any iOS MDM and remains in the path — that is non-negotiable Apple infrastructure that applies to every MDM, including ours. What is removed is the additional layer of third-party SaaS.

Customer-region Kubernetes deployment. For sovereignty-bound contracts, Lockia operates the platform infrastructure in the jurisdiction the buyer's procurement contract specifies. The buyer's data-handling agreements govern the deployment terms; Lockia operates within those terms. This is the architectural property "customer-controlled data path" as defined in our Sovereign UEM platform overview — not a hosting-region promise, but a contractually deployable infrastructure model.

Compliance and procurement posture. Lockia's SOC 2 Type II audit is in progress with Prescient Security. The Cipher Protocol architecture is patent-pending (USPTO provisional 63/940,826, "Bypass-Resistant Device Locking", December 2025). Multi-region Kubernetes infrastructure is operational across the Americas with additional regions on roadmap as procurement contracts require them. The legal entity converting from Florida LLC to Delaware C-Corp aligns with enterprise procurement preferences for vendor incorporation.

Public-sector device sovereignty is one configuration of Lockia's Sovereign UEM platform. The same Cipher Protocol, the same Cipher DPC, the same Cipher MDM, the same Guardian AI agentic layer. What changes for public-sector deployment is the procurement framework (sovereignty clauses, data-residency requirements, vendor-incorporation preferences), the deployment region, and the audit posture. The architectural commitment is the same as for every other vertical Lockia serves.

For a procurement reviewer or a public-sector IT director evaluating Lockia: the platform you deploy for sovereignty-bound public-sector device management is the same platform that powers Lockia's device-financing, carrier-subsidy, and OEM-partner deployments. The architectural choice once; the vertical configurations downstream.