Sealed Compute & Hardware-Attested Access
Confidential compute and hardware-attested device access — for workloads and connections that need to prove, not just encrypt, what they are.
Encryption in transit proves a connection can't be read in flight. It says nothing about who's on each end of it, or whether the machine processing the data afterward can be trusted with what it sees. Some workloads and access paths need to go further — the compute itself, or the device presenting to it, provably attesting to what it actually is. This is capability CNX designs and builds per engagement, not a packaged product — talk to us about your specific access model.
Sealed compute
A confidential computing environment processes data in a way that's opaque even to the infrastructure operator — CNX's own systems administrators cannot inspect data in use, only the workload owner can. For workloads where a customer's own compliance posture requires that guarantee — key material, sensitive transaction processing, anything where "CNX operates the hardware" needs to stop meaning "CNX can see the data" — sealed compute is a capability CNX has built and can deploy. It is priced and scoped per engagement, not a standard tier.
Hardware-attested access
Standard mobile application architecture routes critical transactions through a CDN provider that terminates TLS at the edge, decrypts the payload, inspects it, and re-encrypts it for the hop to the origin — the full plaintext content of every API call is readable at that midpoint, by a foreign commercial entity subject to its own government's laws, with no obligation to notify anyone when it receives a compelled disclosure request.
CNX designs private, hardware-attested access paths that remove that midpoint entirely: a cryptographically verified tunnel that originates on the device, terminates inside Cambodia, and connects directly to the backend over a private network interface. No public internet path for the protected calls. No foreign routing node. No anonymous access.
Device admission, not user friction
A lightweight library integrated directly into the application, using hardware-backed key material (Apple Secure Enclave, Android StrongBox/hardware keystore). No VPN prompts, no profile installation, no permission dialogs — invisible to the end user.
Admission before inspection
Only devices that pass platform attestation (Apple App Attest, Google Play Integrity) reach the backend at all. Anonymous traffic — scanners, bots, anything without a valid attestation — is dropped before any payload is inspected.
Domestic, redundant termination
Designed to terminate across independent data centres inside Cambodia, interconnected via the national IXP fabric, with sub-second failover between them.
NIST AAL
NIST SP 800-63B defines Authenticator Assurance Levels (AAL1–AAL3). AAL3 specifically requires a hardware-based cryptographic authenticator. A software-stored key behind existing password-plus-OTP login already exercises multiple factors, consistent with AAL2 characteristics — a hardware-backed key generated inside Secure Enclave or StrongBox, combined with platform attestation, is what's needed to bring a device-bound credential in line with AAL3's hardware requirement. CNX designs to whichever level a customer's actual compliance posture requires, and states plainly which one a given build achieves — formal AAL determination is a compliance assessment, not a self-declaration.
What this protects
- Transaction payload — amounts, recipients, account details, KYC data, verification responses
- DNS resolution for the protected path
- Routing decisions and flow metadata
- Encryption keys — held in hardware security modules inside Cambodia
This is design-and-build engineering, scoped to the access model and compliance target a specific engagement needs. Contact us to discuss requirements.