Case studies · Technology Implementation
A private family trust fund needed strict control over who could access sensitive documents and data — from which devices, over which network paths, with no public internet exposure.
Executive summary — for the non-engineer
Why this is on a process-consulting site: the access path was the process. The software enforcing it was the last 20% of the work.
A private family trust fund needed a new system — built from scratch — for accessing sensitive documents and operational data across a small fleet of controlled devices. The requirements were defined by security, not convenience: the people and devices that could reach the data had to be precisely known, the access paths had to be auditable, and nothing related to the trust’s documents or internal applications could be reachable from the public internet under any condition.
Commercial MDM platforms and cloud-hosted document systems frequently place management interfaces and data on vendor-controlled infrastructure, creating access paths the trust could not fully control or audit. Public-facing endpoints — even those protected by credentials — were not acceptable for the nature of the materials involved.
The additional constraint was device-level control. Each authorized user needed a dedicated device that could only be unlocked by their own enrolled biometric — no shared credentials, no device handoff, no way for someone in physical possession of a device to access the data without the assigned user’s fingerprint. The devices had to behave as sealed appliances, not general-purpose Android tablets.
The brief to Neuralogic: design and build a system that achieves genuine enterprise-grade isolation and biometric device enforcement — using infrastructure that keeps every sensitive path inside a private network, at a cost appropriate for the scale.
Neuralogic mapped the access control requirements before selecting any component. The constraints were clear: Device Owner / kiosk control on Android, biometric single-user enforcement per device, an Always-On VPN so no device could reach any application without an authenticated tunnel, and seven internal web applications with zero public endpoints.
The solution is a fully self-hosted, private-first stack on Google Cloud Platform. The design principle: minimize the public attack surface to a single point and keep every sensitive component — the MDM server, the reverse proxy, and all seven applications — inside a private VPC with no public IP addresses.
A WireGuard VPN gateway running on a small GCE instance is the sole internet-facing component, exposing only a single UDP port. Every other piece of the infrastructure sits behind it. The only path to any document or application is through an authenticated WireGuard tunnel — there is no fallback, no secondary access method, and no management console reachable from outside the VPN.
Headwind MDM provides genuine Android Enterprise Device Owner control, including kiosk / Lock Task mode and fingerprint single-user enforcement for the managed user on each device. Because Headwind runs inside the private VPC, the management interface itself is never reachable from the public internet. Once a device is enrolled, Headwind pushes an Always-On VPN configuration: the user cannot disable the tunnel while the device remains in kiosk mode. Combined with biometric enforcement, each device becomes a sealed appliance — accessible only to its assigned user, capable of reaching only the private application set.
Deployments are handled through a self-hosted CI runner inside the private network. Changes never require opening inbound ports or routing credentials through an external service.
| Component | Tool | What it does | Cost |
|---|---|---|---|
| VPN gateway | WireGuard on GCE | Sole public endpoint. UDP 51820 only. QR-code enrollment for authorized devices and admins. | $6–15/mo |
| MDM | Headwind MDM (Docker) | Android Enterprise Device Owner, kiosk lock, fingerprint single-user policy, Always-On VPN push. | $0 community |
| Reverse proxy | Caddy | Internal TLS, host-based routing to the 7 apps. Private IPs only — never listens on a public address. | $0 |
| Web applications (×7) | Cloud Run (internal) / Docker | Reachable only via VPN + proxy. No public endpoints of any kind. | $5–20/mo |
| Deploy pipeline | Claude Code → Git → private CI | All deployments occur inside the VPC. Credentials never leave the private network. | $0–5/mo |
| Cloud foundation | GCP VPC + firewall | Private subnets, no public IPs on workloads, least-privilege firewall rules. | Included |
The completed infrastructure gives the trust a documented, auditable access architecture: five enrolled devices, each locked to a single authorized user by biometric, all reaching the private application set exclusively through an encrypted VPN tunnel that the MDM enforces and the user cannot disable.
“[Client quote — to be added]”
The architecture follows directly from the requirements. When document confidentiality and access auditability are the primary constraints, the right design puts every sensitive component behind a single controlled entry point — not distributed across vendor-hosted SaaS interfaces that introduce access paths outside the client’s direct control.
Commercial MDM platforms and cloud document management systems frequently place their management consoles on vendor infrastructure, accessible by vendor staff under the vendor’s security policies. For a trust fund handling confidential financial and legal materials, that’s an access path that doesn’t belong in the architecture. Self-hosting the MDM server inside a private VPC eliminates it entirely.
The result is a system where every component with access to sensitive data is under the trust’s direct operational control — the management interface, the applications, the access logs, and the enrollment process — at an infrastructure cost that reflects the actual scale of the deployment.
We map the access control requirements first, then design the architecture. Book a free 30-minute discovery call.
Book a discovery call ← All case studies